When should you branch?

 

在使用SCM系统时，您应该何时分支？

There are several uses for branching. One of the most common uses is for separating projects that once had a common code base. This is very useful to experiment with your code, without affecting the main trunk.

In general, you would see two branch types:

  • Feature Branch: If a particular feature is disruptive enough that you don't want the entire development team to be affected in its early stages, you can create a branch on which to do this work.

  • Fixes Branch: While development continues on the main trunk, a fixes branch can be created to hold the fixes to the latest released version of the software.

    • You may be interested in checking out the following article, which explains the principles of branching, and when to use them:

  • Ned Batchelder - Subversion branching quick start

    • In general term, the main purpose of branching (a VCS - Version Control System - feature) is to achieve code isolation .

    You have at least one branch, which can be enough for sequential development, and is used for many tasks being recording (committed) on that same unique branch.

    But that model shows quickly its limit:

    When you have a development effort (refactoring, evolution, bug-fixes, ...) and you realize you cannot safely make those changes in the same branch than your current development branch (because you would break API, or introduce code that would break everything), then you need a another branch.
    (To isolate that new code for the legacy one, even though the two code sets will be merge later on)

    So that is your answer right there:
    You should branch whenever you cannot pursue and record two development efforts in one branch.
    (without having an horribly complicated history to maintain).

    A branch can be useful even if you are the only one working on the source code, of if you are many.
    But you should not make "one branch per developer":
    the "isolation" purpose is made to isolate a development effort (a task which can be as general as "let's develop the next version of our software" or as specific as "let's fix bug 23"),
    not to isolate a "resource" .

    (a branch called "VonC" means nothing to another developer: What if "VonC" leaves the project? What are you supposed to do with it?
    a branch called "bugfix_212" can be interpreted in the context of a bug tracking system for instance, and any developer can use it with at least some idea about what he is supposed to do with it)

    A branch is not a tag (SVN is a Revision System which tries to propose versioning features like branching and tagging through directories with cheap file copy: that does not mean a tag is a branch)

    To define a branch means also defining a merge workflow : you need to know where to merge your branch when you are done with it.
    For that, the chapter 7 of Practical Perforce (Laura WINGERD - O'Reilly) is a good introduction (VCS agnostic) to merge workflow between different kind of branches: " " How Software Evolves " (pdf)

    It defines the term codeline (branch which records significant evolution steps of the code, either through tags at certain points, or through important merge back to the branch)

    It introduce the mainline model (a central codeline to record releases), and describes various 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)

    All the 21th century SCMs are telling you:

    Branch for every task you've to work on, no matter whether this is a new feature, a bugfix, a test, whatever. This is called topic branch, and it changes the way you work with your SCM.

    You get:

  • 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 do it:

  • Git
  • Mercurial
  • Plastic SCM

    • Tools that CAN'T do it:

  • SVN
  • CVS
  • VSS
  • TFS
  • Perforce
    • 链接地址: http://www.djcxy.com/p/45044.html

    上一篇: mercurial的最佳实践：分支与克隆以及部分合并？

    下一篇: 你应该什么时候分支？