A feature branch is the sort of
branch that's been the dominant example in this chapter (the
one you've been working on while Sally continues to work on
/trunk). It's a temporary branch created
to work on a complex change without interfering with the
/trunk. Unlike release
branches (which may need to be supported forever), feature
branches are born, used for a while, merged back to the trunk,
then ultimately deleted. They have a finite span of
Again, project policies vary widely concerning exactly
when it's appropriate to create a feature branch. Some
projects never use feature branches at all: commits to
/trunk are a free-for-all. The
advantage to this system is that it's simple—nobody
needs to learn about branching or merging. The disadvantage
is that the trunk code is often unstable or unusable. Other
projects use branches to an extreme: no change is
ever committed to the trunk directly.
Even the most trivial changes are created on a short-lived
branch, carefully reviewed, and merged to the trunk. Then
the branch is deleted. This system guarantees an
exceptionally stable and usable trunk at all times, but at
the cost of tremendous process overhead.
Most projects take a middle-of-the-road approach. They
commonly insist that
/trunk compile and
pass regression tests at all times. A feature branch is
only required when a change requires a large number of
destabilizing commits. A good rule of thumb is to ask this
question: if the developer worked for days in isolation and
then committed the large change all at once (so that
/trunk were never destabilized), would it
be too large a change to review? If the answer to that
question is “yes,” then the change should be
developed on a feature branch. As the developer commits
incremental changes to the branch, they can be easily reviewed
Finally, there's the issue of how to best keep a feature branch in “sync” with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.
This situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch.
At some point, you'll be ready to merge the
“synchronized” feature branch back to the trunk.
To do this, begin by doing a final merge of the latest trunk
changes to the branch. When that's done, the latest versions
of branch and trunk will be absolutely identical except for
your branch changes. So in this special case, you would merge
back with the
$ cd trunk-working-copy $ svn update At revision 1910. $ svn merge --reintegrate http://svn.example.com/repos/calc/branches/mybranch@1910 U real.c U integer.c A newdirectory A newdirectory/newfile …
Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy. After all, what else is a working copy but a very shallow private branch? It's a branch that's only capable of storing one change at a time.