在团队中使用Pull Request来管理代码

前言

在参加多人共同开发项目，且选用Git作为代码托管工具的时候，我们不免会遇到分支冲突、覆盖、合并等问题。显然，因为同一个仓库是属于大家的，所以每个人都有权限向仓库中push或者pull数据。但是这样难免会带来混乱，在人数较多的时候，更是容易出现问题。

目前，在很多团队项目中，都使用Pull Request（GitLab称为Merge Request）来进行Code Review。Pull Request是一种有效的管理源代码的方式，尤其是在许多人一起贡献源代码的时候，显得尤为重要。

Pull Request的优点：

• Auto Merge功能。哪怕两份代码并非在最新的master分支情况下进行修改，Pull Request也会智能识别，将多份来自于不同分支的代码进行合并。
• Code Review功能。开发者提交上去的代码可由管理者进行复审。复审过程中出现的任何问题，可以直接在commit中进行指出，也可以引用相关代码行来指出问题，交流方便。
• 与Issue的绑定功能。Pull Request可以与Issue进行绑定，相当于指定了完成某个Issue所修改的代码，在回顾时可以较为清晰的看到代码变化。

下面，将介绍Pull Request模式的工作流程。

提出需求

所有的任务、需求、Bug修复都以Issue的形式呈现。管理员、开发者、测试员等都可以创建Issue。

Github的创建Issue界面如图所示，左侧主要填写需求的具体内容，支持Markdown。

右侧可以将需求直接指派给某位开发者。如果不指派，开发者也可以选择认领任务。

右下角有Linked Pull Request，可以将与该Issue相关的Pull Request与此Issue构建联系，若Pull Request通过，则代表该Issue被完成。

开发者操作

在该工作模式下，master分支是受保护的——任何开发者都无权直接修改master分支，哪怕是管理员也不应当对master分支进行直接修改，否则会造成混乱。

那么，如果开发者想要修改master分支中的内容怎么办呢？

• 从master分支创建出去一个属于自己的分支，用作开发者自己进行调试的开发环境。

  开发分支的建议命名格式：操作者姓名--操作内容，如guojun--add-readme。千万不要命名为dev1，dev2这种毫无信息量的名字，否则修改记录将难以追溯！

  (master) git checkout -b guojun--add-readme
  

• 修改开发分支中的内容，本地测试，push到开发分支。

  (guojun--add-readme) git add --all
  (guojun--add-readme) git commit -m "add README.md"
  (guojun--add-readme) git push -u origin guojun--add-readme
  

• 最重要的一步，提交Pull Request到master分支。

你可以输入一些关于这个PR的说明，以供其他人进行Review。

PR上传之后，等着组内专门的Reviewers来进行Review吧。

对于不同的仓库，例如前端、后端等，Reviewers可以是测试人员，也可以是PM。

代码复审

我们切换到Reviewers界面。

此时，Reviewers若对代码不满，可以在对应的代码出标出，让开发人员继续修改。若没有问题，且出现图中绿色的画面（和基础分支不冲突），则可以进行Merge。

恭喜！这样代码就Merge完成了。一般情况下，需要删掉PR所创建的开发分支。

另外，如果Merge过程中出现冲突，如多个PR修改了同一份文件，GitHub还提供网页版编辑器供Reviewer去选择应该保留哪些、不保留哪些。

以上就是开发者进行源代码修改的整个过程。