【转载】Git项目管理 第2章 基于Git的团队协同开发

原文来自http://wenku.baidu.com/view/55369c1252d380eb62946d58.html

很多时候我们是多个人同时为做一件事情而努力，如何有效化解多人协同运作过程中出现的种种矛盾是相当重要的。实践证明，Git 可以很好的胜任此类任务，这也是我们要在实验室内部推广Git 应用的主要原因。

2.1 两个人如何协同

Lyr 与Tzc 是本节的两位主角。现在假设Lyr 开始着手开发M2GE 库，并按照第1 章所讲述的Git 基本用法将M2GE 库纳于Git 的管理之下。但是，很快Lyr 就发现了仅凭个人之力很难在项目规定期限内完成这项工作，因此他邀请Tzc 来参与M2GE 库，故事就这样开始了。

Lyr 的M2GE 工作树为/work/m2ge ，Tzc 可通过以下命令获得与Lyr 同样的工作树：

$ cd work

$ git clone lyr@192.168.0.7:~/work/m2ge m2ge

git clone 可利用各种网络协议访问远端机器中的Git 仓库，从中导出完整的工作树到本地。在上述示例中，Tzc 通过SSH 协议访问了Lyr 机器上的lyr 账户的M2GE 仓库并进行导出，从而在当前目录下建立了m2ge 工作树。若上述命令中未指定本地工作树名，那么git clone 会在Tzc 当前所在目录中建立与Lyr 的M2GE 工作树同名的工作树，所以上述命令指定Tzc 的工作树名为m2ge 显得有些多余。注意，git clone 命令只要碰到类似以下格式的远端仓库地址，它就会认为该地址是符合SSH
协议的。

账户@IP:工作树路径

Tzc 既已获得M2GE 工作树，他就可以开始工作了，同时，Lyr 也在位于自己的机器上的M2GE 工作树中工作。在此期间，二人对位于各自机器上的M2GE 仓库的操作只需具备第1 章所讲述的内容足矣。一个阶段之后，二人均将所做的工作不断地提交到各自的Git 仓库中，直至他们觉得有必要将各自所做的工作合并起来之后再进行新的开发阶段。由于Lyr 作为主要开发者，二人的工作在他的机器上进行合并是比较自然的。当然在Tzc 机器上合并也未尝不可，因为Git 是不分主次仓库的，同一项目的不同仓库都是地位均等。为实现与Tzc
的工作合并，Lyr 执行了以下操作：

$ cd ~/work/m2ge

$ git pull tzc@192.168.0.5:~/work/m2ge

git pull 命令可将属于同一项目的远端仓库与同样属于同一项目的本地仓库进行合并，它包含了两个操作：从远端仓库中取出更新版本，然后合并到本地仓库。上述命令可在Lyr 的m2ge 仓库中完成对Tzc 机器上的myge 仓库的合并。如果Lyr 与Tzc 是对了不同的文件进行了改动，那么可以不费周折地完成仓库合并。但是倘若二人对一些相同的文件进行了改动，那么在合并时必然会遭遇合并冲突的问题，此时手动修改发生合并冲突的文件，然后将结果提交到本地仓库。由于处理合并冲突的问题比较复杂一些，所以下面单独拿出一个小节来讲述。当项目合并结束后，意味着Lyr
与Tzc 一个协同开发周期的结束，他们彼此很

欣赏对方的工作，所以又开始了下一个周期……

2.2 如何解决仓库合并冲突

现在假设Lyr 与Tzc 在各自的工作树中对同一份文件foo.txt 进行了修改，而

foo.txt 原内容如下：

one

two

three

Lyr 对foo.txt 进行了如下改动，并将该改动提交到本地仓库。

ONE

two

three

Tzc 对foo.txt 进行了以下改动，也将该改动提交到本地仓库。

one

two

THREE

当Lyr 在合并Tzc 的Git 仓库时，Git 会自动合并二人对foo.txt 的修改：

ONE

two

THREE

现在Lyr 工作树中的foo.txt 文件即包含了Lyr 的改动，也包含了Tzc 的改动，而且合并结果自动作为新版本提交到Lyr 的仓库中。观察上述合并冲突示例，可以看出，虽然Lyr 与Tzc 是对同一份文件进行了修改，但是他们的修改并未重叠。现在假设二人对foo.txt 的同一行做出了修改，那么在仓库合并时会发生什么，应当如何处理呢？

现在假定上述示例中，Tzc 对foo.txt 的修改如下：

one ONE

two

three

这样，二人对foo.txt 的同一行进行了不同的修改，当合并时，Git 会给出以下

反馈信息：

Auto-merged foo.txt

CONFLICT (content): Merge conflict in foo

