git push to multiple sites

The October 2018 day-long GitHub outage led many to consider having a live backup of their Git repos. Multi-remote git push is intrinsic to Git itself. Thus, automatic multi-site pushes are easy 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 username/myprog. We also assume SSH keys on both GitHub and GitLab. 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

  1. 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)
    
    1. Create a new repo username/myprog on GitLab or other backup site
    2. 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
  2. Verify that BOTH push sites are there (in this example, github.com and gitlab.com):

    git remote -v 

    should be like:

    origin  https://github.com/username/myprog (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.

    Notes

    Disable GitLab AutoDevOps

    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 on every 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. While public projects are without GitLab Runner limits, you may want to save the error messages and resource usage by disabling AutoDevOps.

    Disable AutoDevOps on a per-project basis by either:

    • visit https://gitlab.com/username/myprog/settings/ci_cd → “Auto DevOps” → uncheck “Default to Auto DevOps pipeline”. Ensure you do not have a file at the top of your repo named .gitlab-ci.yml or the pipeline will run anyway. Verify there isn’t a pipeline running after you push by visiting https://gitlab.com/username/myprog/pipelines
    • include 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.