<p>Simply keep pushing stuff between the repositories. Git pushes are designed for exactly that. </p>

<p>So, if <code>origin</code> is the old repository, and <code>new</code>is the new one, and you want to move new stuff in the <code>master</code> branch from <code>origin</code> to <code>new</code>, then, locally:</p>

<pre><code>git checkout master &amp;&amp; git reset --hard    # to clean up any local changes, optional
git pull origin 
git push new
</code></pre>

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

CC BY-SA 4.0
2019-01-17T12:23:57.533Z
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
CC BY-SA 4.0
2019-01-15T22:15:19.380Z
2019-01-15T22:15:19.380Z
AnoE
<p>Check this out - <a href="https://stackoverflow.com/a/11426261/4864827">SO question on moving git repo</a></p>

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

CC BY-SA 4.0
2019-01-16T17:22:58.597Z
2019-01-16T17:22:58.597Z
rebelution
<p>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).</p>

<p>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.</p>

<p>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?</p>

<p>We want to include the commit message history when migrating and syncing.</p>

CC BY-SA 4.0
2019-01-15T19:41:33.090Z
Look this link: https://stackoverflow.com/a/48554370/8442153
dalmo.santos
<git><azure-devops><tfs>
How to keep original and new repositories in sync during a migration? (including the commit history)
gbh
# How to keep original and new repositories in sync during a migration? (including the commit history)

(Asked by: username_0 on 2019-01-15)

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.

**Tags:** git, azure-devops, tfs

> **Comments:**
> **username_1**: Look this link: https://stackoverflow.com/a/48554370/8442153  

---

## 2 answers

### Answer by username_2 on 2019-01-15. Score: 6

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.

> **Comments:**
> **username_3**: 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.  

---

### Answer by username_4 on 2019-01-16. Score: 0

Check this out - [SO question on moving git repo](https://stackoverflow.com/a/11426261/4864827)

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


---

