多人协作

一 创建多人协作

如果需要多人协同开发，一般有两种方式：

• 1、添加合作者一起来管理仓库：将其他用户添加到仓库合作者中之后，该用户就具有向当前仓库提交代码。

  github上给自己的项目添加Collaborators 现在改为manage access

对方已经登录github账号，然后访问自己的邮箱就会有提示邮件

• 2、创建一个组织，然后再该组织下可以创建多个项目/仓库，组内成员可以向组内所有项目提交代码。PS：也可以对某个项目指定合作者

​ 其余直接提交即可，可以创建很多仓库

二 多人协作开发步骤

协同开发命令和以上步骤类似，此处就不再重新写代码，描述三人协同开发整个过程即可。

• 创建程序

• • 用户A创建程序，提交到GitHub
  • 用户B克隆项目
  • 用户C克隆项目

• 开发功能

• • 用户A开发功能1
  • 用户B开发功能2
  • 用户C开发功能3

• 提交

• • 用户A提交功能1，并push（A用户手速快，先提交。）
  • 用户B提交功能2，无法push，因为GitHub上已经有其他人提交的新代码。
    解决方法：从GitHub上获取最新代码并合并到本地，提交自己开发的功能2。
  • 用户C提交功能3，无法push，无法提交，因为GitHub上已经有其他人提交的新代码。
    解决方法：从GitHub上获取最新代码并合并到本地，提交自己开发的功能3，此时GitHub上远程库为最新。

• 获取最新代码

  • 用户A获取最新代码
  • 用户B获取最新代码
  • 用户C获取最新代码

上述解决方法可以有下述三种方式操作，都可以完成合并并提交新功能，但是日志记录会有差异，如：下述方式的前两种方式的版本记录中会出现合并，而第三种方式可以保证版本记录干净整洁。

• 方式1：先 git pull origin master 然后 git push origin master

• 方式2：先 git fetch origin master 然后 git merge origin/master 再 git push origin master

  用户A：
    touch 4.py
    git add .
    git commit -m '功能4'
    git push origin master
  
  用户B：
    touch 5.py
    git add .
    git commit -m '功能5'
  
    git push origin master # 报错，因为GitHub中已经有人提交新代码
  
    git pull origin master
  
    git push origin master

  

• 方式3：先 git fetch origin master 然后 git rebase origin/master 再 git push origin master

  用户A：
    touch 4.py
    git add .
    git commit -m '功能4'
    git push origin master
  
  用户B：
    touch 5.py
    git add .
    git commit -m '功能5'
  
    git push origin master # 报错，因为GitHub中已经有人提交新代码
  
    git fetch origin master
  
    git rebase origin/master
  
    git push origin master  

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

小结

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

三 Git flow

Git 作为一个源码管理系统，不可避免涉及到多人协作。

协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。

它最主要的特点有两个。

首先，项目存在两个长期分支。

• 主分支master
• 开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支。

• 功能分支（feature branch）
• 补丁分支（hotfix branch）
• 预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

Git flow 的详细介绍，请阅读阮一峰翻译的中文版《Git 分支管理策略》。

评价：

Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将`master`当作默认分支，可是开发是在`develop`分支进行的，这导致经常要切换分支，非常烦人。

更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，`master`分支和`develop`分支的差别不大，没必要维护两个长期分支。

推荐阅读：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

四 代码review

可以在远程仓库里提交合并请求，也可以在本地合并完毕后再提交到远程，下述演示的是在远程仓库里发起合并请求，然后合并

项目settings=》Branches=》add Rule=》指定Branch name pattern=》选择Require pull request reviews brefore merging

一个普通用户在本地把代码push到了远程仓库的feture1分支=》该用户登录上网页github=》新建Pull Requests

项目负责人登录上github会看到一个Pull requests然后review审核代码=》合并即可=》如果想保持代码的整洁性，可以删除分支，只留一个master分支

代码经过code review合并到了dev分支后，需要在dev分支拆出一个release分支，然后进入测试环节

测试的环节通常不允许轻易添加新功能，可能会有bug，但肯定比较少，测试完毕后与主分支合并有两种方式

• 方式一：在本地merge完毕，然后push到远程
• 方式二：基于网页的Pull Requests

ps：对于代码code review则不能用哦方式一，只能用方式二