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.
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.
I 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.
That 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”.
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.
I 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.
That 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.