Should you squash commits?
On an active shared branch, squash-merging is a defensible team convention. On anything you might license, no. Commit history is priced separately from source when code is licensed for training, and it is the large majority of the token volume, so squashing deletes most of what a repository is worth.
The usual answer to this question is a team convention argument: readable history versus honest history, and reasonable people disagree. That argument is fine as far as it goes. It leaves out something that changes the answer for a large category of repositories.
What squashing does
A branch with fourteen commits gets merged as one. The final code is
identical. The fourteen intermediate states, their messages, and their order
are discarded. git log on main shows a single tidy entry instead of the
sequence that produced it.
Interactive rebase with squash or fixup does the same thing at a finer grain. Rewriting history to remove a file, or starting a fresh repository so the first commit is clean, are the same act with a different motive.
The engineering arguments
For squashing: main stays readable. Each entry is a complete, reviewed unit. Bisecting works at the level of features rather than “fix typo” commits. Nobody has to see the six commits titled “wip”.
Against: the intermediate states are how the code got that way, and that is the thing you most want when something breaks two years later. The commit that tried the obvious approach and reverted it is documentation nobody would have written by hand. Bisecting at feature granularity finds the feature, not the line.
Teams pick a side and live with it. On an active shared branch, either is defensible. This page is not going to relitigate it.
What history carries that a snapshot does not
Look at a repository as a body of text rather than as a program.
The final source is a snapshot: the code as it is now. The history is a record: every diff, every message, every ordering, from the first commit to the last. On a codebase maintained for a few years, that record is far larger than the snapshot. Every commit is a diff plus a message plus a position in a sequence, and there are thousands of them.
a repository, as text
│
├── source ───► the snapshot: the code as it is now
│ small
│
└── history ──► the record: every diff, message, and order
many times larger, and irreplaceable It also carries different information. The snapshot shows what good code looks like. The history shows how code gets that way: what was tried, what failed, how a bug was actually found, how a refactor rippled through thirty files. That is the signal that teaches a model to maintain software rather than merely generate it, and it cannot be manufactured after the fact.
┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐ │ │ │ Private, finished, owned by you: $500+ each to AI labs. │ │ │ │ [ See what my repos are worth ] │ │ │ └──────────────────────────────────────────────────────────────────────┘
How history is valued
When source code is licensed to the labs training coding models, source and history are priced separately, per million tokens. History has the lower rate per token. It has vastly more tokens. Across a real portfolio it runs to something like twenty to thirty times the volume of the source, and it ends up being where most of the money is.
The figures, dated and sourced, are on what AI labs pay for code. The repo value calculator applies them and shows the split, which is usually the moment this page’s argument lands.
The consequence is not subtle. Squashing a year of work into one commit throws away most of what that year is worth. A fresh repository with a single “initial commit” containing a finished codebase is worth its source and nothing else.
A policy
Active shared branches. Follow your team’s convention. If it is squash, squash. The trade-offs are the usual ones and this page adds nothing to them.
Dormant repositories. Leave the history alone. There is nobody to tidy it for and something real to lose. If a repository is finished, the correct action is to archive it as it is.
Repositories you might license. Do not rewrite anything. Do not squash, do not clean up messages, do not remove the embarrassing commits, do not start a new repository to make the first commit look presentable. Submit it as it is.
Repositories with secrets in the history. Still do not rewrite. Secrets and personal data are stripped from the review copy before a buyer sees anything, in the code and the history, and your repository is not touched. Rewriting history yourself to remove a key destroys value and does not fix the leak; rotating the key does.
The one genuinely irreversible action
Deleting the repository. Squashing loses history; deletion loses all of it, usually permanently. If the goal is to stop seeing an old repository, archiving does that without cost. If you are about to delete, read what you lose when you delete a GitHub repository first.
What to read next
- What AI labs pay for code, the figures behind the history argument
- How to archive a GitHub repository, the right action for dormant work
- Can you license private repositories, on which repositories this applies to
Common questions
- What does squashing commits actually do?
- It replaces a sequence of commits with a single commit containing their combined changes. The intermediate states, messages, and order are discarded. The resulting code is identical; the record of how it got there is gone.
- Is squash merging bad practice?
- No. It is a legitimate convention for keeping a main branch readable, and many teams use it well. The point here is narrower: it destroys information, and that information has a value that most teams have never had a reason to consider.
- Does rebasing have the same effect?
- Interactive rebasing that squashes or fixups commits does. A plain rebase that replays commits onto a new base preserves them, though it rewrites their identifiers.
- Can squashed history be recovered?
- Locally, sometimes, through the reflog for a limited time. Once the squashed branch is the only copy on the remote and the original refs are gone, no.
- Should I clean up history before licensing a repository?
- No. Submit the repository as it is. Secrets and personal data are stripped from the review copy without touching your repository. Tidying history removes the thing you are being paid for.