
What git branching models actually work? - ColinWright
http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work
======
akie
I really like this one - [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/)

~~~
jedbrown
I'm not a fan. I have never seen a statement of what it gains over
gitworkflows(7) and similar (models that prepare releases in 'master',
integrate in 'next' which is eventually rewound, and support existing releases
via 'maint'). The most critical difference is that git-flow eschews the
integration process that allows new features to interact before they are
merged to 'master'. Instead of having topic branches tested together in
'next', someone has to be make the difficult decision of whether a topic
branch that has only been tested in isolation should be merged into 'develop'
(or hotfixes into git-flow's 'master', which is most similar to 'maint' of
gitworkflows(7)).

This generally means that a git-flow 'develop' is less stable than a
gitworkflows(7) 'master', so it's more common to be working on a new feature
and find bugs that were there when you started. That's disruptive to
development and its unpleasant to users that would really like the latest
stuff that you think is actually ready for them to use.

Thus any decision to merge a topic branch comes with the pressure that any
bugs introduced in the merge (possibly through indirect semantic conflicts
with other work) will disrupt any developer starting new work between the
merge and the time a fix is provided.

In contrast, merging to 'next' in gitworkflows(7) comes with relatively less
pressure because bugs there only affect integration and eager users, but not
new development. Furthermore, merges to 'master' come with knowledge that the
feature has already been playing nicely in 'next', which contains everything
in 'master' as well as some other new features.

I wrote a more extensive comparison in [http://mail-
archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.an...](http://mail-
archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov)

~~~
aidenn0
I always use "develop" for integration. that is "develop" is git-flow's "next"

~~~
jedbrown
Not the same at all. Git-flow is worse than merging 'next' into 'master'
before a release, which is a huge no-no.

With gitworkflows(7), new topic branches start from 'master', merge to 'next'
when thought to be complete, may receive additional patches while there
(remerging to 'next'), and may fail to "graduate" to 'master' (either being
discarded by reverting in 'next', or just not selected for this release). When
complete, the _topic branch_ is merged to 'master'. 'next' is periodically
discarded (usually after a release). This means that the sometimes messy and
occasionally broken state in 'next' does not remain in the history and is
_not_ used for new development, and some parts of 'next' will not be part of
the permanent history. With gitworkflows(7), the history that eventually makes
it to 'master' is only complete and fully-tested features (demonstrably so,
because it has been in 'next' already). Gitworkflows(7) gives you cleaner
history, a more stable 'master', and makes releasing less disruptive.

~~~
aidenn0
Thanks for the clarification

------
calpaterson
In short: not many. There is a serious tension between branching workflows and
continuous integration (I mean the technique of merge-early-merge-often, not
"the Jenkins server that runs the tests").

The whole point of continuous integration is that you do not wait until you
are done to try to merge your changes. Merges in themselves are painful and
not only are there fewer conflicts but they are less serious when everyone is
(with few exceptions) just doing little merges all the time.

Moreover, having your changes merged in quick also means that you will get
feedback about your changes before you're "done". If your change doesn't break
a test but breaks functionality in a subtle way there is a much greater chance
that someone will notice it and if you're doing something wrong that you don't
know about, again, it's much more likely that someone will tell you. In bigger
teams or in complicated domains this becomes more and more important.

Decent and related article:

[http://martinfowler.com/bliki/FeatureBranch.html](http://martinfowler.com/bliki/FeatureBranch.html)

~~~
alinajaf
Quick question, have you ever personally experienced this work on a team, or
is this just theory?

I'm genuinely interested in collecting good examples of it working. The other
article about flickr doing this with feature toggles seemed to be a good fit.

<Rant>

The reason I ask is that earlier this year, I was working with a client who
spent upwards of $3 million USD on a content managed website with a huge
consultancy that I can neither confirm nor deny is heavily affiliated with the
author of the article you may or may not have posted a link to.

They were left with a config-driven feature-toggle system that can only be
described as a Rube-Goldberg monstrosity. If statements from old feature
toggles littering the codebase and different features toggled on or off in
environments that no one knew the meaning of. My favourite was when we
discovered after days of trawling through the code that a feature toggle was
being used to _switch a feature off_ rather than on.

There was also a team-wide ban on branching of any kind, including local
branching. This belies a misunderstanding of how git works more than anything
else. I went ahead and kept as many local branches as I bloody well felt like,
because there's no way they'd know the difference.

</Rant>

~~~
Chris_Newton
I sympathise with that concern, and anecdotally I’m still waiting to encounter
a feature-toggled project in my own work where the maintenance overheads
didn’t quickly become painful out of all proportion to the benefits.

It was bad enough in the days of #ifdef driven development in C, where the
meaning of your code and even your entire software design could change based
on an arbitrary set of macros that didn’t respect scope, didn’t offer any type
safety, and might be defined anywhere: a random header file, a makefile
setting some command line option, or just some environment variable on one
particular developer’s PC that they set three years ago and forgot about.
Making a controlled, reproducible build that you actually trust to be what you
think it is is very difficult in that kind of environment.

It’s even worse with dynamically typed languages, because now you don’t even
have compile-time warnings about redundant code or type safety guarantees on
the code _inside_ the feature checks to prove it would run sensibly. To me, it
feels like the whole strategy plays right into the major downsides of using
dynamic types. No doubt some people would disagree with me, and would never
dream of writing code without comprehensive test suites that back it up and
are known to have 100% coverage with every possible combination of features
toggled in or out. (If you really think you are in this position, I know a guy
who’d like to offer you an exclusive financial deal guaranteed to make you
rich, if you just send a 25K deposit up-front in unmarked, non-sequential
notes to his mailbox in Nigeria.)

What really bugs me is that this whole feature toggling premise seems to be
caused by the tail wagging the dog. Feature toggling is advocated as a way to
do continuous integration. CI is advocated as a way to avoid nightmare merges.
However, the existence of nightmare merges presupposes that you can have
multiple developers simultaneously working on the same part of your code,
making sufficiently intricate changes that merging will cause headaches, but
for different reasons and without being aware of each other. Otherwise, they
could just communicate effectively, and merge intelligently as they go along
if that makes sense. How can any development team possibly get into that
situation without some spectacular, fundamental failure of project management
and technical leadership? That kind of failure is essentially a social
problem, so it’s doubtful that any kind of technical solution could solve it
reliably, whether a branching model, or a CI-not-branching model, or any other
model for that matter.

------
dancecodes
Git branching and totally is really atomic. But sometime some other can remove
not owned code that seems as cause of integration error with his code. Well
and more its will pushed in mainstream and reported about success. At other
side the other developer will surprised. I hear about signed commits - hope
this help.

------
reinhardt
None. Continuous integration and feature flags FTW:
[http://code.flickr.net/2009/12/02/flipping-
out/](http://code.flickr.net/2009/12/02/flipping-out/)

~~~
voyou
Ah, feature flags. The "hack up your own substitute for version control" model
of version control.

------
seivan
I can really recommend Git Flow.

