Master repository and local repositories in the same machine.

Question

I am new to Git. I have created a master repository in a linux server. The same server is going to be used by 5 groups of 3 users each. I want to create one local repository for each group. And the group members in turn should create one local repository for each of them, play with the contents and committ the modificatons to the group's local repository. How should i go about doing this?

Answer 1

You can create a copy of the master repository by running

git clone --bare /path/to/master/repository

in the directory where you want the copy to be created. I'd suggest doing this 5 times, in different paths, to create 5 different local copies of the master repository. Then each group member can run

git clone /path/to/group_local/repository

to create an individual copy of their group's local repository. So you have three "levels" of repositories: master, local, individual.

Whenever you clone a repository, unless you use the --bare option, git will set the remote.origin.url property of the clone to refer to the original. This means that if you run

git pull

in the clone, it will pull in changes from the original repository, and if you run

git push

in the clone, it will push changes from the clone to the original. So when your group members make their modifications in their individual repositories, they can run git push and those modifications will be "uploaded" to the local repository for their group. In the clone repository, it's also possible to copy changes from another repository (other than the one from which it was originally cloned, I mean) by specifying a URL (or the name of a preconfigured remote) to the git pull command. You can also push to an arbitrary other repository, although there are some things to watch out for if you're going to try that.

Answer 2

First off the bat I would recommend letting the users choose how many repositories they want, it is totally irrelevant and can only serve to create awkward situations.

The way I would organize it is inspred on the "Benevolent Dictator For Life" and Lieutenants model.

The BDFL is the person who integrates the changes from the lieutenants repositories into the toplevel repository master branch.

The lieutenants integrate the changes of the contributors in their repo. Preferably in some sensible branches. The developers push their working branch to the Lieutenant or the lieutenant pulls it from their repo, email a patchset, whatever works best.

Note that these 'integrations' can be largely automated using a CI server like hudson.

The contributors work in branches per task and merge regularly with the MASTER repository. Only in exceptional circumstances from the Lieutenants repo. (Now this only works when the speed moving up is fast enough). It is better to pull from the master to reduce the latency in the loop and to avoid 'unpleasantness' when one of the Lieutenants is sick.