- It turns out I’ve been doing development stuff a long time
- One size fits all policies rarely work well
git rebaseis hard, but isn’t the only way to clean up the cruft in a branch
- squash and merge may be beneficial in certain situations
A grey-beard sermonises…
My first encounter with Distributed Version Control (or DVC) happened around ten years ago, and was actually with Mercurial or (Hg). At the time I’d heard much about Git, but hadn’t used it. One of the major differences between the two was summed up to me like this:
Commits in Mercurial are immutable, once you have written the commit you cannot change it. But commits in Git are maybe immutable, everyone has to agree that a commit is immutable. It’s possible to go back and change pretty much everything about a commit. But I don’t know why you’d want to do that…
And being a callow youth there that stayed, until recently. The reason I bring it up now is that a couple of things have happened recently that reminded me of this.
Squash and merge is the law of unintended consequences in action
In the first situation myself and a colleague were investigating an issue that had occurred with some newly deployed software. The minor difficulty was that we had created this software on a long lived feature branch (there are reasons you may consider long-lived feature branches to be harmful), and the software was actually already a couple of weeks old. If you’re committing with good messages then this isn’t too much of an issue. Once you’ve pinpointed the code that has caused the issue you can just look at the commit to find out why the code/config/whatevs is that way. (And here I’m going to call out GitLens in VS Code as it surfaces this information right in the editor.)
Except that what we saw in the editor wasn’t information on why the code or config was the way it was. What we saw instead was all the code/config in the file associated with a single commit, with a subject line of the name of the long-lived feature branch. On clicking through to view the commit we were confronted with a Wall Of Text.
This was a branch with 60+ commits on it, that had consisted of tens of sub-branches (some of which had also been squash-merged, but I’ll come to that). And in that Wall Of Text was the information I needed. I’ll be truthful, we abandoned that line of inquiry and worked backward to try and establish why things were that way. In talking to my colleague who had squash-merged, it emerged that it was common practice within the organisation.
It’s good to talk
The second situation occurred earlier this week. A member of another team had tweaked some of our code because it came to light that the events they were generating (and we were consuming) whilst having sensible names, had names that could cause problems in the future. (Naming things is one of the hardest problems in computer science.)
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.— Leon Bambrick (@secretGeek) 1 January 2010
But I needed to put in a minor build fix, and appended it to his branch (naughty). For some reason I decided to go and tell my colleague he could merge and kick off the deployment process. And for some reason he asked if it was ok to squash+merge. We started talking about commits, good commit messages and cleaning up cruft. His principal got involved in the conversation and the conversation to
rebaseing, which pretty much killed it dead 🙄 .
And it is true, rebasing can be hard the first few times that you do it. But any skill worth acquiring is hard initially, and the same is true of
git rebase (and I would argue that it is a distinct skill within the
git skill set). As long as the original branch has been pushed up to a server you can then go to town on cleaning up the branch, and the only thing that will be lost (until you push again) is a little time.
Squash and merge might not be that bad
Now I did mention above that it might be legitimate to squash and merge a branch. The one situation this may be legitimate is when you’re working on a short-lived feature branch. But here you need to be careful. You need to ensure that your not creating a monster commit. You also need to go and edit the commit message that will be generated for you. Certainly on Github the commit message will consist of the branch name as the subject of the commit, and the commit messages as a bulleted list within the body.