2

We are in a situation with a distributed team where team members are of different companies and are not granted access to each other's servers. We work on one project and are having one git repository that needs to be synchronized. Both parts of the team (for reasons of simplicity calling them team A resp. B) are making changes.

  • Team A has access to server A, but not to server B
  • Team B has access to server B, but not to server A

We have no system that has access to both servers, and are not likely to get that anywhere soon.

How do we keep the repository synchronized among the different locations?

So far we have been trying the following approach(es) with little success.

Team A:

  • git clone --mirror https://server_a.com/repository_origin.git to get a full copy including all branches and tags from the original repository

  • Wrap the generated folder in a zip file and transfer to team B

Team B:

  • Extract zip

  • cd repository_origin.git

  • git remote set-url --push origin https://server_b.com/repository_mirror.git

Approaches

    • git push --mirror results in the changes of team B to be completely discarded, but all of the changes of team A have been merged into the mirrored repository, i.e. team B changes are not in the mirrored repository.
    • git fetch --all gets all the local changes of team B correctly
    • git push --mirror results in saying there are not changes, i.e. team A changes are not in the mirrored repository.

Obviously we also need to get changes from team B to the original repository, but without the way from A to B working as desired it doesn't seem very useful to try to get B to A to work as desired.

So we have tried these approaches, but neither worked. Does anyone have an idea how to address this? Of course we are hoping to get a solution with everyone working on the same original repository, but due to regulations that is not possible for now and the foreseeable future.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
Martijn Kamstra
  • 105
  • 2
  • 11

1 Answers1

3

Git was designed to support full-featured collaboration over email. The Pro Git book has a chapter discussing this, but basically you can generate changes using git format-patch, send them with git imap-send, and apply them on the other side with git am. Another chapter of the same book includes a short example.

This might feel low-tech, but it is a mature workflow that has worked well for development of Git itself.

If your teams have no way to directly clone an initial copy of the repository you could generate a bundle with git bundle and then clone from that.

If you don't like the email flow you can also use git bundle to update isolated systems. Generally speaking, git bundle is probably a better bet than zipping up clones manually.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257