Viewers: in countries Watching now:
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.
Before we proceed into talking more about centralized and distributed version control, it's time to add a few more terms to our lexicon. Here is the terms we've already discussed: repository, the database where your changes are tracked; working set, your local files with potential changes not yet in the repository; add and check in, ways of getting data in to the repository; check-out and update, ways of getting data from the repository into your working set; and revert or rollback, ways of updating your working set to match specific versions of the repository.
Distributed Repository Systems have the ability to take the contents of an entire repository, or the contents of a particular changeset, and send it to other users collaborating on the same project. When sending changes from one repository to another, you can do it via two methods, one is to use a method which uses HTTP or SSH to communicate the information to a remote server, the other is a way of extracting data from a repository to be able to send by email. So, when sending changes from one repository to another repository on a server, the terms are called push and pull.
Push sends the changes from your repository to the server's repository, and pull gets the changes from the server and adds them to your local repository. As I said, this is almost often done via a server listing on HTTP or via SSH. If you wish to send your changes privately using email, you can do the same thing, but the terms are called import and export. You export from a repository which extracts the changes from your repository and puts them in a file that you can send as an attachment, and conversely, import allows you to take that file that somebody else sends you as an attachment and update your local repository.
One of the most important features in a Version Control Software is the ability to name the specific state of a repository. This, as I said before, is called tagging or labeling. This allows you to say all the files that I have in this particular repository ,or all the files that I have in this project in a repository or in a well-known state, and I want to be able to get back to the state later. For example, when you ship version 1 before you begin to work on version 2, and 2 months later your customers says I need to make a change in version 1 right now and can't wait for version 2, you want to be able to get back to that exact state of version 1 so that you can make that update so that you can extract all the files that represent the state of your product or website or composition as a version 1, make some changes, and saves them back in a way that's separate from what the new stuff you're working on version 2.
Sometimes when you're working on a project, you want to do some experiments, and we'll say what if I re-factor this particular function, or what if we redid the size of the website, or what if we decided to take out this chorus and add another bridge in the song? Version Control Software allows you to make a copy of your entire repository and work on this in a private sandbox. This is called branching or forking. Once you've done all your experimental work, you may decide that this is exactly what you want, and wish to add your changes back into the main portion of your source code.
This is called merging. The thing that you branched from is oftentimes called the main branch or sometimes called the trunk. So what you want to do when you merge is integrate from your private branch back into the trunk or into the main branch. Sometimes you do this because your product is composed of a lot of pieces, and you want to be able to work on the individual pieces separately. For example, you might have an app that has an image processing component and an audio component, and two different developers work on each of these pieces. So, in this case, you would create two branches, one for the image processing developer to use, and one for the audio recording developer to use.
Then when the image processing developer completes her work, she merges her future updates back into the main trunk. This is a special kind of merging called reverse integration. If the audio developer has also done a reverse integration and merged updates back into the main branch, the image processing developer may want to get those changes before proceeding on and making additional changes. So, she can grab the updates from the main branch in a process that's called forward integration, which is kind of like creating a new branch. It simply takes the changes from the main trunk and puts them into her private branch.
And similarly, the audio developer can do the same thing with the image processing changes. We'll see this both conceptually and in action later in the course.
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.