About branches and branch policies
TFS 2017 | TFS 2015
Branch policies are an important part of the Git workflow and enable you to:
- Isolate work in progress from the completed work in your main branch
- Guarantee 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
The following table summarizes the policies you can define to customize a branch. For an overview of all repository and branch policies and settings, see Git repository settings and policies.
Policy
Default
Description
Off
Require approval from a specified number of reviewers on pull requests.
Off
Add one or more policies to validate code by pre-merging and building pull request changes. Can also enable or disable policies.
Off
Add one or more policies to require other services to post successful status to complete pull requests. Can also enable or disable policies.
Off
Add one or more policies to designate code reviewers to automatically include when pull requests change certain areas of code. Can also enable or disable policies.
Adopt a Git branching strategy
There are a few critical branches in your repo that the team relies on always being in good shape, such as your main branch.
Require pull requests to make any changes on these branches. Developers pushing changes directly to the protected branches will have their pushes rejected.
Keep your branch strategy simple by building your strategy from these three concepts:
- Use feature branches for all new features and bug fixes.
- Merge feature branches into the main branch using pull requests.
- Keep a high quality, up-to-date main branch.
A strategy that extends these concepts and avoids contradictions results in a version control workflow for your team that is consistent and easy to follow.
- Adopt a branching strategy
- How to configure branch policies
- Branch permissions
- Require branch folders
- Configure a branch policy for an external service
Create work in branches
Git branches aren't much more than a small reference that keeps an exact history of commits, so they're cheap to create.
Committing changes to a branch won't affect other branches. You can share branches with others without having to merge the changes into the main project.
You can create new branches to isolate changes for a feature or a bug fix from your main branch and other work.
Since the branches are lightweight, switching between branches is quick and easy. Git doesn't create multiple copies of your source when working with branches—it 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 simple to change what you are working on by changing your current branch.
How are Git branches created?
You create branches by using the branch command. Branch creates a reference in Git for the new branch and a pointer back to the parent commit so Git can keep a history of changes as you add commits to the branch.
When you're working with a branch that someone else shared, Git keeps an upstream tracking relationship. The relationship associates the branch on the local repo with the corresponding branch on the remote repo.
Upstream tracking makes it simple to sync changes with others using push and pull.
In this screenshot, you can see a new branch that was created from the main branch. Work continues on both branches and commits are added to both branches.
Git always adds new commits to the current local branch. Check what branch you're working on before you commit so that you don't commit changes to the wrong branch.
Swap between local branches using the checkout command. Git will change the files on your computer to match the latest commit on the checked out branch.
When your work in the branch is ready to share with the rest of the team, you push the changes to update the remote branch.
A common mistake is to make some changes and commit them, realize you're on an incorrect branch, then checkout to the correct branch.
Your most recent changes will no longer be on the filesystem since each branch has its own version of code.
Git brings the files' state back to the last commit on the branch you swapped into, not the previous branch where you made your changes.
You'll need to either cherry-pick the commits from the branch or merge the changes into the correct branch.
Use branches to manage development
Git keeps track of which branch you're working on and makes sure that when you checkout a branch your files match the most recent commit on the branch.
Branches let you work with multiple versions of the source code in the same local Git repository at the same time.
Tell Git which branch you want to work on with checkout, and Git takes care of setting the right file versions for that branch.
You don't need more than one repo on your system when you use branches to isolate your work.
Set up your development environment one time after you clone. Then, use Git branches to swap between feature work and bug fixing.
Branching how to guides
Learn how to complete common tasks when working with branches.
- Branches tutorial
- How to create a branch
- How to delete a branch
- Restore a deleted branch
- How to lock branches