Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Moving A Git Repository To A New Server

Suppose your company decides to change its code-hosting provider or you wish to move your own Git repository to a different host. It doesn’t happen often, but it happens. When I had to move a number of Git projects to a new host, it took me quite some time to find an accurate method.

Having made many attempts, and a couple of fails, and carefully reading Git’s documentation1, I found a solid and effective way. I thought, then, that every developer would benefit from knowing how to migrate a Git repository to a new host quickly and easily. The most important thing is to make sure that your branches and tags and your commit history are all moved.

Further Reading on SmashingMag: Link

Moving A Git Repository To A New Server
Finally, an easy way of moving a git repository to a new server.

Let’s Learn How To Do That Properly Link

First, we have to fetch all of the remote branches and tags from the existing repository to our local index:

git fetch origin

But even if all branches and tags have been fetched and exist in a local index, we still won’t have a copy of them that is physically local. And a local copy is required to migrate the repository.

We can check for any missing branches that we need to create a local copy of. Let’s list all existing branches (local and remote) to see whether we are missing any copies locally:

git branch -a

* master

We can easily tell from this output whether we have local copies of all remote branches: The remote ones are prefixed with the remotes/origin/ path, and the local ones aren’t. So, only our master branch is local, whereas remotes/origin/develop and remotes/origin/release/0.1 are not. That’s OK — let’s just create local copies:

git checkout -b develop origin/develop
git checkout -b release/0.1 origin/release/0.1

After creating local copies of everything, we can verify once again whether all branches with the remotes/origin/ prefix have corresponding local copies (shown without the prefix):

git branch -a

* release/0.1

Now we know for sure that all branches in our repository are stored locally, and we are ready to move the repository to a new host.

At this point, let’s assume we have an SSH-cloned URL of our new repository. If not, create a new repository, and then you will have its SSH-cloned URL.

Let’s use the SSH-cloned URL of our new repository to create a new remote in our existing local repository by executing the following command:

git remote add new-origin

This will give us two remotes for the existing repository: the original one (named origin, connected to the existing remote host) and a new one (named new-origin, connected to the new host).

(Git has this concept of “remotes,” which are simply URLs to other copies of your repository. The name origin refers to the original remote repository; by convention, it is considered the primary centralized repository.)

Now we are ready to push all local branches and tags to the new remote named new-origin. We could push each local branch separately, but pushing all branches at once would be much faster by executing the following Git command:

git push --all new-origin

Let’s also push all of the tags to new-origin with this Git command:

git push --tags new-origin

We’re almost done. Let’s make new-origin the default remote, which will direct all future commits to the new repository that we have just pushed to. To do this, remove the old repository remote:

git remote rm origin

And rename new-origin to just origin, so that it becomes the default remote:

git remote rename new-origin origin

(Everyone is used to the default remote being named origin. So, let’s keep it standard by naming our primary centralized repository remote origin, too.)

Awesome, Done! Link

Your repository is now connected to the new remote (i.e. the new host), which will store all of your branches and tags and your commit history. Plus, all commits will be pushed to the new remote host from now on.

(ds, il al)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4

↑ Back to top Tweet itShare on Facebook

Nik Sumeiko is a JavaScript hacker and Frontend infrastructure engineer based in Vienna, Austria. He works freelance with teams at Sony, IDEO, Samsung and other innovative companies. Nik loves building software that scales using Google Closure Tools. He often shares his experience with younger programmers and learns a lot from great people surrounding him every day.

  1. 1

    Thanks for the article. I’ll keep it in the bookmarks for the future.

  2. 2

    Andy Jeffries

    May 19, 2014 1:55 pm

    It seems that this article makes it sound much more difficult than it is, unless I’m misunderstanding something (and I’ve just moved 30+ repositories, TWICE, in the last week).

    git clone –bare
    cd repo
    git remote add origin
    git push –mirror

    The clone bare brings down all refs/tags/etc, and the push –mirror pushes everything back up.

  3. 3

    There are easier and less error prone ways to move your repo. Look up
    `git clone –bare` and `git push –mirror`
    More details:

  4. 4

    Nice! Clean and straight forward article, just how I like them!

  5. 5

    Does this method preserve commit history? I don’t see anything about that being mentioned …

  6. 6

    Edem, it is (see the sentence above the picture at the beginning of the article) and, by the way, it is one of the most important requirements writing this article – to preserve commits history after repository is being moved.

  7. 7

    David Schmidt

    January 7, 2015 6:30 pm

    Thanks – this was perfect for my use. `git clone –bare` and `git push –mirror` didn’t give me the control I really wanted. The individual steps made it easy for me to tailor exactly how I wanted my repository copy to proceed.

  8. 8

    Haywood Jablomi

    January 22, 2015 12:29 am

    Thanks for the article — you say that “all commits will be pushed to the new remote host from now on,” but doesn’t each user have to update their definition of origin to push to the correct IP address?

    • 9

      When the migration is done, developers can clone from the new repository. So it’s better to push all the commits before the migration is done. Since it has only few steps, you can do it pretty quick. Although I haven’t done any migration, I believe this to be the process. If not some one please correct me.

  9. 10

    I also thank you for this article. It is a great solution to migrate from svn to git, especially if you already use git svn bridge ;)

  10. 11

    Thanks – these instructions were clear and gave me just what I wanted.

  11. 12

    Petr Tomasek

    March 18, 2015 3:17 pm

    In order to continue working on the master branch, I had to issue one more command after renaming new-origin to origin:

    git branch –set-upstream-to=origin/master

    I’m running git version 1.9.2.msysgit.0.

  12. 13

    Much appreciated post, man. Quite clear and obviously useful to many people.


↑ Back to top