By Abhijit Menon-Sen <firstname.lastname@example.org>
This tutorial explains how to share a Git repository among developers. It is meant for small teams who are adopting Git for the first time, and want to get started quickly with a familiar setup before exploring Git's many new possibilities.
If you follow this route, you will end up with a single centrally-hosted repository that everyone in your group can use to publish their own work and fetch whatever others have published. People used to a centralised VCS will find this model easy to adjust to, but of course, each user's "working copy" will itself be a fully-fledged Git repository, and many new workflows are available to users as they learn more.
It would help if you're familiar with basic Git terminology and usage, but if not, you can skim through to find out which commands you need to read about and experiment with. (I recommend Git from the bottom up and the Git tutorial for an introduction.) I shall assume that everyone has git 1.6.5 or later installed, and that they have ssh access to the server that will host the repository.
In the ideal case, you create a repository on the server, clone it on each workstation, and are ready to start work. That happy situation is described below, as well as the all-too-likely addition of an existing repository into the picture.
$ git init --bare --shared foo.git Initialized empty shared Git repository in /git/foo.git/ $ chgrp -R dev foo.git
It doesn't matter what user you run this command as. The
Let's say the server is named
This can be done in many ways. My advice is to set up the new repository on the server, push everything from the old repository into it, and forget about the old repository.
$ cd existing.git $ git push ssh://example.org/git/foo.git '*:*' Counting objects: 3, done. Writing objects: 100% (3/3), 204 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To ssh://example.org/git/foo.git * [new branch] master -> master
The output above is from a test repository with a single commit. The
(Why forget about the old repository? It's just simpler that way, but if you really want, you can configure it to pretend that it's just another clone of the new repository.)
Each user can now create their own copy of the central repository:
$ git clone ssh://example.org/git/foo.git Initialized empty Git repository in /home/ams/foo/.git/
This clone is now configured to track the central repository, which means that
(Note: You'll see a warning about having cloned an empty repository if you didn't push anything into
Let's pretend the original repository looks like the following diagram. The dots are commits, and there are two branches named
The newly-cloned repositories can refer to the central repository as "origin", which is just a handy alias for the full
Instead, you should create a local branch that follows or tracks any remote branch you're interested in; and this is done automatically for the default branch, conventionally named
When multiple people push commits to a shared origin, the update process involves an extra step. Suppose you push a commit while a colleague creates a new local commit of her own. When she tries to
If the various commits do not conflict, Git will merge them with no intervention. Otherwise, it will merge any non-conflicting changes automatically and ask you to resolve the remaining conflicts by hand. Run
You can create new local branches with
If you do not explicitly push your new local branches, they stay in your repository and are invisible to others.
You can also use
Pulling and pushing can be much more flexible than described here—you can specify what branches to track and update automatically, have different local names for branches, and so on. See
Git offers many other workflow and configuration possibilities. Here are a few directions to explore.
Use hooks to automate tasks like sending email to the developers for every commit or enforcing coding standards.
There are graphical frontends like git-cola and QGit, and repository browsers like gitk and Gitweb (both distributed with Git). Use them to browse history and assign blame. Use git-bisect to find out which commit broke a particular test case.
You may eventually need to provide read-only repository access to people outside your own team/network—set up git-daemon. To give someone write access, just give them an ssh account on the server; or install gitolite (the better-documented and better-maintained alternative to gitosis) for fine-grained access control and easier user management.
With more users, the "everything in the master branch" model described here may prove inadequate. There are many workflows that take advantage of Git's easy branching and merging, such as this nicely-illustrated one and the suggestions ingitworkflows(7). Even if you adopt a more decentralised approach, you can keep using your formerly-central repository as a fixed point of contact and for backups.