12 Apr 2018

I’ve recently moved my repositories from GitHub to GitLab. I thought I share a quick post on why I did this and how to go about it.

Why Move?

GitLab has a number of advantages over GitHub for source code hosting:

Free private repositories – GitLab is financed by their Enterprise tiers, and have a free tier for personal projects and small teams. GitHub is free only for public repositories.

GitLab has built-in Continuous Integration/Delivery options built-in, and has a number of DevOps features available to integrate with your specific workflow.

GitLab has a wider range of options for creating project specific sites (using GitLab Pages), such as allowing you to use custom domains and SSL certificates for each project.

GitLab, unlike GitHub, has an open source community edition (with an MIT licence), allowing you to setup your own GitLab server to self-host.

GitLab has pretty much all the features that you expect from GitHub (Wikis, Markdown-based readmes, issue tracking). An important consideration for me was that GitLab, like GitHub, also offers Two Factor Authentication (2FA).

The disadvantages of moving to GitLab are:

As GitHub has been around longer, network effects mean that the majority of developers and projects are already using it. As of 2017, GitHub had some 26 million user and 67 million repositories.

Occasionally you can have slow UI performance.

Both offer integration with a number of third party services (such as Trello, Slack, Jenkins) but GitHub currently offers more integration options than GitLab.

How to Move

GitLab has made made migrating from GitHub very easy. Simply create a new project, and on the new project page, select the ‘Import project’ tab. From here, you can select the GitHub import option. You will then be asked to sign in to GitHub and to authorize GitLab to access your GitHub repositories. On doing this, you are taken to the GitHub Importer page, which lists your projects on GitHub. You can then select the projects to import to GitLab individually, or simply import them all:

Note, the import preserves the repositories commit history. Once the projects are successfully imported, you can then decide whether to delete the source projects on GitHub. I deleted all of my private repositories on GitHub, and maintained only my public projects.

As GitHub is the more popular site for hosting source code, I wanted to be able to keep hosting and updating my public projects there easily. I had thought initially to add GitHub as a second remote to the new GitLab repository, so I could update both GitHub and GitLab repositories from the command line. However, it turns out that GitLab offers the Repository Mirroring feature. From the GitLab documentation:

‘There are two kinds of repository mirroring features supported by GitLab:
push and pull. The push method mirrors the repository in GitLab
to another location, whereas the pull method mirrors an external repository
in one in GitLab.’

By configuring the public repositories to push to the corresponding GitHub repository, I can simply commit my code to the GitLab repo as normal, and the commits are automatically reflected in the mapped GitHub project.

Once the push mirroring was configured, I found that I could commit to GitLab and the code changes would be pushed to GitHub in a matter of seconds!

Migrating to GitLab was a very simple process, and so far, I’m very happy that I made the move.