Join Michael Lehman for an in-depth discussion in this video Branching and merging, part of Learning Software Version Control.
One of the most useful features of Software Version Control is called branching, but it's sometimes the most confusing. Some of the centralized systems make it somewhat complicated to merge two different branches together, so some people feel that branching is complex, but the branching part really couldn't be any easier. You start out with your main branch and your existing files, and you create a new branch, and now you have another set of identical files that you can make changes to. Because all branching means is that you're taking the current state of the repository and creating a new copy.
In the new branch, as opposed to the main branch--which is also sometimes called the trunk-- you can make any changes you want and they don't affect the product that is already working. This is a perfect sandbox in which you can experiment and you can refactor code. You can delete old unnecessary features and add brand-new ones. You really have full freedom to do anything you want to. In our example, a repository contains a file containing features A, B, and C. Once you branch you can see the main trunk still contains A, B, and C, and so does the branch.
Now, at T2 we may delete C and add feature D. And this doesn't have anything to do with what we can do in the main branch, where we might, for example, add feature F. And back in the branch we might delete feature B now and add feature E. And this is all without changing our main production code. In distributed systems such as Git and Mercurial, branching is actually really, really easy and cheap because it only really creates a 40-byte file, simply creating a new GUID, indicating a new path of changes, that doesn't actually make a separate copy of the files.
Hand in hand with branching is the reverse process, called merging. This allows you to take changes that you've made in a branch and add them back into the main trunk or into another branch. So let's take a look. We have our main branch, there is our main file, we'll create a new branch, as we did before, feature 1, and we'll take the copy and we'll add feature D. And now back in the main branch, we'll add feature F. And here in parallel, we're going to add feature E in the feature 1 branch.
So as you do these changes, you might decide you like both sets of changes and want to combine them. In this case, we don't have any conflicting changes because we didn't delete anything, we just added. So now we ask our Version Control system to merge the two branches together, and now we end up with a new file 1, checked into the main branch with all the features from both the main branch and the feature branch. When there are conflicts, such as two changes in each branch that effectively did the same thing, for example, if we deleted feature B in both the main branch and the feature 1 branch, the Version Control Software sometimes can't tell exactly what you meant to do and so therefore it declares a merge conflict and requests that you resolve this manually.
What happens is it brings up a differencing tool to allow you the human to look at the lines that have changed in context and make a decision of whether you want to take the version from the main branch or the version from your feature branch or both changes. On Windows, I highly recommend a tool called Beyond Compare to use as your differencing tool. On the Mac and Linux, there are many, many different tools that will allow you to do this effectively. One of the great benefits of Version Control Software beyond differencing is that not only will it require you to see the various changes that you've made, it will allow you to see the commit messages to determine the intent of the developer who made the changes so that you can understand how to merge the two branches together effectively.
Branching and Merging are the two most powerful features in any Version Control system, and when used with care and thought, they can be the most powerful feature that you can use, because they allow you to experiment or work in parallel and then bring your work back together again at the end to create a completed product or project. So use branches whenever you want to be sure that the main branch or any other branch stays intact.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you