I have a few projects under version control using Git.

Since it is a distributed version control system, it is very easy to have it hosted at multiple places (GitHub, Bitbucket, Google Code, etc.) which provides redundancy, and safety should some site go out of business or turn evil.

The problem is that when a new user clones the repository from location X, only X's remote is available by default in the clone. In order to be able to push changes to the other locations, all of them have to be added manually. This is error-prone and slightly tedious.

Hence the following question: Is it possible to save a set of git remotes inside the repository itself? This way, any clone would have all the remote URLs set up properly and there would not be a long setup required.

up vote 3 down vote accepted

No, there isn't. You could have something - documentation, or executable code - that would set up those remotes for people though.

Generally, though, I would expect that most people would only care about the one remote location. They don't really care about how you deal with your own backup strategy.

(Also, every git clone is a backup as strong as the remote provider, so the risks are somewhat more mitigated than your question might suggest.)

It would be better to use one remote as your master and then import (backup) from this into other services. I know codebase supports importing from public repos.

  • I guess that would be a good compromise, but is there any way to make commits propagate automatically from the master, then? – Etienne Perot Jan 30 '12 at 0:31
  • Well I know that codebase provides you with a sync url or hook that you can visit to trigger a pull from the master. – Wez Jan 30 '12 at 0:41

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.