设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
补丁
调试
外部系统
服务器管理
指南
管理
底层命令
- 2.13.7 → 2.49.0 没有更改
-
2.12.5
2017-09-22
- 2.11.4 没有更改
-
2.10.5
2017-09-22
- 2.3.10 → 2.9.5 没有更改
-
2.2.3
2015-09-04
- 2.1.4 没有更改
-
2.0.5
2014-12-17
描述
Git 与 CVS 的不同之处在于,每个工作树都包含一个存储库,其中包含项目历史的完整副本,并且没有哪个存储库比任何其他存储库更重要。但是,您可以通过指定一个人们可以同步的共享存储库来模拟 CVS 模型;本文档解释了如何做到这一点。
需要对 Git 有一些基本的了解。 经历过 gittutorial[7] 和 gitglossary[7] 应该就足够了。
针对共享存储库进行开发
假设共享存储库设置在 foo.com 主机上的 /pub/repo.git 中。那么作为单个提交者,您可以通过 ssh 克隆共享存储库,如下所示
$ git clone foo.com:/pub/repo.git/ my-project $ cd my-project
并开始进行开发。 cvs update 的等效命令是
$ git pull origin
这将合并自克隆操作以来其他人可能已经完成的任何工作。 如果您的工作树中有未提交的更改,请先提交这些更改,然后再运行 git pull。
注意
|
pull 命令知道从哪里获取更新,这是因为第一个 git clone 命令设置了某些配置变量; 有关详细信息,请参见 |
您可以通过首先提交更改,然后使用 git push 命令来更新共享存储库,其中命令如下
$ git push origin master
将这些提交“推送”到共享存储库。 如果其他人最近更新了存储库,则 git push(如 cvs commit)会报错,在这种情况下,您必须先提取任何更改,然后再尝试再次推送。
在上面的 git push 命令中,我们指定了要更新的远程分支的名称 (master
)。 如果我们省略该名称,则 git push 会尝试更新远程存储库中与本地存储库中的分支名称相同的任何分支。 因此,只要共享存储库没有除 master
以外的任何分支,就可以使用以下任何一种方式完成上次 push:
$ git push origin $ git push foo.com:/pub/project.git/
只要共享存储库没有除 master
以外的任何分支,就可以这样做。
设置共享存储库
我们假设您已经为您的项目创建了一个 Git 存储库,可能是从头开始创建,也可能是从 tarball 创建(请参见 gittutorial[7]),或者从已经存在的 CVS 存储库导入(请参见下一节)。
假设您现有的存储库位于 /home/alice/myproject。 创建一个新的“裸”存储库(没有工作树的存储库)并将您的项目提取到其中
$ mkdir /pub/my-repo.git $ cd /pub/my-repo.git $ git --bare init --shared $ git --bare fetch /home/alice/myproject master:master
接下来,授予每个团队成员对该存储库的读/写访问权限。 一种简单的方法是授予所有团队成员对托管存储库的计算机的 ssh 访问权限。 如果您不想在机器上为他们提供完整的 shell,则有一个受限的 shell,该 shell 仅允许用户执行 Git 推送和拉取操作; 请参阅 git-shell[1]。
将所有提交者放在同一组中,并使该组可以写入存储库
$ chgrp -R $group /pub/my-repo.git
确保提交者的 umask 最多为 027,以便他们创建的目录可以被其他组成员写入和搜索。
导入 CVS 归档
注意
|
这些说明使用 Git 附带的 git-cvsimport 脚本,但其他导入器可能会提供更好的结果。 有关其他选项,请参见 git-cvsimport[1] 中的说明。 |
首先,从 https://github.com/andreyvit/cvsps 安装 2.1 或更高版本的 cvsps,并确保它位于您的路径中。 然后 cd 到您感兴趣的项目的签出的 CVS 工作目录,并运行 git-cvsimport[1]
$ git cvsimport -C <destination> <module>
这会将已命名的 CVS 模块的 Git 归档放在目录 <destination> 中,如果需要,将创建该目录。
导入会从 CVS 中检出每个文件的每个修订版本。 据报道,cvsimport 平均每秒可以进行约 20 个修订版本,因此对于中型项目,这不应超过几分钟。 较大的项目或远程存储库可能需要更长的时间。
主干存储在名为 origin
的 Git 分支中,其他 CVS 分支存储在具有相同名称的 Git 分支中。 主干的最新版本也保留在 master
分支上检出,因此您可以立即开始添加自己的更改。
导入是增量的,因此如果您下个月再次调用它,它将提取在此期间所做的任何 CVS 更新。 为了使其正常工作,您不得修改导入的分支; 而是为自己的更改创建新分支,并在必要时合并导入的分支。
如果您想要一个共享存储库,则需要按照上述说明,创建导入目录的裸克隆。 然后,将导入的目录视为另一个开发克隆,以进行增量导入的合并。
高级共享存储库管理
Git 允许您指定称为“钩子”的脚本,以在某些点运行。 例如,您可以使用这些钩子将对共享存储库的所有提交发送到邮件列表。 请参阅 githooks[5]。
您可以使用更新钩子来强制执行更细粒度的权限。 请参阅使用更新钩子控制对分支的访问。
提供对 Git 存储库的 CVS 访问
也可以提供对 Git 存储库的真实 CVS 访问权限,以便开发人员仍然可以使用 CVS; 有关详细信息,请参阅 git-cvsserver[1]。
替代开发模式
CVS 用户习惯于授予一组开发人员对公共存储库的提交访问权限。 正如我们所看到的,这也可以通过 Git 实现。 但是,Git 的分布式特性允许其他开发模式,您可能需要首先考虑其中一种模式是否更适合您的项目。
例如,您可以选择一个人来维护项目的主要公共存储库。 然后,其他开发人员克隆此存储库,并在他们自己的克隆中工作。 当他们对一系列更改感到满意时,他们会要求维护人员从包含更改的分支中提取。 维护人员审查他们的更改,并将它们提取到主要存储库中,其他开发人员可以根据需要从中提取,以保持协调。 Linux 内核和其他项目使用此模型的变体。
对于小型团队,开发人员可能只需从彼此的存储库中提取更改,而无需中央维护人员。
GIT
属于 git[1] 套件的一部分