What git branching models actually work?

http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work

by ColinWright • 13 years ago

70 39 13 years ago

calpaterson5• 13 years ago

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

flexd• 13 years ago

Why can't you just run continuous integration on all the branches?

baq• 13 years ago

have fun handling 100x build volume...

mullr2• 13 years ago

Because that would be continuous builds on unintegrated-branches.

The point of continuous integration is that everybody is reconciling their work with everybody else's all the time, thus helping you find nasty integration surprises early and while you can still do something about them.

aidenn04• 13 years ago

That's not CI. Example with 3 branches:

   Trunk
   Feature1
   Feature2

If you nightly merge Trunk into Feature1 and nightly merge Trunk into Feature2 and test all 3 branches, you still haven't tested the integration of Feature1 and Feature2. With enough developers working on enough features the odds that at least one pair of features won't work together approaches unity.

People have tried all sorts of methodology and design, &ct. to try and keep this from happening, and they haven't succeeded yet. On the other hand, if feature branches get merged into trunk as soon as they aren't completely broken, and with a way to disable them, then you will very quickly discover that the features don't play well together.

sgk284• 13 years ago

You seem to imply that working on a feature branch means you wait until you're finished the feature to try and merge your changes, which would be an absolutely insane workflow in any sizable org.

While working on a feature branch, you should be pulling in the latest from origin/master on a pretty regular basis such that you never have a big merge. You should be merging early and merging often.

The benefit here is that you get to work on functionality without hindering anyone else (by putting the codebase in a functioning, but transitional state), while getting to integrate on your own schedule. By the time it's ready to push to everyone else, there should be no merge. It'll be a fast-forward.

Feature branches, with a policy of merge early and often, make life substantially easier than traditional continuous integration workflows. Having everybody checking in in-progress work to the same place is a nightmare.

When I'm working on a feature, I want to be able to commit in small bite-sized chunks that allow me to explore solutions, rollback changes, rebase on-top of whatever I want, and ultimately squash my work into a single cleanly merged chunk of work. Any other workflow is limiting and restricting many of the benefits of git.

calpaterson5• 13 years ago

I think we have a language difference: when I say "merging" I don't mean, "incorporate changes from trunk" I mean "you branch and trunk become the same".

getting to integrate on your own schedule

Essentially, this is what I oppose, for the reasons I described originally.

Any other workflow is limiting and restricting many of the benefits of git.

The point of git is to make your workflow better, the point of your workflow is not to make git better. Yeah "branching is easy", and that's good, but it doesn't necessarily mean that you want to start using branches heavily (especially long-lived ones). Bad version control systems were only part of the reason to avoid branches.

lmm• 13 years ago

The problem I have with the CI approach is that it means you have to push a lot more of your program's integration to runtime, which is a worse place to detect failures. When adding a new feature ideally one writes the use case, which won't compile, and then implements the things it calls, which won't compile, and so on - if you're using types properly, then once you've added the front of a new feature your code won't compile until the entire feature implementation is correct. This is a wonderful way to code, eliminating huge classes of potential bugs, but CI seems fundamentally incompatible with it.

calpaterson5• 13 years ago

Ok, so first of all, not everyone uses types and I for one think it is ok to use dynamically typed languages.

Second, I think you have a different vision of CI from me (maybe more frequent). I'm not advocating pushing code that is broken, I'm advocating pushing code that is working (but maybe is incomplete).

alinajaf• 13 years ago

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• 13 years ago

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.

aidenn04• 13 years ago

I have seen this sort of thing work really well. You need really good integration tests, and you need to convince developers that yes, they really should check in half-finished work, appropriately disabled. We used cvs, then subversion on that project, so didn't have some of the issues that git had.

Occasionally there are still feature branches, though they more often start out more as prototype/exploratory branches, that involve significant architectural changes, and when it's a clear win, it gets merged in.

And yes, banning local branches is stupid; uncommitted code on a developers machine happens instead, which is strictly worse than having a local branch with meaningful commits.

kristoffer• 13 years ago

For me the optimal (current best thinking) way of doing continuous integration is to consider the "master" branch to be the integration branch. All tests should always be working here. It should not be possible to deliver a feature branch which breaks the regression tests on master.

Thus I don't like unnecessary merges of unfinished work, it increases the risk for breaking the tests, which will slow down development.

