Branching is a source code management technique for enabling parallel development. When you branch, you create a code line that is essentially a copy of its parent. By keeping track of the ancestry of the new code line, you can identify what has changed since the branch point and apply changes from the branch to the parent code line and vice versa. A branch allows you to work on a variation of the code without immediately affecting—or being affected by—changes on the main code line. (Streamed Lines has a detailed description of other reasons for branching.)
Figure 1 illustrates some branching patterns. Assume that you are working on a main line, and you are scheduled to release version 1 in a week. At some point, you might decide that there are people on your team who can start working on a new feature for version 2 while the rest of the team finishes version 1. You can create a task branch, where a group of developers can work on the new code without interfering with the soon-to-be-released version 1. Once version 1 is ready to ship, you can create a release branch to deliver fixes for released software. In theory, the changes required to deliver the fix from a release branch will be smaller and more easily tested than if you were to attempt to deliver from the main development line. The team can address the problem to be fixed by committing changes to the branch without interfering with the work of the rest of team. You can then merge the task branch changes back into the main line so that everyone is working on one code stream again.
Without branching, it would be tricky for the team to work on two tasks at once. And, there are times when working on a branch can help you be more agile by enabling you to work around roadblocks and keep moving while other work is being completed. A branch allows you to get work done when your code and your processes make it difficult to make the related changes on the main code line.
Figure 1. Common branching patterns