GNU Info

(cvsbook.info)Some Principles For Working With Branches

---

Next: Merging Repeatedly Into The Trunk Up: Going Out On A Limb (How To Work With Branches And Survive)

---

Enter node , (file) or (file)node

Some Principles For Working With Branches
-----------------------------------------

To work successfully with branches, your development group should adhere
to these principles:

   * Minimize the number of branches active at any one time.  The more
     branches under development at the same time, the more likely they
     are to conflict when merged into the trunk.  In practical terms,
     the way to accomplish this is to merge as frequently as you can
     (whenever a branch is at a stable point) and to move development
     back onto the trunk as soon as feasible.  By minimizing the amount
     of parallel development going on, everyone is better able to keep
     track of what's going on on each branch, and the possibility of
     conflicts on merge is reduced.

     This does not mean minimizing the absolute number of branches in
     the project, just the number being worked on at any given time.

   * Minimize the complexity - that is, the depth - of your branching
     scheme.  There are circumstances in which it's appropriate to have
     branches from branches, but they are very rare (you may get
     through your entire programming life without ever encountering
     one).  Just because CVS makes it technically possible to have
     arbitrary levels of nested branching, and to merge from any branch
     to any other branch, doesn't mean you actually want to do these
     things.  In most situations, it's best to have all your branches
     rooted at the trunk and to merge from branch to trunk and back out
     again.

   * Use consistently named tags to mark all branch and merge events.
     Ideally, the meaning of each tag and its relationship to other
     branches and tags should be apparent from the tag name.  (The
     point of this will become clearer as we go through the examples.)


With those principles in mind, let's take a look at a typical branch
development scenario.  We'll have jrandom on the trunk and qsmith on the
branch, but note that there could just as well be multiple developers on
the trunk and/or on the branch.  Regular development along either line
can involve any number of people; however, the tagging and merging are
best done by one person on each side, as you'll see.