33

I want to copy a GitLab project to another repository which should be completely independent from the original project.

For this reason, I tried forking the original project into another project. But inside the original project, the maintainer still can see a list of forks and knows where the other forks are maintained.

I want to have a complete copy without any link to the main project so it cannot be managed by the original project maintainer.

How can I do this?

4 Answers 4

37

Another option is to use Gitlab's export/import feature.

Existing projects running on any GitLab instance or GitLab.com can be exported with all their related data and be moved into a new GitLab instance.

The difference with the other answer is that it also copies the following:

Exported contents

The following items will be exported:

  • Project and wiki repositories
  • Project uploads
  • Project configuration, excluding integrations
  • Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities
  • Design Management files and data
  • LFS objects
  • Issue boards
  • Pipelines history
  • Push Rules

So it depends on your use-case if you want to copy just the codes or if you also want to also migrate the other non-code items as listed above. The result would still be 2 separate projects (i.e. It will not appear as a fork).

Take note that:

The GitLab import/export button is displayed if the project import option is enabled.

To export, go to your project's Settings > General page:

export

Then wait for the email with the downloadable tar.gz. file.
(On my version of Gitlab, if you click the button twice, you can download directly from the browser.)

Then to import, on Gitlab, select the New button > New Project from the top bar.
Then, select Import Project > Gitlab export.

Import

The UI screenshots above may change on future Gitlab versions. Again, make sure to refer to your Gitlab instance's docs pages, or check out the public one from Gitlab EE: Project import/export .

Sign up to request clarification or add additional context in comments.

2 Comments

FYI: Only specific to me perhaps, but using this method I had upload timeouts (probably our infrastructure) when attempting to re-import. So, I had to use a different method.
In my gitlab (GitLab Enterprise Edition v16.4.1-ee), exporting a project, added a Download button, which downloaded a .tar file to my Mac. The import failed as it was not .gz, so had to manually gzip the tar file first.
27

TL;DR

If all you need to migrate is the Git repo itself, you can clone the original project in a sandbox on your local machine, create the new project where you want it, set your new location as the remote and push there.

Notes

  • This answer is not specific to GitLab and will not copy Issues, MRs and other metadata. See @GinoMempin's answer if you need to migrate a complete GitLab project.

  • Since this answer uses only Git itself, it will work from any Git server to any other.

The fast approach: transit via a mirror

Assuming old_url and new_url are your old and new URLs:

git clone --mirror <old_url>
cd <repo_dir_name>
git remote add new_remote <new_url>
git push --all new_remote

If your new repo was empty when you did this, it will now contain all the branches that exist in the original repo, without any connections to it.

If you also want to push all your tags to the new remote, run this command next:

git push --tags new_remote

Note that you might have to create an empty repo on the new server before you do the push operations, depending on your new server's configuration.

The slower approach: transit via a regular sandbox

Some people have reported elsewhere that git clone --mirror doesn't always work as expected. If you're having trouble with the recipe above, you can use a regular sandbox instead:

git clone <old_url>
cd <repo_dir_name>
git remote add new_remote <new_url>
git push --all new_remote

With this approach, that git push --all will only push your main branch, because it only pushes all local branches, not all the remote tracking ones.

So checkout any branch you want to transfer to the new remote, and push it to the new remote. This is a somewhat slower process, but it also lets you control exactly what is being migrated, which can have its own benefits.

Again, you also need to push any tags you want to migrate, either all at once with git push --tags new_remote or one at a time.

Limitations

Migrating a Git repo via a clone will transfer everything that is managed by Git itself, but nothing else. If you have any MRs, issues, CI/CD, Wikis, etc, that you also want to migrate, you will have to use the export/import feature or another full migration approach.

3 Comments

This copies the code only. It doesn't do anything about project related items like issues, merge requests, milestones, etc.
Indeed, that is the great limitation of using Git itself to transfer a repo, because all that meta data is not actually part of the repo.
But often enough, that's all that's needed, so I prefer this simple solution when I don't need to transfer any of the metadata.
6

Another option, when you might not have access to the GitLab export project button, is to import directly from an url.

enter image description here

1 Comment

I tried this, it looks like it should work, but it just seems to hang...
3

Another option, in Setting >> General >> advance >> remove fork relations

it helps, to just remove all relations with upstream project.

1 Comment

This was an option I considered - your answer could be better and gain more upvotes if you include the whole process, e.g. start with forking the repo, then show how to remove the fork relationship, etc.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.