ssh 多人_Git内幕系列三：Git多人协同

本文是Git内幕系列文章的第三篇，将简单介绍下多人协同工作模式下使用Git需要用到的一些命令和流程模型。

本系列其它文章请参考：

1. Git内幕系列一：理解Git
2. Git内幕系列二：Git基础命令
3. Git内幕系列三：Git多人协同

我们在上一篇文章中介绍了下在单人工作模式需要用到的一些Git命令，但在实际工作中，我们往往需要和其他同事协作来完成一个项目的开发。

1，多人协同工作案例

1.1，克隆已经存在的Git仓库

Git可以通过local、HTTP、HTTPS、SSH和它自己的Git协议来克隆一个已经存在的仓库。

1.1.1，本地克隆

本地克隆是最简单的一种克隆方式，它等价于拷贝.git目录然后执行一次checkout。

我们有可能在下面两种情况下使用这种克隆方式：

• 创建一个放在公共服务器上，不包含工作目录的供大家克隆的仓库（bare仓库）。
• 从其他人的NFS（网络文件系统）所共享的仓库进行克隆。

要执行本地克隆，使用类似下面的命令即可：

$ git clone --bare simplegit/.git simplegit-bare.git

优点：直接使用了现有的文件权限和网络访问权限，建立一个这样的版本管理系统是难度不大，对于小团队、小项目比较合适。

缺点：总体思路还是局限在局域网内，而且速度慢。

1.1.2，SSH协议

通过SSH协议进行克隆时，需要你拥有被克隆仓库所在服务器的用户帐密信息。

$ git clone git@github.com:schacon/ticgit.git ticgit_directory

优点：SSH 架设相对简单，协议自身也很安全和高效。

缺点：权限体系不灵活，必须提供操作系统层级的帐户密码。

1.1.3，HTTP&HTTPS协议

Git HTTP协议依懒于WEB容器(apache、nginx)及cgi 组件进行通信交互，并利用WEB容器本身权限体系进行授权验证。

$ git clone https://github.com/flyingww/petstore petstore

优点：解决了本地克隆与SSH协议权限验证单一的问题、可基于域名提供匿名服务，从而可以放到公网上去实现类似GitHub的功能，而本地克隆与SSH则很难做到这一点。

缺点：架设复杂，需要部署 WEB服务器，对于HTTPS协议还需要解决SSL证书问题。

1.2，获取最新代码

当我们克隆了一个远程的仓库后，如果想同步该仓库最新的代码到我们的本地，我们可以用"git fetch"或者"git pull"。

从功能上来说，"git pull"等价于"git fetch" + "git merge"。"git fetch"只会将远程仓库代码更新到分支".git/refs/remotes/<remote>/"（大部分情况<remote>为origin），而不会对你的工作目录做任何修改。当我们运行"git merge"后，才会将跟新合并到我们指定的分支。

下面的命令就是尝试将远程主机origin上所有更新取回本地：

$ git fetch origin

如果我们只希望获取远程主机origin上某一个分支比如master的改动，则可以使用：

$ git fetch orgin master

然后我们就可以在当前工作分支上运行merge命令来将改动合并到我们的工作分支了：

$ git merge origin/master

正如我们在前面提到的，我们也可以使用"git pull"来达到同样的目的。但很多人会建议你不要使用"git pull"，而是使用"git fetch" + "git merge"，主要原因是"git pull"会自动完成merge操作，这种自动化的、神不知鬼不觉的操作往往会让我们不知所措。

1.3，推送更新至远程仓库

我们已经可以从其它仓库获取更新，接下来我们介绍下如何使用"git push"将更新推送至远程仓库。push命令基本格式如下：

$ git push <远程主机名> <本地分支名>:<远程分支名>

如果省略远程分支名，则表示将本地分支推送到与之存在"追踪关系"的远程分支（通常两者同名），如果该远程分支不存在，则会被新建。例如：

$ git push origin master

上面命令表示，将本地的master分支推送到origin主机的master分支。如果后者不存在，则会被新建。如果当前分支与远程分支存在追踪关系，则本地分支和远程分支都可以省略，将当前分支推送到origin主机的对应分支，例如：

//如果在master分支上执行这个命令，则会推送至origin的master分支
$ git push origin

如果省略本地分支名，则表示删除指定的远程分支，同于推送一个空的本地分支到远程分支，例如：

$ git push origin :master

上面的命令等同于"git push origin --delete master"，亦即删除origin仓库的master分支。

2，Git工作流模型

当多人同时使用一个Git仓库来管理他们的开发任务时，可以采用不同的工作流模型。

2.1，中央仓库模型

图片引用自Scott Chacon的Git Internals: Source code control and beyond

在这种模型下，所有开发人员都能直接从中央仓库进行push或者pull。

这种模型对于小团队，且项目本身无需公开的场景比较合适。项目内所有成员都能很容易让自己的本地仓库和团队里其他人的改动保持同步。

2.2，独裁者模型

图片引用自Scott Chacon的Git Internals: Source code control and beyond

这是一种等级森严的模型。只有独裁者能够往一个"blessed"仓库提交代码，而其他人只能从这个"blessed"仓库拉取代码。

所有的"lieutenant"负责各自的子模块，并从下面的开发人员的仓库中fetch最新的改动交由独裁者审批，独裁者决定是否可以合并到"blessed"仓库。

还记得Linus的一句名言么？

My name is Linus, and I am your God.

Linux Kernel就使用这样的模型，Linus正是这位独裁者！

这种模型对于大型项目非常合适，可以让不同的"lieutenant"来负责不同子模块的开发，分工协作，统一管理。

2.3，Integration manager模型

图片引用自Scott Chacon的Git Internals: Source code control and beyond

这是社区型Git仓库比如GitHub使用的一种模型。

"Integration manager"可能是一个人或者一个核心团队，只有他们才有权利将改动推送到"blessed"仓库。

开发人员可以从"blessed"仓库拉取代码，或者将改动推送到各自的"开发分支（developer public）"。他们可以向"integration manager"发起pull request来提交各自的改动，后者会负责合并、测试、接受以及推送这些改动到"blessed"仓库。

今天就聊这么多，希望对大家有所帮助。

参考：

1. Git Internals: Source code control and beyond by Scott Chacon