You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
171 lines
6.8 KiB
171 lines
6.8 KiB
git for CVS users |
|
================= |
|
|
|
Git differs from CVS in that every working tree contains a repository with |
|
a full copy of the project history, and no repository is inherently more |
|
important than any other. However, you can emulate the CVS model by |
|
designating a single shared repository which people can synchronize with; |
|
this document explains how to do that. |
|
|
|
Some basic familiarity with git is required. This |
|
link:tutorial.html[tutorial introduction to git] should be sufficient. |
|
|
|
Developing against a shared repository |
|
-------------------------------------- |
|
|
|
Suppose a shared repository is set up in /pub/repo.git on the host |
|
foo.com. Then as an individual committer you can clone the shared |
|
repository over ssh with: |
|
|
|
------------------------------------------------ |
|
$ git clone foo.com:/pub/repo.git/ my-project |
|
$ cd my-project |
|
------------------------------------------------ |
|
|
|
and hack away. The equivalent of `cvs update` is |
|
|
|
------------------------------------------------ |
|
$ git pull origin |
|
------------------------------------------------ |
|
|
|
which merges in any work that others might have done since the clone |
|
operation. If there are uncommitted changes in your working tree, commit |
|
them first before running git pull. |
|
|
|
[NOTE] |
|
================================ |
|
The `pull` command knows where to get updates from because of certain |
|
configuration variables that were set by the first `git clone` |
|
command; see `git config -l` and the gitlink:git-config[1] man |
|
page for details. |
|
================================ |
|
|
|
You can update the shared repository with your changes by first committing |
|
your changes, and then using the gitlink:git-push[1] command: |
|
|
|
------------------------------------------------ |
|
$ git push origin master |
|
------------------------------------------------ |
|
|
|
to "push" those commits to the shared repository. If someone else has |
|
updated the repository more recently, `git push`, like `cvs commit`, will |
|
complain, in which case you must pull any changes before attempting the |
|
push again. |
|
|
|
In the `git push` command above we specify the name of the remote branch |
|
to update (`master`). If we leave that out, `git push` tries to update |
|
any branches in the remote repository that have the same name as a branch |
|
in the local repository. So the last `push` can be done with either of: |
|
|
|
------------ |
|
$ git push origin |
|
$ git push foo.com:/pub/project.git/ |
|
------------ |
|
|
|
as long as the shared repository does not have any branches |
|
other than `master`. |
|
|
|
Setting Up a Shared Repository |
|
------------------------------ |
|
|
|
We assume you have already created a git repository for your project, |
|
possibly created from scratch or from a tarball (see the |
|
link:tutorial.html[tutorial]), or imported from an already existing CVS |
|
repository (see the next section). |
|
|
|
Assume your existing repo is at /home/alice/myproject. Create a new "bare" |
|
repository (a repository without a working tree) and fetch your project into |
|
it: |
|
|
|
------------------------------------------------ |
|
$ mkdir /pub/my-repo.git |
|
$ cd /pub/my-repo.git |
|
$ git --bare init --shared |
|
$ git --bare fetch /home/alice/myproject master:master |
|
------------------------------------------------ |
|
|
|
Next, give every team member read/write access to this repository. One |
|
easy way to do this is to give all the team members ssh access to the |
|
machine where the repository is hosted. If you don't want to give them a |
|
full shell on the machine, there is a restricted shell which only allows |
|
users to do git pushes and pulls; see gitlink:git-shell[1]. |
|
|
|
Put all the committers in the same group, and make the repository |
|
writable by that group: |
|
|
|
------------------------------------------------ |
|
$ chgrp -R $group /pub/my-repo.git |
|
------------------------------------------------ |
|
|
|
Make sure committers have a umask of at most 027, so that the directories |
|
they create are writable and searchable by other group members. |
|
|
|
Importing a CVS archive |
|
----------------------- |
|
|
|
First, install version 2.1 or higher of cvsps from |
|
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make |
|
sure it is in your path. Then cd to a checked out CVS working directory |
|
of the project you are interested in and run gitlink:git-cvsimport[1]: |
|
|
|
------------------------------------------- |
|
$ git cvsimport -C <destination> <module> |
|
------------------------------------------- |
|
|
|
This puts a git archive of the named CVS module in the directory |
|
<destination>, which will be created if necessary. |
|
|
|
The import checks out from CVS every revision of every file. Reportedly |
|
cvsimport can average some twenty revisions per second, so for a |
|
medium-sized project this should not take more than a couple of minutes. |
|
Larger projects or remote repositories may take longer. |
|
|
|
The main trunk is stored in the git branch named `origin`, and additional |
|
CVS branches are stored in git branches with the same names. The most |
|
recent version of the main trunk is also left checked out on the `master` |
|
branch, so you can start adding your own changes right away. |
|
|
|
The import is incremental, so if you call it again next month it will |
|
fetch any CVS updates that have been made in the meantime. For this to |
|
work, you must not modify the imported branches; instead, create new |
|
branches for your own changes, and merge in the imported branches as |
|
necessary. |
|
|
|
Advanced Shared Repository Management |
|
------------------------------------- |
|
|
|
Git allows you to specify scripts called "hooks" to be run at certain |
|
points. You can use these, for example, to send all commits to the shared |
|
repository to a mailing list. See link:hooks.html[Hooks used by git]. |
|
|
|
You can enforce finer grained permissions using update hooks. See |
|
link:howto/update-hook-example.txt[Controlling access to branches using |
|
update hooks]. |
|
|
|
Providing CVS Access to a git Repository |
|
---------------------------------------- |
|
|
|
It is also possible to provide true CVS access to a git repository, so |
|
that developers can still use CVS; see gitlink:git-cvsserver[1] for |
|
details. |
|
|
|
Alternative Development Models |
|
------------------------------ |
|
|
|
CVS users are accustomed to giving a group of developers commit access to |
|
a common repository. As we've seen, this is also possible with git. |
|
However, the distributed nature of git allows other development models, |
|
and you may want to first consider whether one of them might be a better |
|
fit for your project. |
|
|
|
For example, you can choose a single person to maintain the project's |
|
primary public repository. Other developers then clone this repository |
|
and each work in their own clone. When they have a series of changes that |
|
they're happy with, they ask the maintainer to pull from the branch |
|
containing the changes. The maintainer reviews their changes and pulls |
|
them into the primary repository, which other developers pull from as |
|
necessary to stay coordinated. The Linux kernel and other projects use |
|
variants of this model. |
|
|
|
With a small group, developers may just pull changes from each other's |
|
repositories without the need for a central maintainer.
|
|
|