Pull changes to your local Git repo - Azure Repos

Download changes with fetch

Git fetch downloads remote branch commits and referenced file objects that don't exist in your local repo and updates the remote-tracking branches in local repo cache. Remote-tracking branches are locally cached read-only copies of remote branches and aren't your local branches. Git fetch doesn't update your local branches. For example, if a remote repo designated by origin has a bugfix3 branch, Git fetch will update the remote-tracking branch named origin/bugfix3 and not your local bugfix3 branch. You can use remote-tracking branches to:

Compare a remote-tracking branch with a local branch to review fetched changes.

Merge a remote-tracking branch into a local branch.

Create a new local branch from a remote-tracking branch.

Visual Studio 2022 provides a Git version control experience by using the Git menu, Git Changes , and through context menus in Solution Explorer . Visual Studio 2019 version 16.8 also offers the Team Explorer Git user interface. For more information, see the Visual Studio 2019 - Team Explorer tab.

In the Git Changes window, choose Fetch . Then select outgoing/incoming to open the Git Repository window.

Fetch won't delete remote-tracking branches in your local repo cache that no longer have a remote counterpart. To configure Visual Studio to prune stale remote-tracking branches during a Fetch :

Select Tools > Options > Source Control > Git Global Settings .

Set the Prune remote branches during fetch option to


    True

Visual Studio 2019 provides a Git version control experience by using the Git menu, Git Changes , and through context menus in Solution Explorer .

In the Git Changes window, choose Fetch . Then select outgoing/incoming to open the Git Repository window.

Select Tools > Options > Source Control > Git Global Settings .

Set the Prune remote branches during fetch option to


    True

Visual Studio 2019 version 16.8 and later versions provides a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer , uncheck Tools > Options > Preview Features > New Git user experience from the menu bar. You can use Git features from either interface interchangeably.

In Team Explorer , select Home and then choose Sync to open the Synchronization view.

Select Tools > Options > Source Control > Git Global Settings .

Set the Prune remote branches during fetch option to


    True

To download new commits from a specific remote branch, run the Git fetch command:

