[ACCEPTED]-When should you branch?-branch
In general term, the main purpose of branching 47 (a VCS - Version Control System - feature) is 46 to achieve code isolation.
You have at least one branch, which 45 can be enough for sequential development, and 44 is used for many tasks being recording (committed) on 43 that same unique branch.
But that model 42 shows quickly its limit:
When you have a 41 development effort (refactoring, evolution, bug-fixes, ...) and 40 you realize you cannot safely make those 39 changes in the same branch than your current 38 development branch (because you would break 37 API, or introduce code that would break 36 everything), then you need a another branch.
(To isolate that 35 new code for the legacy one, even though 34 the two code sets will be merge later on)
So 33 that is your answer right there:
You should branch whenever you cannot pursue and record two development efforts in one branch.
(without 32 having an horribly complicated history to 31 maintain).
A branch can be useful even if 30 you are the only one working on the source 29 code, of if you are many.
But you should 28 not make "one branch per developer":
the "isolation" purpose is made to isolate a development effort (a 27 task which can be as general as "let's 26 develop the next version of our software" or 25 as specific as "let's fix bug 23"),
not to isolate a "resource".
(a 24 branch called "VonC" means nothing 23 to another developer: What if "VonC" leaves 22 the project? What are you supposed to do 21 with it?
a branch called "bugfix_212" can 20 be interpreted in the context of a bug tracking 19 system for instance, and any developer can 18 use it with at least some idea about what 17 he is supposed to do with it)
A branch is not a tag (SVN is a 16 Revision System which tries to propose versioning features like branching and tagging through 15 directories with cheap file copy: that does 14 not mean a tag is a branch)
To define a branch 13 means also defining a merge workflow: you need to know 12 where to merge your branch when you are 11 done with it.
For that, the chapter 7 of 10 Practical Perforce (Laura WINGERD - O'Reilly) is 9 a good introduction (VCS agnostic) to merge 8 workflow between different kind of branches: " "How Software Evolves" (pdf)
It 7 defines the term codeline (branch which records 6 significant evolution steps of the code, either 5 through tags at certain points, or through 4 important merge back to the branch)
It introduce 3 the mainline model (a central codeline to 2 record releases), and describes various 1 purposes for branching:
- Active development streams: an persistent codeline when sequential various developments take place
- tasks branches: short-lived branches for more specific task (bug-fix is a classic one, but you can also define a branch for a merge effort you know to be complex to complete: you can merge, commit and test in that task branch without introducing problem for the main current development branch)
- staging branch: for preparing a release, with some pre-production specific data or config files.
- Private branches, ad hoc branches, and sparse branches: for very small tasks, just to be able to commit some work in progress without waiting for formal completion or test review.
That allows to "commit early, commit often".
Other interesting concepts around VCS: Basics concepts
(about ClearCase originally, but also valid for any VCS)
There are several uses for branching. One 16 of the most common uses is for separating 15 projects that once had a common code base. This 14 is very useful to experiment with your code, without 13 affecting the main trunk.
In general, you 12 would see two branch types:
Feature Branch: If 11 a particular feature is disruptive enough 10 that you don't want the entire development 9 team to be affected in its early stages, you 8 can create a branch on which to do this 7 work.
Fixes Branch: While development continues 6 on the main trunk, a fixes branch can be 5 created to hold the fixes to the latest 4 released version of the software.
You may 3 be interested in checking out the following 2 article, which explains the principles of 1 branching, and when to use them:
All the 21th century SCMs are telling you:
Branch for every task you've to work on, no 5 matter whether this is a new feature, a 4 bugfix, a test, whatever. This is called 3 topic branch, and it changes the way you 2 work with your SCM.
- Better isolation
- Better traceability -> you associate tasks with branches, not individual changesets, which makes you free to commit as many times as you want and doesn't impose a limit like "one checkin per task".
- Tasks are independent (normally starting from a stable baseline, so you only focus on your code, not on fixing bugs from your folks), and you can choose whether you want to integrate them at some point or later, but they're always under version control
- You can review code easily (from the version control, not pre-commit bullshit) before hitting the main line
Tools that can 1 do it:
Tools that CAN'T do it:
It also depends on the SCM tool you are 14 using. Modern SCMs (git, mercurial, etc.) make 13 it increasingly easy to create and destroy 12 branches whenever needed. This allows you 11 to, for example, make one branch per bug 10 that you are working on. Once you merge 9 your results into the trunk, you discard 8 the branch.
Other SCMs, for example subversion 7 and CVS, have a much "heavier" branching 6 paradigm. That means, a branch is considered 5 appropriate only for something bigger than 4 a twenty-something-line patch. There, branches 3 are classically used to track entire development 2 tracks, like a previous or future product 1 version.
When you need to make significant and/or 3 experimental changes to your codebase, particularly 2 if you want to commit intermediate changes, without 1 affecting trunk.
It depends on what type of SCM you're using.
In 24 the newer distributed versions (like git 23 and mercurial), you're creating branches 22 all the time and remerging anyway. I'll 21 often work on a separate branch for a while 20 just because someone's broken the build 19 on the mainline, or because the network's 18 down, and then merge changes back in later 17 when it's fixed, and it's so easy to do 16 that it's not even annoying.
The document 15 (short and readable) that most helped me 14 understand what was going in in the distributed 13 systems is: UnderstandingMercurial.
In the older systems with a 12 central repository, (like CVS, SVN and ClearCase), then 11 it's a much more serious issue which needs 10 to be decided at a team level, and the answer 9 should be more like 'to maintain an old 8 release whilst allowing development to continue 7 on the main line', or 'as part of a major 6 experiment'.
The distributed model is much 5 better, I think, and lacking only nice graphical 4 tools to become the dominant paradigm. However 3 it's not as widely understood, and the concepts 2 are different, so it can be confusing for 1 new users.
I find the advice from Laura Wingerd & Christopher 3 Seiwald at Perforce is really concise and 2 useful:
* Branch only when necessary. * Don't copy when you mean to branch. * Branch on incompatible policy. * Branch late. * Branch, instead of freeze.
See http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf for a detailed explanation of 1 each of them and other best practice.
There are various purposes for branching:
- Feature/bug branches. Dynamic and active branches that get moved back into the trunk when the feature/bugfix is complete.
- Static branches (tags in Subversion, though in essence just a 'normal branch'). They provide a static snapshot of say, a release. Even though they could be worked on, they remain untouched.
The need for branching may also arise:
When you need to make changes, based on 10 your current branch, not destined for the 9 next release from that branch (and not before).
For 8 example, we work on trunk usually. Around 7 the time of release, someone's going to 6 need to make a change that we don't want 5 in the current release (it may be before 4 release, at the moment it's usually after 3 release). This is when we branch, to put 2 the release on its own branch and continue 1 development for the next release on trunk.
Whenever you feel like it.
You probably won't 9 very frequently if you work with a centralized 8 SCM since the branches are part of the official 7 repository, and that doesn't really invite 6 much experimentation, not to mention that 5 merges really hurt.
OTOH, there's no technical 4 difference between a branch and a checkout 3 in distributed SCMs, and merges are a lot 2 easier. You'll feel like branching a whole 1 lot more often.
Leaving all the technicalities aside.....
Branch 5 when you know its easier to merge back!
Keeping 4 in mind that merging will always be effected 3 with how the work is carried out in a project.
Once 2 this achieved all the other tertiary issues 1 will come in to play.
More Related questions