《GitHub入门与实践》学习笔记（windows）-第9章 使用github的开发流程
文章目录
一、团队使用 GitHub 时的注意事项
1.团队使用 GitHub 时的注意事项
（1） 一切从简
GitHub 的各项功能都非常简单，就是因为在实际的软件开发中，往往用不到那些复杂度极高的功能。
（2）项目管理工具与 GitHub 相异的原因
GitHub 的这些简单功能，完全能够应对软件开发中的需要。想让团队最大限度发挥实力，建议剔除复杂规则，只以最简单的规则进行开发。
（3）不 Fork 仓库的方法
说明：
（a）这种方法可以让每一名开发者都掌握着一个本地仓库和一个远程仓库，使整个开发流程变得简单。
（b）
二、GitHub Flow——以部署为中心的开发模式：不需要 Fork 仓库的工作流程
（1）以笔者的经验，由 20 人左右的团队使用这个流程来共同开发一个项目，基本不会出现什么大问题。
三、GitHub Flow 的流程
说明：
（1）随时部署，没有发布的概念
这个流程必须遵守“令 master 分支随时保持可以部署的状态”这一规则。每隔几小时进行一次部署，可以有效防止同时出现多个严重 BUG。
由于 master 分支时常保持着可以部署的状态，所以开发者可以随时创建新的分支。
要注意，没有进行过测试或者测试未通过的代码绝不可以合并到master 分支。因此势必要用到持续集成等手段。
（2）进行新的作业时要从 master 分支创建新分支
（3）在新创建的分支中进行提交
在前面的步骤中，开发者为了进行新的更改而创建了新分支，并且明确了在这个分支中应该做哪些工作。接下来就可以在这个分支中修改代码，并进行提交了。
如果将 3 个工作分为 3 次提交，那么每个差别就有了更清晰的含义。
（4）定期 push
在开发过程中，建议开发者定期将本地仓库中创建的分支以同名形式 push 到 GitHub 端的远程仓库。
团队成员可以通过GitHub 的分支列表页面一目了然。
（5）使用 Pull Request
（6）务必让其他开发者进行审查
（7）合并后立刻部署
代码合并至 master 分支并且通过所有自动测试之后，需要立刻进行部署。在部署之后，需要确认刚刚合并的代码是否存在问题。
四、实践 GitHub Flow 的前提条件
1.部署作业完全自动化
（1）使用部署工具
我们要使用 Capistrano 等部署工具，让部署时所需的一系列流程自动化。不小心部署了有问题的代码时，只需一条指令就可以将版本回滚至部署之前。为此，最好让所有参与开发的人都能进行回滚操作。
（2）通过 Web 界面进行部署的工具
一个团队除了开发者以外，往往还包含美工或 HTML 编辑等人，在开发过程中，创建一个让团队所有相关人员都能放心部署的环境至关重要。
下表列出了几种具有代表性的部署工具。
（3）导入开发时的注意事项
为了应对这种情况，建议在部署实施过程中通过工具上锁，或者在实施部署时通知整个团队等，通过严格贯彻这类规则来消除隐患。
2.重视测试
（1）测试自动化
必须让测试自动化，令其自动检测是否有代码被意外破坏，以及是否出现 BUG。
（2）编写测试代码，通过全部测试
每一名开发者都必须编写测试代码。成品代码的 Pull Request 中如果不包含测试代码，是不可以合并至 master 分支中的。
开发者确认代码在本地环境中通过了所有测试后，将其 push 到远程仓库。 随后 Jenkins 或 Travis CI 等 CI 工具会自动对其进行测试，测试结果由 CI 工具第一时间通知开发者。
（3）维护测试代码
要注意的是，测试代码必须时常进行维护，以保证能够在开发流程可承受的速度范围内完成所有测试。
eg：GitHub 公司可以在 200秒内实施 14 000 个自动测试 ：http://zachholman.com/posts/how-github-works/
不论是添加新功能还是修正小 BUG，全都通过同一流程进行。