Git has almost universally taken the world over at this point it seems. The project from the Linux founder is now heavily used by Microsoft, and even games companies with their terabytes of asset history are finding more and more use of Git in their organizations.
One of the consequences of all this attention is that a lot of “alternative” workflows are being exercised on Git that don’t quite match the original intended workflow. In this vein, we’re now seeing a lot of folks advocating for the squashing of commits when merging branches in Git rather than using Git’s standard merge commits.
See for instance this documentation from GitHub or BitBucket which illustrates the feature work they’ve put in to enable this workflow.
My problem is that these features are just workarounds for bad UI.
The supposed benefit of squash commits is that the messy history of a branch can be summarized down to its salient points, and the big snaking history of the development branch doesn’t clutter up the main development branch’s history. After all, when looking at a project’s history, most developers (and users, and managers, and so on) really just want to see the big exciting stuff (the feature merges) and not each and every single commit that ever happened.
However, this isn’t necessarily a technical need for this pruning. The Git history UIs we all use could instead hide these details. e.g., after each merge, exclude all the non-interesting commits between the merge commit and the parents’ common ancestor. Alternatively, if branches are never deleted, the UI can differentiate the development branch from a feature branch based on the branch’s commit ref. The default view of the development branch can prune out all the little commits while keeping that history around, which can be valuable.
That history can be really valuable in many projects. Sometimes the only documentation on a piece of code is the commit that went along with it. Throwing those commit notes away can lose valuable context about why a particular change was made or what it was intended to do.
The tools should do better. Instead of mutilating a repository’s history, the UI for browsing the history should make it easier to filter out information that is irrelevant in the current context.
Yes, Git’s structure makes this hard. If anything, that’s a sign that Git’s current incarnation is not good enough. Mercurial does better here. Plastic does better here. Git should do better here.