【Chapter 9】使用 Github 的开发流程（以部署为中心）
本章中讲解的“开发流程”，是指使用了Git与 GitHub的团队开发所涉及的规则及步骤。接下来的部分我们将会讲解 2 种开发流程，每个流程都有各自不同的特征。在实际开发中究竟要采用哪一种，需要根据现场团队的情况来决定
9.1 团队使用 GitHub 时的注意事项
由软件开发者们组成的团队要想最大限度地发挥出他们的能力需要具备以下的前提条件。
-
一切从简
实际开发过程中，往往并用不到哪些复杂度极高的功能。
-
不 Fork 仓库的方法
一般 Pull Request 的开发流程如下：
- 在 GitHub 上进行 Fork
- 将 Fork 的仓库 clone 至本地开发环境
- 在本地环境中创建特性分支
- 对特性分支进行代码修改并进行提交
- 将特性分支 push 到相应的远程仓库中
- 在 GitHub 上对 Fork 来源仓库发送 Pull Request
在无法给不特定的多数人赋予提交权限的公开软件开发中，这种流程能够防止仓库收到计划之外的提交。
然而在企业开发中，开发者每天都需要见面，要经常互相发送 Pull Request，这种流程就显得有些繁琐了。因此，下面我们要介绍一个不需要Fork仓库的工作流程。
进行 Fork 的开发流程
不进行 Fork 的开发流程这种方法可以让每一名开发者都掌握着 一个本地仓库和一个远程仓库，使整个开发流程变得简单。
9.2 GitHub Flow——以部署为中心的开发模式
下面是 GitHub 公司正在实践的一个十分简单的开发流程。
这是一个以部署（即在正是环境中配置源代码并试运行）为中心的开发流程。在实际开发中往往 1 天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。简单的开发流程能够让问题应对变得更加灵活。正在使用 GitHub 的各位，请务必尝试这一开发流程。（可以适用 20 人左右的团队）
9.3 GitHub Flow 的流程
整个流程大致如下：
❶ 令 master 分支时常保持可以部署的状态
❷ 进行新的作业时要从master分支创建新分支，新分支名称要具有描述性
❸ 在❷新建的本地仓库分支中进行提交
❹ 在 GitHub 端仓库创建同名分支，定期 push
❺ 需要帮助或反馈时创建 Pull Request，以Pull Request进行交流
❻ 让其他开发者进行审查，确认作业完成后与 master 分支合并
❼ 与 master 分支合并后立刻部署
下面我们按顺序进行一步步讲解。
1. 随时部署，没有发布的概念
特点：每隔几小时（甚至分钟）进行一次部署，令 master 分支随时保持可以部署的状态。
优点：1. 每隔几小时进行一次部署，可以有效防止同时出现多个严重 BUG。
虽然有时仍会有一些小BUG出现，但只要将相应的提交 revert 或者提交修正过的代码即可轻松应对。
2. 这一流程要以小时甚至分钟为单位 持续地进行部署，所以不存在发布的概念。
因此，不会出现让 HEAD 返 回去指向很久之前的提交 ，借以取消整个作业内容的情况。
3. 由于 master分支时常保持着可以部署的状态，所以开发者可以随时创建新的分支。
注意：没有进行过测试或者测试未通过的代码绝不可以合并到 master 分支。因此势必要用到持续集成等手段。
2. 进行新的作业时要从 master 分支创建新分支
进行新的作业时要从 master 分支创建新分支，无论是添加新功能还 是修复 BUG 都是如此。此外，新分支的名称要具有描述性。
所谓具有描述性的名称，是指该名称能直观正确地表达这个分支的特性，比如以下几种。
- user-content-cache-key
- submodules-init-task
- redis2-transition
采用这一方式，开发者在查看远程仓库的分支列表时，能够对当前团队正在实施的任务一目了然。另外，由于分支名明确描述了工作内容，即便开发者需要先去做其他工作，回来时也能很快想起该分支的工作目标。
3. 在新创建的分支中进行提交
在前面的步骤中，开发者为了进行新的更改而创建了新分支，并且明确了在这个分支中应该做哪些工作。接下来就可以在这个分支中修改 代码，并进行提交了。修改代码时要注意，绝对不能进行与该分支工作内容无关的修改。
在这一阶段，开发者要在提交的粒度上多花心思。
- 有意识地减小提交的规模，
- 便于清楚地表达目的，
- 有助于其他开发者对 Pull Request 进行审查
比如在添加一个方法时，确认添加位置以及类之后，开发者往往还需要进行下面的操作。
- 修正附近代码的缩进问题
- 发现变量单词拼写错误并进行修正
- 添加本次作业中需要添加的方法
如果将上述工作在一次提交中完成，那么一个差别将包含 3 种含 义，这种提交的粒度就有些不妥。如果将3 个工作分为 3 次提交，那么每个差别就有了更清晰的含义。
4. 定期 push
在这一开发流程中，由于除了 master 分支之外都是作业中的分支， 所以 push 作业分支时不需要有太多顾虑。在开发过程中，建议开发者定期将本地仓库中创建的分支以同名形式 push 到 GitHub 端的远程仓库。
这样做的好处：
- 在备份代码同时，还会定期给开发者团队创造交流的机会。
- 可以通过 GitHub 的分支列表页面清楚的知道其他开发者的状态，必要时给予帮助。
- 可以利用代码进行交流，让其他开发者看到自己编写的代码，同时养成积极查看其他人代码的习惯。
5. 使用 Pull Request
Pull Request 不一定非要在与 master 分支合并时才使用。既然是团 队开发，完全可以尽早创建Pull Request让其他开发者进行审查，一边听取反馈一边编写代码，没必要等到与 master 分支合并时再进行。
Pull Request 具有显示差别以及对单行代码插入评论的功能，开发者 可以利用这些进行交流。另外，如果希望得到特定开发者的反馈或建 议，可以在评论中加入“@ 用户名”，给该用户发送 Notifications。对方 注意到之后，照例都会以某种形式进行反馈。
6. 务必让其他开发者进行审查
一个分支的作业结束后，需要注明作业已完成，让其他开发者进行 审查。找其他开发者看一看自己编写的代码，可以有效防止想当然的错 误或者低级失误。
审查之后如果认为可以与 master 分支合并，则需要明确地告知对方。征得多个人同意后，便可找个适当的时机让其他开发者将该分支与 master 分支进行合并。
7. 合并后立刻部署
代码合并至 master分支并且通过所有自动测试之后，需要立刻进行 部署。在部署之后，需要确认刚刚合并的代码是否存在问题。
9.4 实践 GitHub Flow 的前提条件
1. 部署作业完全自动化
使用部署工具，简化部署操作，提高效率。
2. 重视测试
● 让测试自动化
如果每次部署到正式环境前都需要在测试环境中手动进行测试，那这一开发流程也就无从谈起了。所以必须让测试自动化，令其自动检测 是否有代码被意外破坏，以及是否出现 BUG。
● 编写测试代码，通过全部测试
每一名开发者都必须编写测试代码，开发者确认代码在本地环境中通过了所有测试后，将其 push 到远 程仓库。
● 维护测试代码
要注意的是，测试代码必须时常进行维护，以保证能够在开发流程 可承受的速度范围内完成所有测试。
很遗憾，这本书我就看到这里就到此为止了，其实我早都想结束了，毕竟没有那个场景需求，很多东西都看起来都很难有感觉，每天写起来也有点难受，接下来我将学习 Flask（清理之前买的书），抱歉（虽然基本 0 浏览量）。
