What is a Branch in software development? A branch is what happens when your development team needs to work on two distinct copies of a project at the same time. This is best explained by citing a common example.
Suppose your development team has just finished and released version 1.0 of UltraHello, your new flagship product, developed with the hope of capturing a share of the rapidly growing market for "Hello World" applications.
But now that 1.0 is out the door, you have a new problem you have never faced before. For the last two years, everybody on your team has been 100% focused on this release. Everybody has been working in the same tree of source code. You have had only one "line of development," but now you have two:
- Development of 2.0 . You have all kinds of new features which just didn't make it into 1.0, including "multilingual Hello," DirectX support for animated Hellos, and of course, the ability to read email
- Maintenance of 1.0 . Now that real customers are using UltraHello, they will probably find at least one bug your testing didn't catch. For bug fixes or other minor improvements requested by customers, it is quite possible that you will need to release a version 1.0.1.
It is important for these two lines of development to remain distinct. If you release a version 1.0.1, you don't want it to contain a half-completed implementation of a 2.0 feature. So what you need here is two distinct source trees so your team can work on both lines of development without interfering with each other.
The most obvious way to solve this problem would simply be to make a copy of your entire source control repository. Then you can use one repository for 1.0 maintenance and the other repository for 2.0 development. I know people who do it this way, but it's definitely not a perfect solution.
The two-repository approach becomes disappointing in situations where you want to apply a change to both trees. For example, every time we fix a bug in the 1.0 maintenance tree, we probably also want to apply that same bug fix to the 2.0 development tree. Do we really want to have to do this manually? If the bug fix is a simple change, like fixing the incorrect spelling of the word "Hello," then it won't take a programmer very long to make the change twice. But some bug fixes are more involved, requiring changes to multiple files. It would be nice if our source control tool would help. A primary goal for any source control tool should be to help software teams be more concurrent, everybody busy, all at the same time, without getting in each other's way.
To address this very type of problem, source control tools support a feature which is usually called "branching." This terminology arises from the tendency of computer scientists to use the language of a physical tree every time hierarchy is involved. In this particular situation, the metaphor breaks down very quickly, but we keep the name anyhow.
A somewhat better metaphor happens when we envision a nature path which forks into two directions. Before the fork, there was one path. Now there are two, but they share a common history. When you use the branching feature of your source control tool, it creates a fork in the path of your development progress. You now have two trees, but the source control has not forgotten the fact that these two trees used to be one. For this reason, the SCM tool can help make