GitHub flow

参考文献：GitHub flow

如果你的项目需要回滚大版本，需要支持多个版本同时运行
可以使用更完备的 A successful Git branching model

---

创建一个分支

当你在做一个项目的时候，在任何时候，你都会拥有一个当前正在开发的分支
这个分支可以拥有新的特性或想法 —— 一些这样的分支正在开发中，一些还尚未开始进行
Git 的分支会帮助你完成这样的工作流

当你在你的项目中创建了一个分支，你就创建了一个你可以尝试新想法的环境
你在一个分支上进行的修改不会影响到主分支 main，因此你可以随意地实验与提交修改
只有当你的分支已经做好了被合作者审查的准备时，才应该对变更进行 push（提交 Pull Request）
只有当分支被验证无误之后（如在生产环境进行测试通过），才能最终合并进 main 分支

分支是 Git 的一个核心概念，整个 GitHub flow 都基于分支
一个核心原则是：任何 main 分支上的内容都是可正式部署的

正因为如此，在创建新分支时，无论是为了添加新特性还是为了修复问题，都必须从 main 分支分出
分支名称必须是描述性的，能够描述分支的用途（如：refactor-authentication, user-content-cache-key, make-retina-avatars）
这样别人就能知道哪些工作正在进行中

添加 commit

每当添加、修改或删除了文件之后，需要通过 commit（提交）将这些变化加入到你的分支
你在分支上添加 commit 的过程会被记录下来，今后可以进行追踪

commit 为你的工作创建了一个透明的历史记录，其他人可以通过这个记录理解你做了什么以及为什么要这么做
每个 commit 都有一个关联的提交消息，用来描述为什么要做这个变更
而且，每个 commit 也是一个变更单元，当发现 Bug 或思路改变时，可以基于这个变更单元进行回滚

提交消息非常重要，特别是当把 commit push 到服务器时，Git 会用提交信息来展示每一个 commit
清晰明了的提交消息，可以让其他人更容易地了解你的工作过程与提出反馈

开启一个 Pull Request

开启一个 Pull Request 相当于发起一个关于你的 commit 的讨论
因为它们是与底层的 Git 仓库紧密地集成在一起的
所以任何人都可以看到，如果他们接受你的请求，有什么变动会被 merge（合并）进来

你可以在开发过程中的任何时候开启一个 Pull Request：
当你有一点（或没有）代码，想要分享一些截图或总体思路的时候、当你卡住了需要帮助或建议的时候、或者当你准备好让某人审查你的工作的时候
通过 GitHub 的 @mention 系统，你可以在 Pull Request 消息中向特定的人或团队请求反馈

Pull Request 在向开源项目做贡献时，以及需要管理共享仓库变更时特别有用
如果你使用的是 Fork & Pull 模型，Pull Request 提供了一种方式来通知项目维护者你希望他们考虑的变更
如果你使用的是共享仓库模型，Pull Request 有助于在将新的变更合并进 main 分支前，对提议的变更进行代码审查与讨论

代码审查

当一个 Pull Request 开启后，对变更进行审查的人或团队，可能会有疑问或提出评论
也许是代码风格不符合项目规范、变更没有单元测试，或者一切都没有问题
Pull Request 被设计用来鼓励与捕获这类会话
你可以根据对你的 commit 的讨论结果与反馈修改代码
例如有评论指出你忘记了做某个事情或者代码有 Bug，你可以在你的分支上修复问题后再 push（推送）变更
GitHub 会以统一的 Pull Request 视图，展示最新的 commit，以及你可能会收到的任何新增的反馈

Pull Request 评论是以 Markdown 书写的，因此你可以插入图片和表情、使用格式化的文本块以及其它轻量级的格式

部署

使用 GitHub，你可以在将代码合并进 main 分支前，使用某个分支进行部署到生产环境做最终的测试

当你的 Pull Request 审查完毕，并且分支通过了你自己的本地测试，你就可以将变更部署到生产环境验证它们的有效性
如果你的分支引起了问题，你可以立即回滚，将现有的 main 分支部署到生产环境

不同的团队可能会由不同的部署策略
对于有些团队来说，最好先部署到一个预设的测试环境
而对于另一些团队来说，根据工作流的其它因素，直接部署到生产环境可能才是更好的选择

合并

现在，你的变更已经在生产环境得到了验证，可以将你的代码 merge（合并）到 main 分支了

当合并之后，Pull Request 会保留一个代码历史变更的记录
这些记录是可以搜索的，这让任何人都可以弄清楚历史上每个决定的通过原因与决策过程

通过在 Pull Request 的文本中包含某些关键字，可以将 issue（问题）与代码关联起来
当 Pull Request 被合并之后，相关的 issue 会被关闭
例如键入短语 Closes #32 可以关闭仓库中的 32 号 issue
想要获得更多信息，请查看 help article

---

参考文献：GitHub flow

如果你的项目需要回滚大版本，需要支持多个版本同时运行
可以使用更完备的 A successful Git branching model