Using Git with multiple servers

Question

I have a set of servers with code bases on them. lets call them p1, p2, p3. I have a development server which i use to store the code d1. Each p server is different with a different code base.

I'm trying to figure out how to manage the git repo's correctly so that each of the "p" servers keep the "d1" server up to date.

here's what i did.

1. Create a git repo on p1 and initial commit.
2. created a --bare clone of the repo and scp'd it to the d1 server.
3. Repeated this for all servers.

my d1 server now has a /git/ folder with subfolders

p1, p2,p3. each of these has the normal content of

HEAD Branches config description hooks info objects refs.

I can clone these repos to another machine or folder and i get to see the actual files which is exactly what i wanted.

OK so here is my problem.

How to I keep the p1 repo up to date when someone clones the d1 copy and commits to it.

Do I need to run git fetch on p1

or should i have people change p1 and then git push to d1.

Answer 1

you can implement mirroring with gitolite to keep a central server with all the latest code from the others

from http://gitolite.com/gitolite/mirroring.html

Mirroring is simple: you have one "master" server and one or more "slave" servers. The slaves get updates only from the master; to the rest of the world they are at best read-only.

In the following pictures, each box (A, B, C, ...) is a repo. The master server for a repo is colored red, slaves are green. The user pushes to the repo on the master server (red), and the master server -- once the user's push succeeds -- then does a git push --mirror to the slaves. The arrows show this mirror push.

The first picture shows what gitolite mirroring used to be like a long time ago (before v2.1, actually). There is exactly one master server; all the rest are slaves. Each slave mirrors all the repos that the master carries, no more and no less.

This is simple to understand and manage, and might actually be fine for many small sites. The mirrors are more "hot standby" than anything else.

But when you have 4000+ developers on 500 repos using 25 servers in 9 cities, that single server tends to become a wee bit stressed. Especially when you realise that many projects have highly localised development teams. For example, if most developers for a project are in city X, with perhaps a few in city Y, then having the master server in city Z is... suboptimal :-)

And so, for about 3 years now, gitolite could do this:

You can easily see the differences in this scenario, but here's a more complete description of what gitolite can do:

Different masters and sets of slaves for different repos.

This lets you do things like:

Use the server closest to most of its developers as the master for that repo. Mirror a repo to only some of the servers. Have repos that are purely local to a server (not mirrored at all). Push to a slave on demand or via cron (helps deal with bandwidth or connectivity constraints). All this is possible whether or not the gitolite-admin repo is mirrored -- that is, all servers have the exact same gitolite-admin repo or not.

Pushes to a slave can be transparently forwarded to the real master.

Your developers need not worry about where a repo's master is -- they just write to their local mirror for all repos, even if their local mirror is only a slave for some.