All version control systems perform a set of similar actions. Familiarity with one system will acquaint you the concepts, so switching to another system is usually frictionless. This tutorial runs through a short list of the common source control operations, which provides understanding of each operation.before using them in Team Foundation Version Control and GIT
- [Voiceover] All version control systems perform a set of similar actions. Familiarity with one system will acquaint with you the concepts, so switching to another system is usually frictionless. The action performed upon the version control system can be thought of as an operation on a system. Think of this as a general term, so whether I use Subversion or Git, they both have a commit operation that saves the local changes to the system. Each system uses a concrete command name for the real action. Most of the time, the various systems pick the same command name, but there can be variations.
In this video, I'll run through a short list of the common operations, so we have a shared understanding of each operation before using them in Team Foundation Version Control and Git. The create operation is the way to make a new, empty repository. Usually, this is a one-time operation performed at the beginning of a project. When you create the repository, each system required a few details, like the name of the repository, the location of the repository, and possibly other information, like which users are permitted to use the system.
Now that you have a repository, you check out the repository to make a working copy on your developer computer. A working copy is a snapshot of the repository that is used by a developer as a place to make changes. The real repository is shared by the entire team, but no one should modify the repository directly. Each developer gets their own working copy. Any changes in the working copy are kept locally, until the developer discards them or saves them to the repository. To save the changes, use the commit operation.
This takes any pending changes in the working copy and applies them to the repository. In the real world, the changes can be complex. There could be new files in folders, modified files, file and folder renames, relocated files, and file deletions. All of these changes are saved in the repository as a unit and identified as a changeset. The commit is atomic, which means all the changes are committed as a unit or the commit is aborted, and the changes roll back.
Most systems have a comment or log system where you can write a message, explaining the modifications in the your changeset. Update brings any changes in the repository to the local computer. It updates the files as needed and merges changes in the files as necessary. For systems that support locking files on check out, the merge step is not necessary, because team members can't change the files while there is a copy checked out. Because the system knows what is happening in the working copy, and what's changed on the server, it can efficiently manage the update.
The next set of operations is simple to understand. You can add, edit, delete, rename, and move file and folders in the working copy. All of the changes are marked as pending in the local working copy. A commit operation is needed to persist the changes to the repository. Use status to get a report of what changes are in the pending changeset. This usually consists of a list of edits, editions, deletions, and so on. If you want to see the actual changes between the working copy and the repository, use the diff operation.
This is usually implemented as a side-by-side comparison of the two items. Revert provides a way to discard all pending changes and turn to the prior working copy. This is useful if your experimental code is not solving your problem and you just want to start anew. Finally, there is the tag operation. This provides a way to label a changeset with a name, as opposed to identifying it with a time stamp only. This is helpful for labeling milestones and releases. The branch operation is used to create a fork in your code base, to move your project into another development path.
This is often done when changing version numbers. For example, a 2.0 branch is created four months before version 1.4 is completed. This allows another team to start working on new features in 2.0 while the 1.4 version is finalized. Then when 1.4 is done and the rest of the team switches over to help on version 2.0, the 1.4 branch is still there for bug fixes if needed. The merge operation is useful when you have multiple branches that need to converge into a single branch again.
For example, say you have a branch where team members are experimenting with a new feature. At some point, it's determined that it's a good feature and is ready to add to the product. Use merge to bring the experimental branch together with the main trunk, where the rest of the team has been working on the older features. Be aware that merge is also a term used when there is conflicts in multiple working copies. When two developers have changes inside the same file, you can merge the contents together, then commit to the repository. Distributed version control systems are the hot topic in source control.
They are based on a fundamentally different philosophy. Rather than have one repository on the server and many working copies on the local machine, the idea is to have many instances of the repository, one on each computer. This means that the developer doesn't have to connect to a server to perform any operations. So check outs, commits, updates, branching, and merges are all available from the local repository. Yes, you'll need a network connection at some point if you want to collaborate with other team members, but all the common operations are done against the local instance.
To collaborate with your team, you'll need to synchronize the distributed repository with the other team members. Remember that each developer has a private repo instance on their computer. One possible approach to this would be to do peer-to-peer syncing between team members. While this might work for small teams of two to three developers, it would be messy for larger teams. To make it easier so synchronize between the local repos, most teams create a shared server and put a copy of the repository there.
The push operation is used to synchronize between two repository instances. The local repository, the one on your computer, is the push transmitter. The remote repository, a repository on another computer, is the push recipient. The changesets on the local computer are synced with the remote computer. I can hear the question in your mind, "How is this different from the commit operation "discussed earlier?" So let's review. The Add, Edit, Delete, Move, Rename, and similar operations happen in the working copy, which is on the developer computer.
The commit operation takes those pending changes and stores them in the repository. In distributed systems, that repository instance is also on the local developer computer. Now when you use the push operation, it syncs the repository to the remote computer. You're taking all the modifications in the local repository and syncing them to the remote instance. There might be five days' worth of edits in the local repository, perhaps 20 changesets in total. These are all sent with one push operation to the remote computer. Here's an example.
Tad and his team are using Git for version control. Git, as you probably know, is a distributed system. Tad decides it's time to sync with another repository. He pushes his content to Terry's computer. Now all this changes are in her repository. Later, when Terry is ready to sync, she can push from her local repository to Tad's computer. This works, but is awkward for larger teams. It's more common to create a shared repository on another computer that is accessible to all the team members. Back to our scenario, the team has purchased some GitHub licences and created a shared repository in the GitHub servers.
Now Tad pushes to the shared repository. The next day, Terry pushes to the same repository on GitHub. The pull operation is another way to synchronize between two repository instances. The difference between push and pull is the direction of the sync. The remote repository, the one on your server, is the pull source. The local instance is the sync destination. Keep in mind that the pull operation is initiated on the local computer. Back to our scenario, Terry pushes to the shared repository.
Later, Tad learns that his repository's out of sync, so he starts a pull operation on his computer, which syncs the GitHub repository with his local repository. A couple weeks pass, and there's a change to the team. Jacob is transferred over from another division in the company and has joined the team. He doesn't have a local instance of the repository on his computer. Have no fear, that's why distributed version control systems have the clone operation. Clone makes a local copy of the remote repository on Jacob's computer.
And now he's ready to work. Eventually, he'll have some changes that he'll push to the server, too. That concludes this look at the common operations available in version control systems. There are 18 operations accessible in most centralized systems. We looked at the majority of them in this video. When working in distributed systems, like Mercurial and Git, there are three additional operations, push, pull, and clone, that are necessary for syncing between repositories. Details about the operations work in Visual Studio are sprinkled throughout the rest of this course.
- Source control principles
- Signing up for Team Services
- Creating team projects
- Adding projects to source control
- Checking in and checking out changes from the repository
- Adding users to a team project
- Tracking work items
- Adding projects to Git
- Using history to understand team commits
- Using tags to label versions