Automatic merge failed; fix conflicts and then commit the

result.

上述信息之意是：尝试合并foo.txt 文件的改动发生了冲突，自动合并失败，请用户手动修复冲突然后将结果提交到仓库中。Lyr 看到上述信息，就打开了合并后的foo.txt，他看到了以下内容：

<<<<<<< HEAD:foo

ONE

=======

one ONE

>>>>>>> 1116d3270764d91a25532a753a47b8b0e1b6f1b8:foo

two

three

以一串< 开头的字串表示Lyr 的当前项目版本对foo.txt 的修改结果，而以一串> 开头的字串表示Tzc 的当前项目版本对foo.txt 的修改结果。中间用了一串= 号将二人修改结果隔开。一旦理解了版本冲突的表示格式，Lyr 就很容易地根据现实情况将合并冲突问题解决掉，他认为Tzc 的改动是不符合项目需求的，并且按照项目的实际需求进行了手工合并。最后，Lyr 将合并处理结果提交到仓库中，即完成了重叠冲突的合并问题的解决。

2.3 三人以至更多人如何协同

前文在讲述二人协同模式时，强调了Lyr 与Tzc 的主次关系，这种关系似乎对于三人以至更多人的协同也有效。现在我们再引入两位故事主角Lxc 与Zhu 来说明此问题。假设Lxc 与Zhu 仿照Tzc 那样从Lyr 那里git-clone 了一份项目仓库，进行了一番卓有成效的版本更新。最后，Lyr 需要一一取回其他三人的仓库，然后再一一合并方能完成一个协同周期，这些工作逐渐让Lyr 汗流浃背，疲于应付。因此Lyr 希望其他三人能够分担一下项目版本合并问题的处理工作。

Git 提供了git-pull 的对偶命令，即git-push。顾名思义，git-pull 命令负责从远端仓库取回版本更新，而git-push 可将本地版本更新推送到远端仓库中。利用git-pull 与git-push 命令，那么在一个协同周期之内，除了Lyr 之外，其余三人的项目开发流程大致如下：

$ git clone lyr@192.168.0.7:~/work/m2ge

... 项目开发...

$ git add 改动的文件

$ git commit

$ git pull

... 解决版本合并问题...

$ git push

在一个协同周期内，Lyr 对M2GE 仓库的管理工作相当于管理一份他个人项目一般，因为M2GE 库是位于他的机器上，他是不需要git-pull 与git-push 的。这样，一个基于Git 较为简单的三人以至更多人的协同工作模式被实现了，这是我们在尚未熟悉Git 应用之时比较稳妥的协同方案。下一节将基于这一方案讲述M2GE 库仓库的建立以及多人协同开发过程的具体实现。

2.4 M2GE 的协同开发

上一节所给出的三人及三人以上的协同工作模式有些不合理，譬如Lyr 过于特殊，别人都要git-pull 与git-push，唯独他不需要。现在要剥夺他的这一特权，最有效的办法就是将M2GE 仓库建立在实验室的服务器上。

首先，Lyr 通过SSH 登录到服务器，寻找合适位置，建立m2ge.git 目录，譬如

/project/m2ge.git ，然后初始化一个空仓库，以此作为M2GE 仓库：

$ mkdir -p ~/project/m2ge.git

$ cd ~/project/m2ge.git

$ git --bare init --shared

上述操作中，git-init 命令的--bare 选项可以让m2ge.git 目录等价于一个仓库。也就是说，m2ge.git 本来是一个工作树，但是--bare 选项将本应当存放在m2ge.git/.git 中的仓库内容全部放置在m2ge.git 目录下，就好像仓库完全的裸露在工作树中，所以称之为赤裸的仓库。

然后，Lyr 将自己机器上已经接受Git 管理的m2ge 仓库推送到服务器端的m2ge.git 仓库：

$ cd ~/work/m2ge

$ git push m2@192.168.0.2:~/project/m2ge.git master

上述git-push 命令中出现的master 参数的含义将在下一章讲述，此处可略过不谈。现在，大家已经得到了M2GE 仓库的最初版本，并且可以使用git-clone 命令

在本地创建工作目录：

$ git clone m2@192.168.0.2:~/project/m2ge.git

之后，我们就可以开始一个又一个协同周期，服务器上的m2ge.git 仓库将会逐次记录着每位协同开发者的版本更新提交，此基本过程可参考上一节所述内容来理解。

2.5 总结

本章讲述了基于Git 最基本的多人协同工作模式，并引入了三个新的Git 命令：git-clone、git-pull 与git-push。基于这三个命令并配合上一章所讲述Git 基本操作，足以实现M2GE 初级阶段的协同开发。