要注意， 没有进行过测试或者测试未通过的代码绝不可以合并到 master 分支。

●

使用 Pull Request

Pull Request 不一定非要在与 master 分支合并时才使用。既然是团

队开发，完全可以尽早创建 Pull Request 让其他开发者进行审查，一边 听取反馈一边编写代码，没必要等到与 master 分支合并时再进行。

Pull Request 具有显示差别以及对单行代码插入评论的功能，开发者

可以利用这些进行交流。 另外， 如果希望得到特定开发者的反馈或建 议，可以在评论中加入“@ 用户名”，给该用户发送 Notifications。对方 注意到之后，照例都会以某种形式进行反馈。

习惯了在 Pull Request 上进行交流后，我们将能更精确地表达出代 码的意图，审查的效率也会越来越快。熟练运用 Pull Request 是这一开 发流程成功的关键。

希望各位能将这一开发流程应用到自己的开发现场，以便更加灵活 地使用 GitHub。

master 分支与 develop 分支的区别

下面我们先给各位讲一讲 master 分支与 develop 分支的相关内容。 在 Git Flow 中这两个分支至关重要，它们会贯彻整个流程始终，绝对不 会被删除。

master 分支

master 分支时常保持着软件可以正常运行的状态。由于要维持这一 状态，所以不允许开发者直接对 master 分支的代码进行修改和提交。

其他分支的开发工作进展到可以发布的程度后，将会与 master 分支 进行合并，而且这一合并只在发布成品时进行。发布时会附加包含版本 编号的 Git 标签（Tag）。这部分的详细内容我们将在后面进行讲解。

develop 分支

develop 分支是开发过程中的代码中心分支。 与 master 分支一样， 这个分支也不允许开发者直接进行修改和提交。

程序员要以 develop 分支为起点新建 feature 分支，在 feature 分支中 进行新功能的开发或者代码的修正。也就是说，develop 分支维持着开 发过程中的最新源代码，以便程序员创建 feature 分支进行自己的工作。

●

在 feature 中进行的工作

feature 分支以 develop 分支为起点，是开发者直接更改代码发送提 交的分支。开发以下述流程进行。

❶

从 develop 分支创建 feature 分支

❷ 在 feature 分支中实现目标功能

❸ 通过 GitHub 向 develop 分支发送 Pull Request

❹ 接受其他开发者审查后，将 Pull Request 合并至 develop 分支

与 develop 分支合并后， 已经完成工作的 feature 分支就失去了作

用，可以在适当的时候删除。

为方便进行具体讲解，现在假设我们要给软件实现一个添加用户的 功能。