git.oblomov.eu Git - git/blob - Documentation/gitcvs-migration.txt

   1 gitcvs-migration(7)
   2 ===================
   3
   4 NAME
   5 ----
   6 gitcvs-migration - Git for CVS users
   7
   8 DESCRIPTION
   9 -----------
  10
  11 Git differs from CVS in that every working tree contains a repository with
  12 a full copy of the project history, and no repository is inherently more
  13 important than any other.  However, you can emulate the CVS model by
  14 designating a single shared repository which people can synchronize with;
  15 this document explains how to do that.
  16
  17 Some basic familiarity with Git is required. Having gone through
  18 linkgit:gittutorial[7] and
  19 linkgit:gitglossary[7] should be sufficient.
  20
  21 Developing against a shared repository
  22 --------------------------------------
  23
  24 Suppose a shared repository is set up in /pub/repo.git on the host
  25 foo.com.  Then as an individual committer you can clone the shared
  26 repository over ssh with:
  27
  28 ------------------------------------------------
  29 $ git clone foo.com:/pub/repo.git/ my-project
  30 $ cd my-project
  31 ------------------------------------------------
  32
  33 and hack away.  The equivalent of 'cvs update' is
  34
  35 ------------------------------------------------
  36 $ git pull origin
  37 ------------------------------------------------
  38
  39 which merges in any work that others might have done since the clone
  40 operation.  If there are uncommitted changes in your working tree, commit
  41 them first before running git pull.
  42
  43 [NOTE]
  44 ================================
  45 The 'pull' command knows where to get updates from because of certain
  46 configuration variables that were set by the first 'git clone'
  47 command; see `git config -l` and the linkgit:git-config[1] man
  48 page for details.
  49 ================================
  50
  51 You can update the shared repository with your changes by first committing
  52 your changes, and then using the 'git push' command:
  53
  54 ------------------------------------------------
  55 $ git push origin master
  56 ------------------------------------------------
  57
  58 to "push" those commits to the shared repository.  If someone else has
  59 updated the repository more recently, 'git push', like 'cvs commit', will
  60 complain, in which case you must pull any changes before attempting the
  61 push again.
  62
  63 In the 'git push' command above we specify the name of the remote branch
  64 to update (`master`).  If we leave that out, 'git push' tries to update
  65 any branches in the remote repository that have the same name as a branch
  66 in the local repository.  So the last 'push' can be done with either of:
  67
  68 ------------
  69 $ git push origin
  70 $ git push foo.com:/pub/project.git/
  71 ------------
  72
  73 as long as the shared repository does not have any branches
  74 other than `master`.
  75
  76 Setting Up a Shared Repository
  77 ------------------------------
  78
  79 We assume you have already created a Git repository for your project,
  80 possibly created from scratch or from a tarball (see
  81 linkgit:gittutorial[7]), or imported from an already existing CVS
  82 repository (see the next section).
  83
  84 Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
  85 repository (a repository without a working tree) and fetch your project into
  86 it:
  87
  88 ------------------------------------------------
  89 $ mkdir /pub/my-repo.git
  90 $ cd /pub/my-repo.git
  91 $ git --bare init --shared
  92 $ git --bare fetch /home/alice/myproject master:master
  93 ------------------------------------------------
  94
  95 Next, give every team member read/write access to this repository.  One
  96 easy way to do this is to give all the team members ssh access to the
  97 machine where the repository is hosted.  If you don't want to give them a
  98 full shell on the machine, there is a restricted shell which only allows
  99 users to do Git pushes and pulls; see linkgit:git-shell[1].
 100
 101 Put all the committers in the same group, and make the repository
 102 writable by that group:
 103
 104 ------------------------------------------------
 105 $ chgrp -R $group /pub/my-repo.git
 106 ------------------------------------------------
 107
 108 Make sure committers have a umask of at most 027, so that the directories
 109 they create are writable and searchable by other group members.
 110
 111 Advanced Shared Repository Management
 112 -------------------------------------
 113
 114 Git allows you to specify scripts called "hooks" to be run at certain
 115 points.  You can use these, for example, to send all commits to the shared
 116 repository to a mailing list.  See linkgit:githooks[5].
 117
 118 You can enforce finer grained permissions using update hooks.  See
 119 link:howto/update-hook-example.html[Controlling access to branches using
 120 update hooks].
 121
 122 Alternative Development Models
 123 ------------------------------
 124
 125 CVS users are accustomed to giving a group of developers commit access to
 126 a common repository.  As we've seen, this is also possible with Git.
 127 However, the distributed nature of Git allows other development models,
 128 and you may want to first consider whether one of them might be a better
 129 fit for your project.
 130
 131 For example, you can choose a single person to maintain the project's
 132 primary public repository.  Other developers then clone this repository
 133 and each work in their own clone.  When they have a series of changes that
 134 they're happy with, they ask the maintainer to pull from the branch
 135 containing the changes.  The maintainer reviews their changes and pulls
 136 them into the primary repository, which other developers pull from as
 137 necessary to stay coordinated.  The Linux kernel and other projects use
 138 variants of this model.
 139
 140 With a small group, developers may just pull changes from each other's
 141 repositories without the need for a central maintainer.
 142
 143 SEE ALSO
 144 --------
 145 linkgit:gittutorial[7],
 146 linkgit:gittutorial-2[7],
 147 linkgit:gitcore-tutorial[7],
 148 linkgit:gitglossary[7],
 149 link:everyday.html[Everyday Git],
 150 link:user-manual.html[The Git User's Manual]
 151
 152 GIT
 153 ---
 154 Part of the linkgit:git[1] suite.