git fetch <remote repo> <remote branch name>
To run Git fetch for all remote branches, use:
git fetch <remote repo>
When you clone a remote repo, Git assigns the alias origin as shorthand for the URL of the remote repo that you cloned. Run git remote -v to check the origin alias value. To add the origin alias manually, run git remote add origin <remote repo url>. With the origin alias, you can simplify the Git fetch command to:
git fetch
For more information on Git fetch options, see the Git reference manual.
By default, Git fetch won't delete remote-tracking branches in your local repo cache that no longer have a remote counterpart. To remove stale remote-tracking branches, run Git fetch with the --prune flag, or configure Git to prune remote-tracking branches during Git fetch.
After a Git fetch, you can compare a local branch with its corresponding remote-tracking branch to see what changed on the remote branch. If you decide to update your current local branch with fetched changes, you can perform a Git merge or rebase. Or, you can run Git pull, which combines a Git fetch with a Git merge or rebase. Both Git merge and Git rebase update a target branch by applying commits from a source branch onto it. However, Git merge and Git rebase use different strategies. For more information, see Update branches with merge or rebase and When to rebase vs. merge.
Update branches with merge or rebase
Git merge and Git rebase integrate commits from a source branch into your current local branch (target branch). Git merge performs either a fast-forward or a no-fast-forward merge. The no-fast-forward merge is also known as a three-way merge or true merge. Git rebase is another type of merge. These merge types are shown in the following diagram.
Git merge and Git rebase are extensively used in the Git workflow. When working on a local feature or bugfix branch, it's common practice to:
Keep your local main branch current with its remote counterpart by periodically pulling to fetch and merge remote commits.
Integrate local main branch updates into your local feature branch using a rebase or merge.
Back up your work on the local feature branch by pushing it to the corresponding remote branch.
On feature completion, create a pull request to merge your remote feature branch into the remote main branch.
This approach helps you:
Stay aware of recent work by others that might affect your work.
Promptly resolve any conflicts between your work and that of others.
Apply your new feature on top of up-to-date project content.
Get a pull request review of your work.
Merge
For Git merge, if the tip of the target branch exists within the source branch, the default merge type will be a fast-forward merge. Otherwise, the default merge type will be a no-fast-forward merge.
A fast-forward Git merge can never have a merge conflict because Git won't apply a fast-forward merge if the tip of the target branch has diverged from the source branch. By default, Git uses a fast-forward merge whenever possible. For example, Git will apply a fast-forward merge on a local branch that you only update by pulling from its remote counterpart branch.
A no-fast-forward Git merge generates a new target branch "merge commit" that integrates source branch changes with target branch changes. The applicable changes are those made after the last commit that's common to both branches. In the preceding diagram, commit C is the last common commit in both branches. If any source branch change conflicts with any target branch change, then Git will prompt you to resolve the merge conflict. The merge commit (L) contains the integrated source branch and target branch changes. The source and target branch tips (K and E) are the parents of the merge commit. In your branch's commit history, a merge commit is a useful marker for a merge operation, and clearly shows which branches were merged.
Git merge only modifies the target branch—the source branch remains unchanged. When you encounter one or more merge conflicts, you must resolve them to complete the merge. Or, you can cancel the merge operation and return the target branch to its prior state.
For more information on merge options and strategies, see the Git reference manual and Git merge strategies.
If the source branch is a remote-tracking branch, ensure that branch is up-to-date by running a Git fetch before the merge.
To integrate commits from one or more source branches into your current local branch, run the following Git merge command. For multiple source branches, separate their names with spaces.
git merge <source branch name>
Git will notify you if there are conflicts during the merge. You can either resolve the conflicts and then run git merge --continue, or run git merge --abort to undo the merge and return to the pre-merge state.
Rebase
Git rebase resequences the commit history of the target branch so that it contains all source branch commits, followed by all target branch commits since the last common commit. Another way to view it is that a Git rebase replays the changes in your target branch on top of the source branch history. If any source branch change conflicts with any target branch change, then Git will prompt you to resolve the merge conflict. Git rebase doesn't create a merge commit. Notably, Git rebase changes the sequence of the existing target branch commits, which isn't the case for the other merge strategies. In the preceding diagram, commit K' contains the same changes as K, but has a new commit ID because it links back to commit E instead of C.
Git rebase only modifies the target branch—the source branch remains unchanged. When you encounter one or more merge conflicts, you must resolve them to complete the rebase. Or, you can cancel the rebase operation and return the target branch to its prior state.
If you're the only person working on your feature or bugfix branch, consider using Git rebase to integrate new main branch commits into it. Otherwise, use Git merge. For more information on Git rebase and when to use it, see Apply changes with rebase and Rebase vs merge.
If the source branch is a remote-tracking branch, ensure that branch is up-to-date by running a Git fetch before the rebase.
To integrate the commits from a source branch into a target branch, run the Git rebase command:
git rebase <source branch name> <target branch name>
If your current local branch is the target branch, you can simplify the Git rebase command to:
git rebase <source branch name>
Git will notify you if there are conflicts during the rebase. You can either resolve the conflicts and then run git rebase --continue, or run git rebase --abort to undo the rebase and return to the pre-rebase state.
Download changes and update branches with pull
By default, Git pull combines a Git fetch and a Git merge to update your current local branch from its remote counterpart. Optionally, Git pull can perform a Git rebase instead of a Git merge.
Unlike Git fetch, Git pull will update your current local branch immediately after downloading new commits from the remote repo. Use Git pull when you know you want to update your current local branch right after a Git fetch.
To configure Visual Studio to rebase instead of merge when you Pull:
From the Git menu, go to Tools > Options > Source Control > Git Global Settings.
Set the Rebase local branch when pulling option to True.
To use fetch and integrate commits from a remote branch into the current working branch, run the Git pull command:
git pull <remote repo> <remote branch name>
If the remote repo has a branch with the same name branch as your current working branch, you can simplify the Git pull command to:
git pull <remote repo>
When you clone a remote repo, Git assigns the alias origin as shorthand for the URL of the remote repo that you cloned. Run git remote -v to check the origin alias value. To add the origin alias manually, run git remote add origin <remote repo url>. With the origin alias, you can further simplify the Git pull command to:
git pull
To use a rebase strategy to integrate commits from a remote branch into the current working branch, run the Git pull command with the --rebase flag. For more information on Git pull options, see the Git reference manual.
Git will notify you if there are conflicts during the merge/rebase portion of the Git pull operation. Then, you can resolve the conflicts and then run git merge --continue or git rebase --continue, or run git merge --abort or git rebase --abort to undo the merge/rebase.
Next steps
Share code with push
Resolve merge conflicts
Related articles
New to Git repos? Learn more