We have a git repository that is currently hosted on Azure Devops and have to migrate it to our in house TFS 2017 git (the move is due to a business decision).

But during this setup we need to run both the original and new repositories in parallel for a time and synchronise them regularly until the new repository is signed off by the Dev leads. Only after the new one is approved by the team lead will the devs switch over and then we will make the original read-only. Throughout this process, we need to ensure the developers remain productive.

So how do we perform the initial migration from the Azure Devops repository to the new TFS 2017 git? And then how do we synchronise them regularly so that the new one does not get too far out of sync with the original?

We want to include the commit message history when migrating and syncing.


2 Answers 2


Simply keep pushing stuff between the repositories. Git pushes are designed for exactly that.

So, if origin is the old repository, and newis the new one, and you want to move new stuff in the master branch from origin to new, then, locally:

git checkout master && git reset --hard    # to clean up any local changes, optional
git pull origin 
git push new

That's it. master is a branch like any other, so if you have multiple branches, rinse and repeat.

  • Indeed. Git is by design expected to work with multiple repos and multiple forks. As long as the commit history has a common history its no problem. And an empty repo shares a common history with every other repo so can be pushed to.
    – simbo1905
    Commented Jan 17, 2019 at 12:23

Check this out - SO question on moving git repo

You probably would need to add automation around this since you want to move all repos.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.