Principles of source control

Keyboard Shortcuts

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 systemsperform a set of similar actions.Familiarity with one systemwill acquaint with you the concepts,so switching to another system is usually frictionless.The action performed upon the version control systemcan 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 operationthat saves the local changes to the system.Each system uses a concrete command namefor 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 listof the common operations,so we have a shared understanding of each operationbefore using themin Team Foundation Version Control and Git.The create operation is the wayto make a new, empty repository.Usually, this is a one-time operationperformed 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 copyon your developer computer.A working copy is a snapshot of the repositorythat is used by a developer as a placeto 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 themor saves them to the repository.To save the changes, use the commit operation.

This takes any pending changes in the working copyand 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 repositoryas a unit and identified as a changeset.The commit is atomic,which means all the changes are committed as a unitor the commit is aborted, and the changes roll back.

Most systems have a comment or log systemwhere you can write a message,explaining the modifications in the your changeset.Update brings any changes in the repositoryto the local computer.It updates the files as neededand 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 fileswhile there is a copy checked out.Because the system knows what is happeningin 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 movefile and folders in the working copy.All of the changes are marked as pendingin the local working copy.A commit operation is needed to persist the changesto the repository.Use status to get a report of what changesare in the pending changeset.This usually consists of a list of edits,editions, deletions, and so on.If you want to see the actual changesbetween the working copy and the repository,use the diff operation.

This is usually implemented as a side-by-side comparisonof the two items.Revert provides a way to discard all pending changesand turn to the prior working copy.This is useful if your experimental codeis not solving your problemand 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 forkin 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 createdfour months before version 1.4 is completed.This allows another team to start workingon new features in 2.0while the 1.4 version is finalized.Then when 1.4 is done and the rest of the teamswitches over to help on version 2.0,the 1.4 branch is still there for bug fixes if needed.The merge operation is usefulwhen you have multiple branchesthat need to converge into a single branch again.

For example, say you have a branchwhere team members are experimentingwith a new feature.At some point, it's determined that it's a good featureand is ready to add to the product.Use merge to bring the experimental branchtogether with the main trunk,where the rest of the team has been workingon the older features.Be aware that merge is also a term usedwhen 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 systemsare the hot topic in source control.

They are based on a fundamentally different philosophy.Rather than have one repository on the serverand 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 toconnect to a server to perform any operations.So check outs, commits, updates, branching, and mergesare all available from the local repository.Yes, you'll need a network connection at some pointif you want to collaborate with other team members,but all the common operationsare done against the local instance.

To collaborate with your team,you'll need to synchronize the distributed repositorywith the other team members.Remember that each developer has a private repo instanceon their computer.One possible approach to thiswould be to do peer-to-peer syncing between team members.While this might work for small teamsof 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 serverand put a copy of the repository there.

The push operation is used to synchronizebetween 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 computerare 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 operationshappen in the working copy,which is on the developer computer.

The commit operation takes those pending changesand stores them in the repository.In distributed systems,that repository instance is alsoon the local developer computer.Now when you use the push operation,it syncs the repository to the remote computer.You're taking all the modificationsin the local repositoryand syncing them to the remote instance.There might be five days' worth of editsin the local repository,perhaps 20 changesets in total.These are all sent with one push operationto 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 repositoryto Tad's computer.This works, but is awkward for larger teams.It's more common to create a shared repositoryon another computer that is accessibleto all the team members.Back to our scenario,the team has purchased some GitHub licencesand 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 synchronizebetween two repository instances.The difference between push and pullis 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 operationis 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 overfrom another division in the companyand has joined the team.He doesn't have a local instanceof the repository on his computer.Have no fear,that's why distributed version control systemshave the clone operation.Clone makes a local copy of the remote repositoryon Jacob's computer.

And now he's ready to work.Eventually, he'll have some changesthat he'll push to the server, too.That concludes this look at the common operationsavailable in version control systems.There are 18 operations accessiblein 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 Studioare sprinkled throughout the rest of this course.

Resume Transcript Auto-Scroll

Author

Released

7/28/2016

A programmer's most valuable asset is his or her codebase. What are you doing to protect the integrity of your code? The source control options offered in Visual Studio, including Team Foundation, Team Services, GitHub, and Bitbucket, can help you work with team members more effectively, prevent accidental overwrites, enable rollbacks, and resolve bugs. In Visual Studio Essentials 10, Walt Ritscher shows how to connect Visual Studio to any online repository, create projects, add team members, and work with versions. He shows how to check code in and out, use CodeLens to examine changes in the Visual Studio editor, and use the History and Diff features to see who opened and updated projects.

Topics include:

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

Skill Level Beginner

2h 36m

Duration

51,386

Views

Show MoreShow Less

Q: This course was updated on 08/23/2017. What changed?

A: A new video was added that provides notes for Visual Studio 2017 developers.