Version Control with Git in Visual Studio Code and Azure DevOps
2 h 40 m
Lab Overview
Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here is a quick overview of the two vesion control systems:Team Foundation Verson Control (TFVC): TFVC is a centralized version control system. Typically, team memvers have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.Git: Git is a distributed version control system. Git repositories can live locally (such as on a developer's machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as a history and compare without a network connection.Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.In this lab, you will learn how to establish a local Git repository, which can easily be syncronized with a centralized Git repository in Azure DevOps. In addition, you will learn about Git branching and merging support. You will use Visual Studio Code, but the same processess apply for using any Git-compatible client with Azure DevOps.

Related Learning Path(s):
AZ - 400 - Microsoft Azure DevOps Solutions
  • Understand how to establish a local Git repository
  • Understand how perform Git branching and merging using Visual Studio Code

This exercise will introduce you to the Skillmeup lab environment.

Certain Azure DevOps labs require a preconfigured **Parts Unlimited** team project. This document outlines the required steps to set up the required data.

In this exercise, you'll configure a Git credential helper to securely store the Git credentials to communicate with Azure DevOps.
In this exercise, you'll clone an existing repository and install a new extension in Visual Studio Code for working with Azure Repos.
When you make changes to your files, Git will record the changes in the local repository. You can select the changes that you want to commit by staging the changes. Commits are always made against your local Git repository, so you don't have to worry about the commit being perfect or ready to share with others. You can make more commits as you continue to work and push the changes to others when they are ready to be shared.
What's in a commit?
Git commits consist of the following:
- The file(s) changed in the commit. Git keeps the contents of all file changes in your repo in the commits. This keeps it fast and allows for intelligent merging.
- A reference to the parent commit(s). Git manages your code history using these references.
- A message describing a commit. You give this message to Git when you create the commit. It's a good idea to keep this message descriptive, but to the point.
Git uses the parent reference information stored in each commit to manage a full history of your development. you can easily review this commit history to find out when file changes were made to determine differences between versions of your code using the terminal or form one of the many Visual Studio Code extensions available. You can also review changes using the Azure DevOps portal.
Git's use of the Branches and Merges feature works through pull requests, so the commit history of your development doesn't necessarily form a string, chronological line. When you use history to compare versions, think in terms of file changes between two commits instead of file changes between two points in time. A recent change to a file in the master branch may have come from a commit created two weeks ago in a feature branch but was only merged yesterday.
You can manage the work in your Azure DevOps Git repo from the Branches view on the web. You can also customize the view to track the branches you care most about so you can stay on top of changes made by your team.
Committing changes to a branch will not affect other branches and you can share branches with others without having to merge the changes in to the main project. You can also create new branches to isolate changes for a feature or a bug fix from your master branch and other work.
Since the branches are lightweight, switching between branches is quick and easy. Git does not create multiple copies of your source when working with branches, but rather uses the history information stored in commits to recreate the files on a branch when you start working on it. Your Git workflow should create and use branches for managing features and bug fixes. The rest of the Git workflow, such as sharing code and reviewing code with pull requests, all work through branches. Isolating work in branches makes it very simple to change what you are working on by simply changing your current branch.
In addition to all the functionality available in Visual Studio Code, you can also manage your repo branches from the Azure DevOps portal.
You can create Git repos in team projects to manage your project's source code. Each Git repo has its own set of permissions and branches to isolate itself from other work in your project.
Real-Time Lab
Not Registered?
Create Account
Already Registered?
What are Labs?

Labs provide a live environment to get hands-on experience using the same tools and services in the real world.

Learn More