• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Common Branching Patterns
Version control is most often used for software development,so here's a quick peek at two of the most commonbranching/merging patterns used by teams of programmers.If you're not using Subversion for software development, feelfree to skip this section. If you're a software developer usingversion control for the first time, pay close attention, asthese patterns are often considered best practices byexperienced folk. These processes aren't specific toSubversion; they're applicable to any version control system.Still, it may help to see them described in Subversion terms.
Release Branches
Most software has a typical lifecycle: code, test, release,repeat. There are two problems with this process. First,developers need to keep writing new features while quality-assurance teams take time to test supposedly-stableversions of the software. New work cannot halt while thesoftware is tested. Second, the team almost always needs tosupport older, released versions of software; if a bug isdiscovered in the latest code, it most likely exists in releasedversions as well, and customers will want to get that bugfixwithout having to wait for a major new release.Here's where version control can help. The typical procedurelooks like this:
•
Developers commit all new work to the trunk.
Day-to-day changes are committed to
 /trunk 
: new features,bugfixes, and so on.
•
The trunk is copied to a “release” branch.
When theteam thinks the software is ready for release (say, a 1.0release), then
 /trunk 
might be copied to
 /branches/1.0
.
•
Teams continue to work in parallel.
One team beginsrigorous testing of the release branch, while anotherteam continues new work (say, for version 2.0) on
 /trunk 
. If bugs are discovered in either location, fixesare ported back and forth as necessary. At some point,
 
however, even that process stops. The branch is“frozen” for final testing right before a release.
•
The branch is tagged and released.
When testing iscomplete,
 /branches/1.0
is copied to
 /tags/1.0.0
as areference snapshot. The tag is packaged and releasedto customers.-
•
The branch is maintained over time.
While workcontinues on
 /trunk 
for version 2.0, bugfixes continue tobe ported from
 /trunk 
to
 /branches/1.0
. When enoughbugfixes have accumulated, management may decideto do a 1.0.1 release:
 /branches/1.0
is copied to
 /tags/1.0.1
, and the tag is packaged and released. This entire process repeats as the software matures: whenthe 2.0 work is complete, a new 2.0 release branch iscreated, tested, tagged, and eventually released. After someyears, the repository ends up with a number of releasebranches in “maintenance” mode, and a number of tagsrepresenting final shipped versions.
Feature Branches
A
feature branch
is the sort of branch that's been thedominant example in this chapter, the one you've beenworking on while Sally continues to work on
 /trunk 
. It's atemporary branch created to work on a complex changewithout interfering with the stability of 
 /trunk 
. Unlike releasebranches (which may need to be supported forever), featurebranches are born, used for a while, merged back to thetrunk, then ultimately deleted. They have a finite span of usefulness.Again, project policies vary widely concerning exactly whenit's appropriate to create a feature branch. Some projectsnever use feature branches at all: commits to
 /trunk 
are afree-for-all. The advantage to this system is that it's simple—nobody needs to learn about branching or merging. Thedisadvantage is that the trunk code is often unstable orunusable. Other projects use branches to an extreme: nochange 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 branchis deleted. This system guarantees an exceptionally stableand usable trunk at all times, but at the cost of tremendousprocess overhead.Most projects take a middle-of-the-road approach. Theycommonly insist that
 /trunk 
compile and pass regressiontests at all times. A feature branch is only required when achange requires a large number of destabilizing commits. Agood rule of thumb is to ask this question: if the developerworked for days in isolation and then committed the largechange all at once (so that
 /trunk 
were never destabilized),would it be too large a change to review? If the answer tothat question is “yes”, then the change should be developedon a feature branch. As the developer commits incrementalchanges to the branch, they can be easily reviewed bypeers.Finally, there's the issue of how to best keep a featurebranch in “sync” with the trunk as work progresses. As wementioned earlier, there's a great risk to working on abranch for weeks or months; trunk changes may continue topour in, to the point where the two lines of developmentdiffer so greatly that it may become a nightmare trying tomerge the branch back to the trunk. This situation is best avoided by regularly merging trunkchanges to the branch. Make up a policy: once a week,merge the last week's worth of trunk changes to the branch. Take care when doing this; the merging needs to be hand-tracked to avoid the problem of repeated merges (asdescribed inthe section called “Tracking Merges Manually”). You'll need to write careful log messages detailing exactlywhich revision ranges have been merged already (asdemonstrated inthe section called “Merging a Whole Branchto Another”). It may sound intimidating, but it's actuallypretty easy to do.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...