Comments on: When to branch your code http://www.stevideter.com/2008/04/23/when-to-branch-your-code/ Technology, code, and thoughts by Stevi Deter Thu, 15 Dec 2011 15:20:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Steve http://www.stevideter.com/2008/04/23/when-to-branch-your-code/comment-page-1/#comment-17 Steve Thu, 24 Apr 2008 02:19:42 +0000 http://www.stevideter.com/2008/04/23/when-to-branch-your-code/#comment-17 My experience over the past 10+ years is with the CVS/SVN set. I've settled on basically not branching unless necessary with them. For most "move fast, get it done" projects, that means you might have a dev+qa+staging branch and a live branch. For projects that need more control, you'd have one branch per change request (2d-3w of work), but merge behavior gets murky after dev. QA folks would probably use the change request branch, then it's merged into a UAT branch for UAT, and then merged into staging to allow eventual launch. This is more pain than the basic branching, but also falls apart if the client changes their minds and wants to launch something different than what was dev'd or uat'd ... or if there are significant changes in UAT. I'm playing around with git as a different approach. In git, individual commits can be merged separately between branches, so you can easily "rebase" (i.e. bring arbitrary changes from trunk back into a branch) at will, and merge back to trunk, without causing undue conflicts. It could have the effect of having us branch once per change or once per ticket ... we'll see. My experience over the past 10+ years is with the CVS/SVN set. I’ve settled on basically not branching unless necessary with them. For most “move fast, get it done” projects, that means you might have a dev+qa+staging branch and a live branch.

For projects that need more control, you’d have one branch per change request (2d-3w of work), but merge behavior gets murky after dev. QA folks would probably use the change request branch, then it’s merged into a UAT branch for UAT, and then merged into staging to allow eventual launch. This is more pain than the basic branching, but also falls apart if the client changes their minds and wants to launch something different than what was dev’d or uat’d … or if there are significant changes in UAT.

I’m playing around with git as a different approach. In git, individual commits can be merged separately between branches, so you can easily “rebase” (i.e. bring arbitrary changes from trunk back into a branch) at will, and merge back to trunk, without causing undue conflicts. It could have the effect of having us branch once per change or once per ticket … we’ll see.

]]>