How to migrate from Gitlab to Github: the Intergiro way

Selecting a host for your git repositories can be an arduous task. There are many popular hosting places, all with different prices and conditions, so it can feel like there are too many options and always one with a better price or more interesting features. Recently, Gitlab, one of the major hosting hubs, changed their subscription model, becoming the reason for  many companies to reassess their budgets and make plans to migrate. This includes us here at Intergiro. How did we manage the migration? It was an interesting, albeit challenging, process. 

First of all, why Github? Microsoft-owned Github is one of the most popular repositories. Github offers comfortable prices and some security, CI/CD, and other features that other code hosts simply don’t have. To give an example, from our perspective, team management in Github is easy to use, understand and customize as needed, and it’s only one feature. With all these benefits in mind, Github was chosen for further migration.

Keep in mind that CI runners should be prepared for pipelines. Here there are two options: using Github Actions runners (remember, you always have some free minutes) or setting up self-hosted runners. Official documentation describes how to use any machine as self-hosted runner, but you can find more options: set up self-hosted runners using Docker or using Kubernetes. In our infrastructure Kubernetes, runners are used. Lifehack: you can use preemptible nodes in GKE or spot instances in AWS.  In this case, the associated costs will be less than if standard instances are used. Also, special tags for different types of pipelines can be attached.

Let’s move to the migration of real code. The best way to migrate from Gitlab to Github is to set up mirroring between repositories. Using mirroring, all changes can be pushed when you are working on configuring pipelines, permissions, etc. Additionally, you can always pull code locally, change the remote origin, and push it.

One of the most important things in git repositories is pipelines. The platform for CI/CD pipelines has the name “Github Actions”. You need to configure Github Actions workflow (its pipeline) for tests, lint, or deployments. Trigger of workflow, type of runners, and other details can be set up in workflow. Yaml files, where workflows are described, should be placed in .github/workflows/ directory. We highly recommend checking out this repository - here you can find many examples of workflows. 

Next step: setting up permissions. If you create the organization, you can create a lot of teams and assign necessary permissions to teams in settings. Here you can also configure secrets for Github Actions, rules for branches, webhooks, and many other aspects. These features are worth trying.

In conclusion, it’s necessary to say that there is no single best choice: all the popular git repositories have advantages and disadvantages. Regardless we suggest trying Github. Consider testing it using a free plan. Finally, check this table comparing Gitlab and Github - it’s based on our experience of migration: