What Are Branches in Software Development?



As you make changes in one or both of these folders, they diverge, but they continue to share a common history.

The Pitiful Lives of Nelly and Eddie

In order to use your source control tool most effectively, you need to develop just the right amount of fear of branching.  This delicate balance seems to be very difficult to find.  Most people either have too much fear or not enough.

Nelly is an example of a person who has too much fear of branching.  Nelly has a friend who has a cousin with a neighbor who knows somebody whose life completely fell apart after they tried using the branch and merge features of their source control tool.  So Nelly refuses to use branching at all.  In fact, she wrote a 45-page policy document which requires her development team to never use branching, because after all, "it's not safe." 

So Nelly's development team goes to great lengths to avoid using branching, but eventually they reach a point where they need to do concurrent development.  When this happens, they do anything they can to solve the problem, as long as it doesn't involve the word "branch."  They fork a copy of their tree and begin working with two completely separate repositories.  When they need to make a change to both repositories, they simply make the change by hand, twice.

Best Practice: Don't be Afraid of Branches

If you're doing parallel development, let your source control tool help. That's what it was designed to do.

Obviously these people are still branching, but they keep Nelly happy by never using "the b word."  These folks are happy, and we should probably just leave them alone, but the whole situation is kind of sad.  Their source control tool has features which were specifically designed to make their lives easier.

At the other end of the spectrum is Eddie, who uses branching far too often.  Eddie started out just like Nelly, afraid of branching because he didn't understand it.  But to his credit, Eddie overcame his fear and learned how powerful branching and merging can be.

And then he went off the deep end.

After he tried branching and had a good first experience with it, Eddie now uses it all the time.  He sometimes branches multiple times per week.  Every time he makes a code change, he creates a private branch. 

Eddie arrives on Monday morning and discovers that he has been assigned bug 7136 (In the Elbonian version, the main window is too narrow because the Elbonian language requires 9 words to say "Hello World.")  So Eddie sits down at his desk and begins the process of fixing this bug.  The first thing he does is create a branch called "bug_7136."  He makes his code change there in his "private branch" and checks it in.  Then, after verifying that everything is working okay, he uses the Merge Branches feature to migrate all changes from the trunk into his private branch, just to make sure his code change is compatible with the very latest stuff.  Then he runs his test suite again.  Then he notices that the repository has changed yet again, then he does this loop once more.  Finally, he uses Merge Branches to apply his code fixes to the trunk.  Then he grabs a copy of the trunk code, builds it and runs the test suite to verify that he didn't accidentally break anything.  When at last he is satisfied that his code change is proper, he marks bug 7136 as complete.  By now it is Friday afternoon at 4:00pm, and there's no point

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.