Ask HN: What Git branching strategy do you use in 2023, and why?
I'm working with a new small team (less than 8) and converting them to Git. It's been awhile since I started with a green field when it comes to branching strategy. What do you follow in 2023, and why?
16 comments
[ 3.7 ms ] story [ 50.1 ms ] threadIt's rather simple for a new employee to understand, meshes in nicely with CI/CD systems and the release processes of the places I worked at.
Many modern workflows literally have has you prematurely deploying experimental code into production. Hidden behind feature flags. Release branches may not be needed when you do that, but that's a transfer of complexity, not an elimination.
Also the alternatives usually involve a lot of cherry picking. That's nice, but cherry picking requires good understanding of the code to properly do. Complexity moved away from one area into another again.
Development happens on short lived branches, gets merged to master via pull request after code review if needed, but at least some automated testing should be done.
NEVER DO MERGE COMMITS: Always rebase + fast forward merging only.
Branches that never reached production and likely never will should be discarded after a while.
Branches that reached production e.g. hotfix branches should be converted to tags after a while.
When looking at history on our main branch, we ALWAYS use `git log --first-parent` which ONLY shows merge commits. Then it shows you exactly what was important (the merge) and in the correct order.
I really wish this was the default view of git log, or really, if git log acted like bzr log that would be even better. It would stop all these arguments about how to have linear history.
Personally I’m a `merge —squash` guy but to each their own
An actual "merge commit" should make it easier to revert/reset. I always use merge --no-ff to ensure a merge commit is created. With a merge commit it's clear where the feature branch starts/ends.
To back out a merge, you would just do another merge with a reverse diff: `git merge merge-commit..merge-commit^`
Also, it makes things like backporting much easier, since you can just pull out the merge commit and it brings in any "subcommits", rather than individually cherry-picking each commit, like you'd have to do with a fast-forward.
It also makes life so much easier on other developers that are just working in feature branches. No need to rebase. No need to squash. No need to clean up commits. We allow merging master back into your feature branch rather than rebasing, since in the end it doesn't matter (and sometimes, everything you did is interesting).
- git checkout -b "new-branch"
- git commit
- git merge --no-ff master (to get the latest from master into our branches)
- git push
That's all you need. No rebase or force pushes. Easy.
But I understand why people who just use `git log` complain with merge commits. It is frustratingly hard to see what actually happened, because subcommits from that merge branch show up in the past in your linear timeline and aren't grouped together. It clutters your log and makes it really hard to tell what is going on and what commits are related to each other.
bazaar's (now called breezy) log (which we used before moving to git) was really nice. By default, it only showed first parents (direct commits or merges). And if you wanted to see more than that, it grouped merges together. This is what happens when you call `bzr log --include-merged` to show not just the top level merges/commits, but also the sub-commits from each merge:
The top level merges are in order by commit/date, while the sub-commits in each branch and in order with respect to their parent, not the entire repo!This even resolves stuff, like in revno 29.2.3 where the master branch is merged into the feature branch (fix-408) to get fix-408 up to date.
git should be used like an audit log, where you can trace the thought process and actions of your developers. Erasing that by rebasing/squashing for a "clean" log isn't worth it in my opinion.
I'd much rather see 40 commits across two weeks on your branch than one "clean" commit with everything. With the 40 commits, I can trace back through your work, and understand your challenges (sometimes seeing 5 commits in a row with 'trying to get X to work' is really useful).
Now, do I want all that detail once your branch is in master. Absolutely Not! I just want a single merge commit that brings in your whole branch. Unfortunately, `git log` shows everything, which is why I advocate for `git log --first-parent` being the default.
If git log's default behavior wasn't so terrible, I don't think this argument would even come up so often.
However, `merge --squash` loses its association with that feature branch, which is annoying. You also don't get to see any of the history of what happened in that branch, which can sometimes be really useful if there ends up being a bug that you want to bisect. You don't have any of the original developers individual steps, since it all comes in as a big, unassociated chunk.
It is all about reducing feedback cycles.
[1]: https://githubflow.github.io/
I hate git-flow with a passion.