How to do a branch per task strategy with git

Question

Currently, my team is looking for an agile git branching strategy. I originally thought we could follow this article: http://nvie.com/posts/a-successful-git-branching-model/, but unfortunately we do pushes to production too often to work on a branch with multiple tasks in it until it is stable (the next release branch strategy). Also, there is often situations where issues that should only take a few days to finish take a while to resolve due to priories changing. Because we do not have the time to work on these long running tasks they sit in dev or a next release branch and give way to the possibility of breaking production.

I want to adopt a branch per task strategy and want to know how it has been done with git before. I'm not just talking about feature branches, but a branch for every individual task you are assigned. Also, there would be no dev branch since your task branches will be your dev branch. Having a develop branch entices developers to commit directly to that branch which leads to open issues in our main branch.

I came up with this:

I believe adopting this strategy will keep the main branch clean and will also account for when developers are not around to finish their tasks before we do a push to production.

The main idea behind it is that the main branch is a protected branch and there is no development branch. Since the main branch is protected it will force you to create a branch off of it for individual tasks. In order to merge back in you have to request a merge from the administrator. We will tag every release to production and hotfixes will also be branches off of the main branch. We have four test sites set up that we can use to test the different task branches.

I haven't seen any examples of this strategy just yet, so I was hoping to get some feedback on what I have here.

UPDATE

So I know its been a while since this question was posted, but if anyone is looking for a similar strategy it seems that GitHub has adopted it here.

Answer 1

The git flow model you mention is designed specifically to solve your problem :). Although it shows commits to develop, all tasks should be done in their own feature branch, and only merged back to develop once complete and tested. That way you know you can always release from develop (i.e. merge to master and tag), so it supports regular and continuous release.

Branch-per-task works really well with git flow because branching is cheap. We also use our issue numbers as prefixes, so git flow feature start PR-123_make-widget has a useable branch name but also highlights issue PR-123 in our JIRA.

Following the git-flow method as described above gives you a stable development branch (or maybe multiple stable development branches if you're working on a major new version branch as well as develop. You are also able to do hot-fixes which are applied directly to master and then merged back into develop.

For your 'request for merge', you could use pull requests (if you're using Github, Stash, Bitbucket, etc) or you could use a tool like Gerrit.

There's a reasonable argument that any branch which passes all tests should be merged back to develop automatically, in which case you could try doing per-commit micro reviews on feature branches. There are loads of options!

Update If you are going to persevere with your suggested model, I would recommend considering how your release cycle works. Does the release just involve tagging and pushing, or do you feature freeze for some time to carry out additional QA? Might you ever do that in the future? If the answer is 'yes' or 'maybe' then you shouldn't release from master, but should instead create a release branch, carry out your last minute fixes, and then tag and push. Don't forget to merge back as well though.

Update If you are employing a branch-per-task strategy it might appear that the master branch serves no real purpose. If you are doing continuous release, so every stable develop branch build is deployed to your production environment automatically, this is probably true. In an environment where a build is promoted to production, without a release phase, i.e. the promotion doesn't involve any additional commits the additional branch is possibly unnecessary. The real benefit of the develop/master branching strategy comes when you have a release phase where final release fixes (deployment issues, last minute bugs, etc.) and general housekeeping such as version number bumps are done in a transient release branch.

Using the release branch and then merging that to a master branch means you can continue to merge stable features back into develop even though your release isn't complete yet.

It's also quite nice to have single commit points on the master branch, with each commit representing a release, but that's a purely aesthetic justification so isn't really that valid :).

Answer 2

I want to adopt a branch per task strategy and want to know how it has been done with git before

Git lightweight branching has been specifically designed with exactly this in mind, you can and ideally should create branches for each individual topic.

The following is quite subjective. The successful branching model that you refer to is successful because its plain common sense (and the marketing of calling it successful to reassure the world that branching and merging isn't scary at all). My own evidence is anecdotal, but it stands to reason that everyone who used git on a large enough project with many developers naturally had release, develop, stage, featureX, featureY, etc branches, or variants of thereof, with a common and normalised flow between them.

Your flow, as charted, makes sense, and one shoe doesn't fit all - you shouldn't be afraid to deviate from a successful git branching model where necessary!

Notwithstanding, with every such flow the main question is what's your staging, QA and release strategy. Fixing bugs, developing features, whether on topic branches or common branches isn't much of an issue, code is just code. And git is very good at moving code around between branches, splitting it to new branches, rewinding to code's old state, etc.

So what's more of an issue is how do you plan to QA and release the code. What are your resource limitations? (Build times, webservers, embedded harnesses, test farms, CI build and test boxes, etc.) Just as an example, if branching and moving code around is cheap, but building or re-building a branch takes 8 hours, then having a branch per a minuscule change doesn't make sense. Your flow has to consider this to be a successful one.