The October 2018 day-long GitHub outage led many to consider having a live backup of their Git repos. This functionality is intrinsic to Git itself, and is trivial to configure for an arbitrarily large number of backup sites (GitHub, GitLab, Bitbucket, Dropbox, …).
This article covers the typical case where the main Git repository is on GitHub, but a public backup is desired on GitLab or similar site.
The article assumes an existing working GitHub repo cloned to your computer
We also assume SSH keys on both
Use different SSH key pairs for each site for best security.
Back up the GitHub repo
username/myprog to GitLab with every
git push automatically as in the following section.
GitHub with GitLab backup
- check that the GitHub repo is setup normally on your computer:
cd myprog git remote -v
should be like:
origin https://github.com/username/myprog (fetch) origin ssh://github.com/username/myprog (push)
- Create a new repo
username/myprogon GitLab or other backup site
- Add the GitLab (or other) backup site:
git remote set-url origin --push --add ssh://github.com/username/myprog git remote set-url origin --push --add ssh://gitlab.com/username/myprog
- Verify that BOTH
pushsites are there (in this example, github.com and gitlab.com):
git remote -v
should be like:
origin https://github.com/scivision/pymap3d (fetch) origin ssh://gitlab.com/username/myprog (push) origin ssh://github.com/username/myprog (push)
When pushing, you will see multiple
Everything up-to-date – one for each site you’re pushing to.
At this time of this writing, GitLab enables by default AutoDevOps on every GitLab repo, existing and new. The goal is to ease use of GitLab’s fully integrated CI/CD stack, which historically / ironically was significantly more cumbersome to configure .gitlab-ci.yml than say Travis-CI .travis.yml or AppVeyor with GitHub.
However, AutoDevOps consumes 15 minutes or more of
GitLab Runner quota
git push for private GitLab projects.
The free GitLab plan has 2000 minutes/month for private projects, resetting on the first day of each month.
Even if your projects are public (thus without GitLab Runner limits), you may want to save the error messages and resource usage by including a do-nothing
.gitlab-ci.yml in each repo:
job: script: echo
Don’t use a blank
.gitlab-ci.yml as that will produce CI errors.
At the time of this writing, GitLab.com users don’t have a way to shut off AutoDevOps for all projects. That missing feature will hopefully be corrected.