git合作流程（collaborator模式和contributor模式）

前言：github的三种合作模式：1）fork；2）organization；3）collaborator，开发者在这三种模式下的权限依次升高。

合作者模式：

假设我们有两个合作者A和B共同开发维护一个代码仓库(repository)，其中A是仓库的拥有者，他可以为项目添加合作者。

A在他github项目主页的Settings——Collaborators里面进行添加，邀请B为合作者。B在收到邀请提醒后，可选择接受邀请。B此时拥有了A所创建项目的直接读写权利。

注意虽然此时B已经是该项目的作者之一，但此时在B的github个人主页上不能看到该项目的repository，因为这个repository并不是B所拥有(创建)的。可以在B账户的setting下的repository部分查看https://github.com/settings/repositories，或者点击github主页面也可看到https://github.com/。

注：如果希望项目既有collaborator同时又可以限制他们的读写权利，尤其是限制其“写”的权利，可利用organization来为team成员赋予不同等级的权力。详见github中organization的相关操作。

contributor模式：每个合作者在他们fork的仓库上进行代码修改、发布自己负责的部分，再向主仓库提起pull request

collaborator模式：每个合作者新建自己部分的feature branch，在这个新分支上进行代码修改，然后提起向master branch的pull request

collaborator模式适合用于一个小型的、信任度较高的团队中，因为此时几个合作者都拥有了最高“写”权限。这种模式下，不需要像contributor模式那样让每个合作者对原仓库进行fork，而是可以把这几个合作者看成一个人在工作，遵从git flow的方式，从而以创建不同branch的方式进行合作开发。事实上，在最早的git中branch和fork间区别并不大，所以对于一个高度互信的小型团队。利用branch特性来进行合作开发就足够了。

B访问到A的项目仓库后，可将其项目克隆到自己的本机上，然后在本机上进行开发。开发时，为了便于代码审查以及防止冲突，应另开分支再开发。比如新建自己部分的feature branch，在这个分支下开发好后，可直接push到远端，注意此时会直接推送到A的项目仓库下，因为B作为合作者拥有A创建的项目的直接“写”权力。

此时查看A的项目主页，会提醒你最近push了一个branch到该仓库下，你可以选择Compare & pull request，从而试图将你在新分支下所作的代码修改merge到该项目的master分支上去。如下图所示：

 

如果一切顺利的话，点击Compare & pull request之后会提示“This branch has no conflicts with the base branch”.说明新分支可以被顺利融合到主分支上去。如下图所示：

由于你(B)本身就是项目合作者，所以拥有权力决定是否批准该pull request。如果你觉得可以的话，就直接点击Merge pull request，从而使得新分支内容merge到主分支上去。

评注：可见，以合作者模式开发项目代码时，仿佛你就是该项目的创建者，你拥有最高权限。

贡献者模式：

首先，无论B是否为A创建的项目的合作者，如果以这种模式进行合作，B都需要fork A的项目仓库，从而在B的主页上得到A的代码仓库的一份拷贝；然后B需要将该仓库clone克隆到他的本地硬盘上去成为本地代码库再进行后续修改。此时，在B的本机上得到的是主分支，即master分支。

为了进行开发，B可以选择在本地新建一个其他分支并在这个新分支上进行开发。使用命令：git checkout -b new_branch创建并切换到新分支“new_branch”。

然后在这个新分支下进行代码修改和开发。

写好代码后，需要推送到远端，可使用命令：git push origin new_branch。这个命令省略了远端分支名，由于该名称的远端分支并不存在，故会新建一个名为new_branch的远端分支，然后将本地代码推送到该远端分支。此时在B的github主页上(即远端)可在Branch下看到有两个分支，一个名为master，一个名为new_branch。

此时，所有的代码修改都是在B的本地和远端的new_branch分支下保存的，可将此修改提交到原仓库(A的master分支上)去。可在github主页上点击Compare & pull request命令，此时会弹出一个Comparing changes的页面，可对B：new_branch和A：master两个分支下的代码内容进行比较并创建pull request。如下图：

注意：在上图中，可以对被merge的仓库和分支进行选择，比如这里，如果B仅仅想把new_branch分支融合到B自己fork了的项目的master分支上，而非A的项目分支上去，就可以在上图左边点击下拉图标进行选择。

说明：为什么需要新建一个其他分支来开发？

——其实在这里有两种选择：1）在本地new_branch分支上写好代码后，先在本地merge到master分支上，再将本地master分支push到远端master上去；2）在本地new_branch分支上写好代码后，先push到远端成为一个新的远端new_branch分支，然后提起pull request，然后其他人可对其进行审查，觉得可以的话，再同意将远端的B：new_branch分支merge到远端的A：master分支。

即便是A自己向自己的项目master分支提交代码也应遵循这一工作流程，即先在本地创建new_branch分支，然后push到远端成为一个远端的new_branch分支，然后提起pull request，在其他人审查合格后再将自己的远端new_branch分支merge到自己的远端master分支。

在B创建了pull request之后，A(owner)会收到相关提醒，提醒B作出了某某提交。当然，如果B本身也是项目的合作者的话，那么他自己就能决定是否merge该pull request，而不必经过A的允许。

评注：无论你是否被列为项目的collaborator，你都可以以contributor的方式来贡献代码。当你是collaborator身份的时候，你既可以fork原项目也可以选择不fork。事实上， 把项目fork到你自己的账户在某种意义上仅仅是用于展示你工作的最新状态。只利用分支特性就可以发起pull request从而便于代码审查、防止冲突，故不必非得从fork后的项目发起。

 

备注：

fork：使整个git文档库分出另外一个，所谓的“分叉”，比如将A的仓库fork到B称为B账号下的一个仓库（原仓库下所有的分支都被fork）

branch：使程序项目分出另外一个，所谓的“分支”，比如从master分支分出一个develop分支

clone：不记录它是从哪个git文档库复制出的（而fork复制出的文档库会保留它的来源文档库）