If you rebase your feature branch continuously then you achieve what you are asking for without merging unfinished work.

akie• 13 years ago

I really like this one - http://nvie.com/posts/a-successful-git-branching-model/

smackay• 13 years ago

This also works for me for the following reasons:

* Simple but quite expressive, covering a large number of use-cases.

* Reliable - there's not much in the way of rope to hang yourself.

* It's easy to explain to people new to git or software development.

It certainly works well for small teams, but I'm not sure how far it would scale - probably quite well as long as there are not too many deviations.

Also as a starting point for development with git it's hard to fault. As you become more familiar/confident you can start to add more complex commands ( rebasing history, etc.) and build quite a sophisticated workflow.

UPDATE: As to the why branch just use continuous integration debate, well continuous integration works just fine as long as your window to deployment is short (hours or a small number of days). With anything that takes a little longer or involves database migrations then branching in some form is still required. So rather than being an either/or situation they really just overlap in practice and one does not preclude the other.

geocar4• 13 years ago

I really don't, because it glosses over what I find is the most important part: releasing.

I find that because releasing is handwaved away, people find their own way which often sounds like "this is ready, I've pushed to Iteration 16" instead of "this is ready, please pull."

That post could really be fixed by deleting the "develop" branch.

choult2• 13 years ago

The thing about develop is you should consider it at least a little volatile; you create the release branches to harden it before the merge into master (and back into develop).

Using a script set such as git-flow really helps manage this without worrying too much.

My only concern about using git-flow was that it was only really suitable on one repo; it doesn't really automate the transmission of the various branches to other repos. But then hubflow[1] sorts that one out.

[1] http://datasift.github.io/gitflow/

skore• 13 years ago

I've been using it for about a year now and it has worked absolute wonders for me. I'm currently building a package manager/deployment tool/automatic updater around the concept and I'm enjoying the hell out of it. My focus is on applications that a client (typically site developers) installs, so this might be different from other developers here.

The main benefit of Nvies Branching Model is that it reduces anxiety.

Since you keep both fixes and features on separate branches, you minimize the anxiety of "can I do this now?" and "wouldn't this also break that". Instead, you just push and push and merge and worry later. You can work on several bugs for several clients - at the same time. Zero anxiety about fixing one thing for one client that breaks another thing for another client.

The golden rule is simply that you don't merge to master (or, for that matter, to a release-x branch) what isn't well tested to be good on a feature-x or hotfix-x branch.

So using that thing I currently build[0], I can just push-to-deploy whatever I'm working on without being afraid that I break clients who have automatic updates enabled. With this strategy, it's up to the clients: If they subscribe to a development or feature branch, it's understood that things could break. I simply have to be careful what touches master and that's it. (And in most cases, clients only subscribe to other branches in a support context, anyways.)

Finally - Yes, there is a certain overhead, but you can use git-flow[1] on the command line to keep that down to a minimum.

[0] http://mangrove.valanx.org [caution: WIP]

[1] https://github.com/nvie/gitflow

jedbrown2• 13 years ago

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...

aidenn04• 13 years ago

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

VLM2• 13 years ago

I've been running with this for about a year. No one has mentioned self discipline as an issue.

Its strongly tempting to "change one little thing" outside the model. Yes yes I know "git flow hotfix" blah blah blah its only a dozen command lines or whatever. But sometimes its so tempting just to checkout master, fix one character, and push it.

The problem isn't so much dumb little typo-fixes that should have been caught in "release" testing, if not feature or develop, or keeping "real" huge changes in the git-flow, but those annoying border cases where both could be argued to be wrong or right.

One solution is to go hard core fundamentalist and demand everything go with the git-flow never outside the process, although that will "waste" some time.

geocar4• 13 years ago

although that will "waste" some time.

Not so much, although it wastes someone's time.

Someone has to be the release manager, and git-flow gives them only one tool: To reject the release by pushing back.

If they eliminate the develop branch and merge the features directly into the release branch (whenever they attempt to perform a release) then if something goes wrong, they can simply drop one of the features and re-build their branch.

reinhardt• 13 years ago

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

voyou• 13 years ago

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

seivan• 13 years ago

I can really recommend Git Flow.

dancecodes• 13 years ago

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.

What git branching models actually work?

Related Stories