Edit

Key concepts

  • Article

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Here you'll find definitions of key concepts and artifacts used in Azure Repos.

Branch

Branches are lightweight references that keep a history of commits and provide a way to isolate changes for a feature or a bug fix from your main branch and other work. Committing changes to a branch doesn't affect other branches. You can push and share branches with other people on your team without having to merge the changes into main.

Switching between branches is quick and easy. Git doesn't create multiple copies of your source code when you're working with branches - it uses the history information stored in commits to re-create the files in a branch when you start working on it.

Learn more: branches, branch organization, and how we use branches at Microsoft.

Branch policies

Branch policies are an important part of the Git workflow. You use them to help protect the important branches in your development, like main. Branch policies enable you to:

  • Isolate work in progress from the completed work in your main branch.
  • Guarantee that changes build before they get to main.
  • Limit who can contribute to specific branches.
  • Enforce who can create branches and the naming guidelines for the branches.
  • Automatically include the right reviewers for every code change.
  • Enforce best practices with required code reviewers.

Learn more: branch policies.

Clone

Create a complete local copy of an existing Git repo by cloning it. Cloning a repo downloads all commits and branches in the repo and sets up a named relationship with the existing repo that you cloned. Use this relationship to interact with the existing repo, pushing and pulling changes to share code with your team.

Learn more: cloning.

Commit

A commit is a group of changes saved to your local repository. You can share these changes to the remote repository by pushing.

Learn more: commits.

Fork

A fork is a complete copy of a repository, including all files, commits, and (optionally) branches. The new fork acts as if someone cloned the original repository and then pushed to a new, empty repository. After a fork has been created, new files, folders, and branches are not shared between the repositories unless a pull request carries them along. When you're ready to share those changes, it's easy to use pull requests to push the changes back to the original repository.

Learn more: forks

Git

Git is the most commonly used version control system today and is quickly becoming the standard for version control. Git is a distributed version control system, so your local copy of code is a complete version control repository. These fully functional local repositories make it is easy to work offline or remotely. You commit your work locally, and then sync your copy of the repository with the copy on the server.

Git in Azure Repos is standard Git. You can use the clients and tools of your choice, such as Git for Windows, Mac, partners' Git services, and tools such as Visual Studio and Visual Studio Code.

Learn more: Git and Azure Repos.

Git workflow

Version control has a general workflow that most developers use when writing code and sharing it with the team. These steps are:

  1. Get a local copy of code if they don't have one yet.
  2. Make changes to code to fix bugs or add new features.
  3. When the code is ready, make it available for your team to review.
  4. After the code is reviewed, merge it into the team's shared codebase.

Git has a version of this workflow that uses terminology and commands such as repositories, branches, commits, and pull requests. These terms might sound familiar if you've used a version control system like Team Foundation Version Control (TFVC) or Subversion, but they behave differently in Git.

  1. Create a branch for the changes you plan to make and give it a name, such as users/jamal/fix-bug-3214 or features/cool-feature.
  2. Commit changes to your branch. People often have multiple commits for a bug fix or feature.
  3. Push your branch to the remote repository.
  4. Create a pull request so other people can review your changes. To incorporate feedback, you might need to make more commits and push more changes. When the code is ready, complete the pull request and merge your code into the target branch, such as main.

Use this workflow if you're new to Git. As your team gets more experienced and confident with Git, extend it to suit your team's needs.

Learn more: how we use Git at Microsoft.

Notifications

With notifications, you receive an email when changes occur to work items, code reviews, pull requests, source control files, and builds. For example, you can get notified whenever a bug that you opened is resolved, or when a work item is assigned to you. You receive notifications based on rules or subscriptions made by you, for your teams, or for the project. Learn more: About notifications.

Projects

A project, which was previously known as a team project, provides a repository for source code. A project provides a place where a group of people can plan, track progress, and collaborate on building software solutions. A project is defined for an Azure DevOps Services organization or within a TFS project collection. You can use it to focus on those objects defined within the project. To learn more, see About projects and scaling your organization.

Public projects

A project created within an Azure DevOps Services organization that is visible to the whole world. Everyone in the world can discover them and perform limited operations. You can use the Azure DevOps CLI to discover a list of projects. Administrators can control who gets to fully contribute. Administrators can switch a project from private to public, and vice-versa, as described in Change the project visibility.

Pull request

Create pull requests to review and merge code in a Git project. Pull requests let your team review code and give feedback on changes before you merge it into the main branch. Pull requests can come from either topic branches within the same repository or a branch in a fork of the original repository. Reviewers can step through the proposed changes, leave comments, and vote to approve or reject the code.

Learn more: pull requests.

Pull

A pull command updates the code in your local repository with the changes from other members of your team that are in the remote repository.

Learn more: pull.

Push

Share changes made in commits and branches by using the push command.

When you push, Git uploads the saved commits in your checked branch to the remote repository. If the branch exists on the remote repository, Git takes the commits and adds them to that branch on the remote repository. If that branch doesn't exist, Git creates a new branch with the same commits as your local branch.

Learn more: push.

Repository

A repository is a location for your code managed by version control. Azure Repos supports both Git and TFVC.

Teams

A team corresponds to a selected set of project members. With teams, organizations can subcategorize work to better focus on all the work they track within a project. Each team gets access to a suite of Agile tools. Teams can use these tools to work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to meet their work requirements. To learn more, see About teams and Agile tools.

Team Foundation Version Control (TFVC)

A centralized version control system. With TFVC, devs have only one version of each file on their dev machines. Branches are path-based and created on the server. Historical data is maintained only on the server. Learn more: Use Team Foundation Version Control.