Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
This course is a gateway to learning software version control (SVC), process management, and collaboration techniques. Author Michael Lehman reviews the history of version control and demonstrates the fundamental concepts: check-in/checkout, forking, merging, commits, and distribution. The choice of an SVC system is critical to effectively managing and versioning the assets in a software development project (from source code, images, and compiled binaries to installation packages), so the course also surveys the solutions available. Michael examines Git, Perforce, Subversion, Mercurial, and Microsoft Team Foundation Server (TFS) in particular, describing the appropriate use, features, benefits, and optimal group size for each one.
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.
There are currently no FAQs about Fundamentals of Software Version Control.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.