-1

I am recently using a remote git server (my own computer), and the server malfunctioned and can't be remotely accessed.

I was wondering if there is a proper way to maintain TWO remote depositories, so that the second depository on my other computer can be automatically used when the first one fails?

My second question is how to automatically (e.g. via a script) to synchronize the primary and backup remote depositories periodically, and how can I change which one is the default/primary depo?

My daily use case is pretty simple, as follows:

git clone user@host:A.git
cd A
(modify code ..)
git add .
git commit -m "..."
git push
git pull ....

So, there is no branching and conflicts is not my concern here. The primary and the backup(s) repos should just be snapshots of the same work at different points of time. Some of them may be lagging behind because of accessibility issues.

P.S. I am not asking the basics of how to set up a (bare) remote depo, and do regular push-pulls using ssh. What I am asking is if there is a way to automatically switch between a primary and a backup repo when one of them fails.

Thanks.

--- EDIT ---

To clarify, my question boils down to this:

Is there a way to setup two remote repositories like a mirroring RAID (disk array), where

  1. a pull request pulls from the the most up-to-date repo, and a push request pushes changes to all live mirrors.

  2. If one of the repos went down, and come back again, it will pick up the changes accumulated in other repos.

Note: there is an old post here, which asks a related question. But the answers there did not address the synchronization problem, and what happens when multiple repos become out-of-sync.

Community
  • 1
  • 1
thor
  • 21,418
  • 31
  • 87
  • 173
  • You can setup a backup **R** epository just by cloning on another machine; If you start with that you can probably solve your own doubts - or at least then ask not-overly-broad/not-opinion-seeking questions. – AD7six May 17 '14 at 13:01
  • Well, I am seeking for a very specific solution. My current workflow is listed, and I was only asking how this could be adapted to work with an alternative repo. – thor May 17 '14 at 16:55
  • You might consider your problem very-specific, but it's several very generic things in one question which if answered completely is just someone's opinion of how to do it. Your current workflow is "I use git" - Your problem is not a snowflake =). – AD7six May 17 '14 at 17:15
  • I am not sure which part is being too generic. I can certainly clarify my question. But not much I can do beyond that. I am here only to ask a question. VonC's answer seems to be interesting and pointing to the right direction. Still reading. You might understand what this kind of questions are about if you read through the question and answers therein. – thor May 17 '14 at 17:16
  • k Let me break out some atomic questions from what you've asked: "How can I create a bare clone of a git repository? How Can I push to two remotes at the same time? How can I schedule a git pull for one git repository from another? How can I use post-receive to update another clone?". If you mix and match those bits together (and probably more bits) - that's your asked-question; which should be somewhat apparent from the answer below. – AD7six May 17 '14 at 17:20
  • @AD7six OK, there is certainly some misunderstanding about my question. You said things that I didn't say, and ask me to answer for it. I do not want to go into how you interpret my question. I don't see how that can help solve my problem or any problem. I don't have time for this, sorry. – thor May 17 '14 at 17:25

1 Answers1

1

You could maintain a second bare repo anywhere you want (like an usb disk), and push automatically on both remotes at once.
See "pull/push from multiple remote locations".

That or you can setup a script which does a backup, which is called in Git a bundle.
I have written recently a script which does:

You can run that script at any time: if no new commits have been created, it won't do anything.

The idea behind bundles is to save a repo as one file (much safer than saving a large number of files in a .git tree, and easier to copy around).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250