Moving back to Github

Coming back to the fold #

While setting up my own git server was a fun exercise, the truth is no open-source contributor or prospective employer will go hunting the web for your personal repository.

In short, at least having your code on Github greatly increases the odds of your work seeing the light of day. To be sure, Gitlab has some great use cases that, as a single developer, I just don’t encounter:

• run Gitlab on-premises or in the cloud for free
• create nuanced groups and permissions for your team’s projects
• requiring full control over where code is stored
• etc

The whole reason I went to Gitlab in the first place was Github’s restriction of 5 personal repositories per account. But with the announcement of unlimited private repositories on Github, my main use case became invalid - needing more private repositories.

The migration back to Github was pretty straight forward:

1. Create a public or private repository on Github

2. Copy the new git url

3. In the Gitlab repository add a new remote like this:

git remote add github {{ Github repo URL}}

4. Simply push the branches you want on Github:

git push github master

There we go, migration complete and we have an exact mirror of our Gitlab repository with history, commits, branches, etc.

One interesting social caveat to Github is that public repositories are more like your portfolio than your work bench of half-finished projects. Looking at my Github profile, I had a grand total of 50 repos, most of it out-dated code or simply forked projects. After paring down my public repos to the projects I actually care about the total count is down to 21 repositories - how cathartic.

Next steps #

So now what? Well, after running my own git server for three months I discovered my main use of the server was for automated Continuous Integration tests. In my next post I’ll go over how to setup Continuous Integration using Github as a source.