A successful Git branching model (2010)
A successful Git branching model (2010)
In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.
There is a discussion on Hacker News, but feel free to comment here as well.
So I’ve been a fan of and have used git flow since probably 2015ish. It really does make things so much easier and takes a lot of the Wild West feeling of git. I strongly recommend it for teams of any size- I even use it solo simply for the structure and documentation it adds around releases and history.
Also, going all in with semantic versioning and declarative git messages just really make your repos feel pro.
2I use git flow when there's a large number of contributors, trunk based when there are a small numbe (or just me), and emails of latest versions to myself when I am feeling particularly evil.
1That last point made me throw up in my mouth a little bit.
Years ago I got pulled in to work on a big Java project from another company. I asked for the source because we had to write and include a new module. They said “we just decompile the jar, make changes, and recompile it”.
I couldn’t get off that project fast enough.
2
Have been a fan of a what I called "simplified" git flow until recently when I realized I am basically doing trunk based branching with two trunks (Main and dev). The static dev branch had its appeal for static deployments (no test deploy from varying feature branch, but still not main); however, for gitops and for general simplicity forcing yourself and the team to main has its advantages. E.g knowing that every deployment is from main.
2