A note of reflection after 10 years of “A successful Git branching model”

I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler.<p>[1] <a href="https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trunkbaseddevelopment.com&#x2F;</a>

Reading the comments, I realize I&#x27;m a git neophyte (limited experience working on some open source software, didn&#x27;t know &quot;gitflow&quot; was a thing) so excuse me for my naive question. But what about this simple workflow. Developers submit PR on top of a master branch (developer is in charge of rebasing, PR must pass integration test). Administrator is in charge of merging, maintains a linear history. Releases are just tags on master. Has this workflow a name? anything wrong with it?

Is this related to the &quot;Please stop recommending Gitflow&quot; [1] article posted yesterday?<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22485489" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22485489</a>

We started with gitflow, but our team ended up going with a Release based branching system as the constant integration of various features ended up giving less control on what to deploy and when. Most common scenario...<p>Devs create feature branches from master<p>Features will be targeted to a release at some point, Release branch gets taken from master<p>Devs PR feature branches to the release branch<p>Release branch merges back to master on deployment.

A problem with GitFlow is it&#x27;s painful to follow PR model.<p>Especially on the Github repository where pushing to master is a lock and can only done by PR and merge(or squash or whatever).<p>Let&#x27;s take a look at a release:<p>1. Branch of release&#x2F;1.0 from develop 2. Fix some bug, then at the time of deploymennt. Merge it back to master <i>and</i> develop<p>But once we merge, github close the PR... If we attempt to create another PR for other branch. The Github now see different history between master&#x2F;develop...

I&#x27;ve yet to work on a codebase that was so congested it required such strong delineation between feature&#x2F;hotfix&#x2F;release but I can see how it might be required at a certain size. I wonder what that threshold is.

It all depends on the situation. The simplest possible situation of mostly just having a master branch also can work quite well. When you have specialized testers that test a candidate release you start to need release branches. Feature branches start being necessary if changes are temoprarily incompatible with current master. This should not be too common, though. In many cases one can avoid feature branches by having feature switches that get removed as soon as a feature is done. If one wants to or needs to use feature branches they should be short-lived because one will be creating a merge hell if this is not the case. The git flow seems just too complicated for most cases. One comment already notices that it is quite unclear why a separate development and master branch are necessary.

I love this branching model. I have being used in all projects and teams I can. I use it even in projects where I work alone. For me it is the ultimate branching model.

AFAICT Gitflow just has one more branch than it needs. If you got rid of the master branch and supported production releases off release branches it would be just as useful and significantly less complicated. Can anyone explain to me what real value the master branch adds in this model? And without using fluffy meaningless words like, &quot;source of truth,&quot; please.

I have never succeeded in working in a branch and having the real owners accept my state.<p>I am of course talking about &#x27;outsider&#x27; changes to code, but the effect is real: the master owner can elect to say &quot;sorry, we decided to re-architect significantly and what you did is now superfluous, or at least too hard for us to re-integrate&quot; and almost everything I have been involved with, this is what happened.<p>Submitting small patches to their head state is more effective for me than trying to maintain state against a moving target with a realistic chance of making significant change, and having it accepted into the mainline.

Strongly agreed with the new author note. I used the same ideas with the teams I&#x27;ve been coaching: &quot;Consider your context....&quot; as the need or not of support for multiple versions and &quot;...Decide for yourself.

I accept your apology.<p>History is for reading, not writing. Do we make decisions that give us readable and informative histories? The people who give up and rebase absolutely everything into one linear trunk are not working optimally, but at least they&#x27;re trying.

So cool that something Linus Torvalds made to solve his own problems, spread all around the world so quickly. I guess great dev tools can only be made by great developers, who have been through a lot of scenarios&#x2F;problems themselves.