Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-17T12:23:57.533Z
Answers: 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.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2019-01-15T22:15:19.380Z
Answers: 2019-01-15T22:15:19.380Z
Answers: AnoE
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-16T17:22:58.597Z
Answers: 2019-01-16T17:22:58.597Z
Answers: rebelution
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-01-15T19:41:33.090Z
Comments: Look this link: https://stackoverflow.com/a/48554370/8442153
Comments: dalmo.santos
Tags: <git><azure-devops><tfs>
Title: How to keep original and new repositories in sync during a migration? (including the commit history)
UserDisplayName: gbh
ThreadText: # 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 `new`is 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.
  
  
  ---
  
  