52

Just installed a fresh new 6.8 Gitlab on a brand new high performance server.

Before considering to forget my repositories history (comments, issues, etc...), do one know of a way to export a repository data from a Gitlab server to another Gitlab Server ?

I just failed to found anything on the documentation for exporting/migrating the whole project data (not just the git repository and its wiki).

blackeyedboy
  • 591
  • 1
  • 5
  • 5

4 Answers4

36

For GitLab versions >= 8.9 (released in June 2016) you can use the built-in export and import project feature.

Please not that for the existing installations of GitLab, this option has to be enabled in the application settings (URL: /admin/application_settings) under 'Import sources'. You have to be a GitLab admin user to enable and use the import functionality.

Here is the feature complete documentation: https://gitlab.com/help/user/project/settings/import_export.md

Greg Dubicki
  • 5,983
  • 3
  • 55
  • 68
  • 3
    This one should be the accepted answer. Here is more information: https://gitlab.com/help/user/project/settings/import_export.md – Cristian T Aug 13 '16 at 07:37
  • Thanks @CristianT! I have also added the link to my answer. – Greg Dubicki Aug 14 '16 at 18:12
  • 1
    It looks like the import options have changed: *gitlab is not listed* ! I noe see GitHub, Bitbucket, Google Code, Fogbugz, git repo – Someone Somewhere Sep 15 '16 at 13:11
  • Maybe you haven't enabled it in `/admin/application_settings`, @SomeoneSomewhere? I have added that to my answer. – Greg Dubicki Sep 15 '16 at 13:41
  • thanks for your fast response. I can't find the setting and using `https://gitlab.com/admin/application_settings` results in a 404. Is it something like Burger Menu -> Profile Settings -> Applications ? – Someone Somewhere Sep 15 '16 at 19:57
  • The OP was asking about his own instance of GitLab, not gitlab.com. I see that although *export* is available at gitlab.com, *import* is in fact not there. – Greg Dubicki Sep 16 '16 at 08:25
  • I concur, on gitlab.com I don't see it available :-/ I was hoping it would be somehow – Someone Somewhere Sep 19 '16 at 14:29
  • For future reference: as of Dec 2019 there *IS* an option to both import as well as export project at gitlab.com. – Greg Dubicki Dec 28 '19 at 07:25
10

I have actually done this recently, we were upgrading our instance of gitlab and needed to save and import repositories to the new installation.

First, create a bundle of the checked-out repository. For example, say you checked out a repository we will call myrepository

To check out the repository use git clone (let's assume your repository is under the root account and the ipaddress is 192.168.1.1)

git clone http://192.168.1.1/root/myrepository.git (or match your environment)

Now this step is somewhat important; you need to change into the working directory that has the .git folder of your checked out repository.

cd myrepository

Next, you create a bundle file:

git bundle create myrepository.bundle --all

Import the bundle file into the new instance of gitlab.

Create a new 'myrepository' on the gitlab gui interface

clone the empty repository; let's say this new gitlab has the ipaddress 192.168.1.2:

git clone http:\\192.168.1.2\root\myrepository.git (or match your environment)

You will get warnings that you cloned an empty repository. This is normal.

Change into the working directory of your checked out repository and do a git pull:

cd myrepository

git pull file/path/to/myrepository.bundle

this will pull the repository into your clone. Next you can do a git add, git commit and git push

This should work assuming you have the gitlab server settings set up correctly; you may have issues such as needing to add a client_max_body_size parameter in your nginx.conf file and also a 'git config --global http.postBuffer' to push large files.

Another way to do this is to make patch files of each commit and then deploy them:

This involves doing a 'git format-patch -C 0badil..68elid -o patch_directory_path' and reference the range of all your commits and have them pushed to an output directory; this should give you one patch file per commit. Next would involve git cloning the new empty repository, changing into the working directory of the clone and applying the patches to the new repository using 'git am patch_directory_path'

user3614014
  • 653
  • 1
  • 6
  • 22
  • 16
    I don't get the many upvotes. If you have big gitlab server, with lots of users, projects etc. this answer doesn't help in the slightest. The issue here isn't the repo itself, which, as you can see per this answer, is really easy to push to somewhere else (`git clone --mirror` then `git push --mirror`, no need for all the fluff in this answer), the issue is setting up all those users, all those repos, all the matching permissions, all the issues, etc., nothing of which is being addressed here – Cookie Jul 20 '16 at 15:38
  • Well, this is the hard way. You cannot just move part of data on the filesystem, you need to upgrade the GitLab properly in order to perform all the database upgrade (rake) tasks while not loosing all the precious data along the way. – igraczech Jul 28 '17 at 22:53
7

For the repos themselves, you can use git bundle: that will generate one file, that it is easy to copy around.
(as I described in "Backup a Local Git Repository")

But another way is simply to git clone --mirror your repos from the first server on a local workstation, and git push --mirror to the new server.
This is what GitHub details in its help page "Duplicating a repository".

In both cases, you need first to declare those repos on the new GitLab server, in order for them to be initialized, and ready to receive commits.

But for the rest... not easily. There is a feature request pending:
(Update August 2016, 2 years later: GitLab 8.9 has that feature implemented)
(for GitLab version older than 8.9, see and upvote Greg Dubicki's answer)

I agree that issues are the main thing to make exportable first.
They are stored in the database. Storing them in git is not an option. Maybe export them as a formatted file (SQL, YAML or something else).

This blog post illustrates the export of a mysql database.

Use mysqldump to create dump of old database, then create a new database on the new server and import this.

  • On old:
    mysqldump gitlab | gzip > gitlab.sql.gz
  • On new:
    gunzip < gitlab.sql.gz | mysql gitlab

Run the db migrate command to make sure the schema is updated to the latest version.

sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • i'm not sure you understood, that would export my repositories, but not their issues, comments on code, comments on merge request, etc... – blackeyedboy Apr 25 '14 at 14:30
  • @blackeyedboy i have edited my answer with the relevant feature request. – VonC Apr 25 '14 at 14:33
  • damn, i forgot searching on their suggestion forum ! thanks for the link – blackeyedboy Apr 25 '14 at 14:34
  • thanks, but it says `from version 3.1 to 4.1`, we are currently 6.8 and gitolite is no more used by gitlab since 5.0 – blackeyedboy Apr 25 '14 at 14:37
  • @blackeyedboy it doesn't matter. The version isn't what is important here: the process would remain the same: dumping and re-importing the database. – VonC Apr 25 '14 at 14:38
  • As of now, with currect GitLab >= 8.9 this way of doing things is just too much hassle. – Greg Dubicki Aug 17 '16 at 08:33
7

For GitLab versions < 8.9, without built-in export/import feature, I recommend a great tool from Marcus Chmelar, gitlab-migrator. I used it successfully many times with older GitLab versions so you should too. Just be aware of its limitations.

Community
  • 1
  • 1
Greg Dubicki
  • 5,983
  • 3
  • 55
  • 68