How to avoid Microsoft’s GitHub takeover

Migrating, mirroring, and self-hosting as alternatives to Microsoft's GitHub.

You might have heard the (good? bad?) news that Microsoft acquired GitHub, the popular service that’s home to many a developer’s entire life’s work. Many developers are some combination of horrified, annoyed, and worried, and that’s not entirely unexpected—humans are creatures of habit, and we like reliability. Now that Microsoft has taken over, it’s not as easy to forecast GitHub’s new long-term direction.

Will they start charging open source projects for hosting their code? Will they close down projects from competitors of theirs? Or will GitHub operate independently, only bolstered by a bit of Microsoft’s deep coin curse?

It’s impossible to say. But, I think, this new has forced many developers to second-guess the industry’s near-complete reliance on a single source for collaboration on and distribution of code. People are starting to wonder if there are better, or smarter, alternatives.

Let’s talk avoidance. Or, more specifically, mitigation.

GitLab to the rescue?

The name is similar, but unlike GitHub, GitLab is entirely open source. Big teams who want their code hosted in a managed, safe environment can pay for enterprise-level plans, but nothing is stopping you from self-hosting a GitLab instance on a server of your own.

More on that in a moment.

Anecdotally, GitLab has already seen a massive spike in imported projects via their GitHub Importer tool monitor. As of writing, GitLab is spitting out 502 errors due to being overloaded with all the new demand.

The GitLab 502 page.

There is a clear demand for what’s perceived to be a more “free” home for projects, both open and closed source, that use Git for version control. If and when you can access their service again, it might make sense to duplicate your codebase on GitLab using their free plan, if only for the sake of redundancy.

For more information about the GitHub importer and its syntax, check out the documentation.

GitLab is a great stepping stone, but I’ve already heard that GitLab might someday be acquired by another tech multinational now that they’ve seen the market value in the service they’re offering. In the short-term, GitLab might be a good choice, but if the developer community transfers its affinity from one company to another, they might be setting themselves up for disappointment.

Start mirrroring

A few years ago, Git added the capability to have more than one remote for a given repository. For example, you can add more than one push URL for a given remote (origin in this case):

$ git remote set-url --add --push origin git://github/repo.git
$ git remote set-url --add --push origin git://gitlab/repo.git

Now, when you execute git push origin master, your master branch code will be pushed to both remotes, one after the other. You can add others, too, if you want to triple, quadruple, or many-uple your code.

If you’d rather name your remotes differently, you can do so:

$ git remote set-url --add --push github git://github/repo.git
$ git remote set-url --add --push gitlab git://gitlab/repo.git

You can then create a git pushall alias to simplify your time on the command line—change the variables according to your needs:

git config alias.pushall '!git push github master && git push gitlab master'

Git aficionados will note that having multiple remotes could create issues or new complexities—what happens if developer A makes a change on GitHub while developer B makes another change on GitLab?—but figuring out those challenges are more about proactively setting up VCS standards. For single developers or small teams who want a “copy” of their code in another place, mirroring in this way is perfectly safe.

Self-hosting for ultimate control

Mirroring your code endlessly to any number of remotes managed by other businesses is one option, but others might be interested in taking complete control of their code via self-hosting a Git repository on their virtual private server (VPS).

For a primer on self-hosting, check out our beginner’s guide, [](What the Heck is Self-Hosting? A Guide to ‘Owning’ Your Webapps).

As mentioned earlier, GitLab has a self-hosted version that you can install right now on your VPS. It’s free, with some limitations, but it’s a good start. We even have a tutorial on installing GitLab, and it’s incredibly straightforward.

If you want to try something entirely free, might I suggest Gitea? Installing from the binary is silly easy:

$ wget -O gitea
$ chmod +x gitea
$ ./gitea web

Going the Docker route is also very straightforward. Either way, you’ll have a fully-functional and powerful web-based management tool for all your Git-based code.

[cta text="Self-host your code for the ultimate in power." text2="16GB RAM and KVM for 90% less than the competition." button="Deploy a better Git"]

I even added Gitea to my current self-hosted docker-compose stack without much trouble. I just needed to add a few extra environment variables and get the ports sorted. I run my stack behind the nginx-proxy container as explained in this tutorial on hosting multiple websites with SSL, so it’s not the most simple setup, but it works great!

    image: gitea/gitea:latest
    container_name: gitea
      - [email protected]
      - USER_UID=1000
      - USER_GID=1000
      - ROOT_URL=https://gitea.DOMAIN.TLD
      - DOMAIN=gitea.DOMAIN.TLD
      - PROTOCOL=http
      - VIRTUAL_PORT=3000
    restart: unless-stopped
      - proxy-tier
      - default
      - ./gitea:/data
      - "5000:3000"
      - "222:22"

See my entire docker-compose.yml file for more details. Yes, I understand the irony in using the GitHub “gist” feature for this. Let’s just roll with it.

There are plenty of other Git systems available for self-hosting—for more, check out our ultimate guide to self-hosting/SaaS app alternatives.

The future of Git

Overall, I think the Microsoft acquisition is a positive step for the broader development community. There’s a decent chance that, with some new cash and a massive company behind it, GitHub will do even more amazing things. As I’m writing this very post with Visual Studio Code, I’m not allowed to be entirely skeptical of Microsoft’s commitment to open source.

And, yes, I’m aware of the company’s “embrace, extend, and extinguish” past.

Even if we avoid disaster with GitHub’s future, we’re starting to second-guess our reliance on a single system. We’re beginning to wonder whether code quality has anything to do with a network of grade-school-esque popularity contests, like accumulating stars. We’re starting to branch out and get smarter about our code. This is all good news.

Plus, I’ve always thought giving an entire codebase a “star,” like it were a mildly amusing tweet, was a little silly. Talk about a network effect.