Two identical git repositories

Question

We are using git for our project's source code, working in a large team. Now about half of the developers are leaving for the on-site phase of the project. This phase will involve heavy development, ie many commits. At the same time the other half left behind will also continue working on the code.

Unfortunately the on-site will only have intermittent and unreliable internet connection. Yet it is vital that the on-site team is able to synchronize (commit/push/pull) their changes between another. But it is also vital that changes made on the "central" git repository by the rest of the team in the office are available.

So I am looking for a setup that will allow the on-site team to work efficiently using git even if the internet is down for a prolonged period of time, but also to be able to synchronize to/from the office when internet is available.

Is there an easy and fool-proof way to do that?

My first idea: take a netbook with us to act as "server" and have a bare clone of the repository. Then have the on-site team change their origin to the netbook and push to and pull from the netbook. But the synchronization to the main repository is causing me some trouble. Doing a git push on the netbook works fine, but a git fetch does not return me changes made on the main repo. Additionally, I'm worried what would happen if a file was changed on both repos and there was a conflict - I suppose somebody would need to work on the netbook to resolve the conflict and commit it before synchronization can happen?

Answer 1

Your setup should work, so I'm not sure what's wrong with the fetching. However, when it comes to fetching from your company's central repo and resolving conflicts, this should be done locally : whenever the internet connection is up, one developer could fetch from the central repo, merge and resolve conflicts at his own computer, and push the results to both the central repo and the onsite repo. I believe one should never work directly on a repository that is being used as a server (and if it is a bare repository, which it should be, you can't work directly on it since there is no working copy). This also saves you from setting up the development environment on the onsite server.

Furthermore, the onsite developers shouldn't replace origin with the onsite repository; rather, they should add a new remote with git remote add , and call it eg onsite . Then, whenever one wants to do a pull , push or fetch , one can choose whether to use the company's central repo or the onsite repo.