The lesson to be learned here is "Don't use GitHub."

Use something that you can run your own instance of (like GitLab) and make the cloud version a shadow copy of your local one. That way if they pull the rug out from under you, you actually have some way of dealing with the issue.

That's why I set up my github and gitlab to mirror each other. gitlab can even automatically get the latest changes from my github repo. too bad github can't do this yet [1].

[1]: https://github.com/isaacs/github/issues/415

Put another way, do not treat Github/lab/Bitbucket as file hosting. As a repository it's fine, because it is assumed you have a local copy.

Don't put all your projects in one cloud

And... Use Gitlab

Gitlab too had incidents, remember db backup fiasco ? I know few devs that lost issues and wikis that day.

Just backup your repos once a year, lets not be paranoid.

In case of GitLab, the incident was caused by a human error, and they worked hard to fix it afterwards. GitHub and DigitalOcean (to name the ones recently mentioned on HN) have delibrately set up automated kill switches with no possibility of appeal, sans crying on Twitter. Sure, when data is lost then it may not matter in the end, but I'm still more sympathetic to the former.

Indeed, how GitLab handled the incident was exemplary. That is entirely different topic.

Here's the blog post about it https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-...

Yeah sure. But since Gitlab is possible to run self-hosted, you can back up the entire instance from the public cloud to the self-hosted version. That's pretty great.

By the same logic you can have a script that does git pull locally as cron job all the time along with exporting issues (wikis are just another implicit repo).

The point was that nobody does that for backup purposes in advance, and maintaining local Gitlab along with supportive infrastructure is not trivial task.