If, while committing your git changes through Visual Studio, you faced the following errors:
| Error: | Error encountered while pushing to the remote repository: rejected Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing to the same ref. You may want to first integrate the remote changes before pushing again. |
| Error: | You have divergent branches and need to specify how to reconcile them. |
Error encountered while pushing to the remote repository: rejected Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing to the same ref. You may want to first integrate the remote changes before pushing again.
Remote: Azure Repos
Remote:
Remote: Found 13 objects to send. (2 ms)
From https://dev.azure.com/xxxxxxxxx/_git/xxxxxxxxx-> origin/main
Hint: You have divergent branches and need to specify how to reconcile them.
Hint: You can do so by running one of the following commands sometime before
Hint: your next pull:
Hint:
Hint: git config pull.rebase false # merge
Hint: git config pull.rebase true # rebase
Hint: git config pull.ff only # fast-forward only
Hint:
Hint: You can replace “git config” with “git config –global” to set a default
Hint: preference for all repositories. You can also pass –rebase, –no-rebase,
Hint: or –ff-only on the command line to override the configured default per
Hint: invocation.
Unable to pull because your local and remote branches changed.
Set your preferred Git behavior for how to reconcile diverged branches in Git settings.
You may solve these issues in an unorthodox solution…but…
This can be a nerve-wracking situation, especially when you’re sure no one else has been working on your branch or project. Yet, you still encounter this error. One simple yet frustrating workaround is as follows:
- Copy the folder of the project you’re working on
- Delete the local repository
- Access your DevOps and clone the repository again
- Paste your copied project files into the newly cloned repository folder
- Open the project, commit your changes, and push
While this method often resolves the issue, allowing you to push your changes successfully, it’s important to note that it’s not an ideal long-term solution. It’s more of a quick fix that lacks the finesse of proper version control practices.
How to solve this issue in a proper way?
So, to make this process less painful, here’s a better solution using Visual Studio:
- Open Visual Studio and your project
- Go to Tools > Options
A new window will open. Here, search for Source Control, and then:
- Click on Git Global Settings
- Set Rebase local branch when pulling property to False.
- Click OK.
Now retry your Fetch, Pull, and Push operations. You should now be able to successfully push your commits.
But why does this happen?
The reason for this issue is that Git uses a distributed version control system, where each developer has a complete copy of the repository. When you’re working on a project with multiple developers, changes can happen in parallel. Sometimes, the remote repository (on Azure DevOps in this case) gets updated with new commits while you’re working on your local copy.
When you try to push your changes, Git detects that the remote branch has new commits that aren’t in your local branch. This creates a “divergent” situation where your local branch and the remote branch have different histories.
By setting the Rebase local branch when pulling property to False, you’re telling Git to use the merge strategy instead of rebase when pulling changes. This often resolves the conflict by creating a merge commit that combines your local changes with the remote changes.
Remember, while this solution often works, it’s always a good practice to communicate with your team about who’s working on what to minimize conflicts. Regular pulls and pushes can also help keep everyone’s work in sync and reduce the likelihood of divergent branches.
Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for Sandro’s son!
