Comments on: Git/Branch-Per-Feature – Composable Deployments/Releases?

By: David Alpert

David Alpert — Thu, 11 Mar 2010 22:11:36 +0000

This is largely the same pattern my current team is using with Subversion; we have a build branch off the trunk that maps to your staging branch and we branch feature branches off the build branch then merge back into the build branch as they are ready to deploy to stage for testing.

That said, I think most of those branches and merges would go much faster and more smoothly w/ git than w/ svn.

By: Jon Kruger

Jon Kruger — Tue, 09 Mar 2010 17:44:49 +0000

+1 to the article that Dugald posted. I modeled my Git workflow off of that post and it is going great.

By: Dugald

Dugald — Tue, 09 Mar 2010 16:12:24 +0000

Yes, that article does a great a job outlining how things fit together. We use it, and then branch per feature, merging back into develop. Then, other developers can just pull from develop and do the same. I also like master as always having stable releases and being the goto for that. Then, everything else is fluid and temporary.

By: Joey Beninghove

Joey Beninghove — Tue, 09 Mar 2010 16:01:22 +0000

Dugald,
Wow, that is a great article! Thanks! That model looks very attractive. I have thought about a using a long running “dev” branch somehow, but wasn’t sure how best to fit it into the flow. This helps explain it a lot.

By: Dugald

Dugald — Tue, 09 Mar 2010 15:30:09 +0000

One thing I miss from your setup is a long-running ‘development’ branch. I use this branch to branch off features and then merge them back into the ‘development’ branch. We then keep development and master as the common branches pushed/pulled among developers. Staging seems to be serving that purpose for you, but I prefer the methodology in this post: http://nvie.com/git-model , where releases are in a separate branch for the release, which is then merged back into development and master.

By: Jon Hilton

Jon Hilton — Tue, 09 Mar 2010 08:16:53 +0000

We’ve certainly seen benefits from approaching Git this way, especially as we also have TeamCity labelling builds for us.

The upshot is that if we have a problem with the deployed version (version number embedded in the dll) we can create a hotfix branch from that specific build without affecting any of our feature/master/staging branches.

The branch-per-feature approach also does a good job of ensuring developers work in a modular fashion rather than a scatter-gun, change twenty things at once assault on the code!