How to manage GIT repository hierarchies?

Question

I've used git in a distributed enviornment (including GitHub) in which developers work offline then push to the central repo. I now have a requirement for a more structured repository hierarchy because we have multiple offices. If we take an example we have developers based in Tallinn who will push to their remote repository. We also have developers in London who will push to their repository. We then need to merge the changes between the two remote repositories and pass them back to the developers in both sites. The hierarchy therefore looks something like this:

     
    Tallinn   -------   London 
       |                  |
 -------------      -------------
 |   |   |   |      |   |   |   |
Dev Dev Dev Dev    Dev Dev Dev Dev

Can someone recommend the best approach to implement this?

Answer 1

If there is on direct communication between Tallinn and London (meaning you cannot push directly from one central repo to another), that means Tallinn and London repos are essentially fork one from another.

Fork is more a social way of sharing versioned data, popularized by GitHub.
But the principle behind a GitHub fork still applies in your case: you will exchange data through patches (as in "using, for instance, git format-patch").

Even if your repos have no fork queue (like GitHub repos do), you will still have to manage the various patches coming on a given repo, and check they can be applied in a fast-forward manner.
I would recommend for that dedicated branches from this kind of update.

Answer 2

I think you need a "Common" repository hosted somewhere, linked to Tallinn and London. So each team can push and pull from it.

Answer 3

I'd pick a city to host the official master, and have someone responsible for merging the changes from both cities. Each city will have there own repo that dev's can commit to, and at the end of the day all the changes will get merge into the master repo. Then both city repo's will be updated from that.

               master
                 | 
    Tallinn   -------   London 
       |                  |
 -------------      -------------
 |   |   |   |      |   |   |   |
Dev Dev Dev Dev    Dev Dev Dev Dev

This is not all that different from how Linux works. 1 person controls the master, but instead of cities things are divided up by subsystems.

Answer 4

I'd set up a 'gatekeeper' who has access to both sets of repositories. This machine -- which can be a server or just a subdirectory on someone's machine -- has repositories that are set up with remotes from both offices. Then, for each repo that needs updating on both sides:

git pull talinn
git pull london
git push talinn
git push london

Note that either pull operation could result in merge conflicts that would require manual resolution. If you have a script doing this, it would have to punt those cases to a developer to fix. It's quite possible to just have a person do this task every so often instead, though.