理解 Github Flow

GitHub Flow 是一个非常轻便的，基于分支的工作流。非常适合代码部署非常频繁的团队和项目。这里这篇指南中咱们一起看看 Github Flow 好用在哪，如何来用。

创建一个分支

当你在开发一个项目的时候，一般在同一时刻你会同时开展多个想法，其中一些比较成熟了，另一些还是很初级。有了分支就可以很好的来进行管理了。

当你在项目中创建一个分支的时候，你正在搭建一个可以尝试新想法的环境。你在新分支上所做的修改不会影响到主（master） 分支，所以你能自由实验和提交修改。在被你的同事审核之前，你的分支是不会被合并的，所以一切都是安全的。

深度技巧

分支是 Git 的一个核心概念，整个 GitHub Flow 也是基于它的。最重要的规则只有一个：主（master）分支上的任何内容都要保证是可部署的。

正因为如此，当开发一个新功能或者修复错误的时候，你的新分支独立于主分支是极其重要的。你的分支名应该见名知义（ 例如，refactor-authentication，user-content-cache-key，make-retina-avatars）， 以便让其他人知道你正在做什么工作。

添加新版本

一旦你的分支创建好之后，就可以开始做些修改了。不论何时你添加，编辑或者删除一个文件，你就做一个版本，然后把它们添加到你的分支中。 添加版本的过程就跟踪了你在一个功能分支上的工作进展。

版本也为你的工作创建了一个透明的历史，其他人可以跟随着去理解你所做的工作以及为什么要这样做。每一个版本都有一条相关联的版本信息， 版本信息是一段描述，解释了为什么要做这样一个特定的修改。此外，每一个版本都可以看作是一个独立的修改单元。这样如果你不小心改错了，或者是改变了开发思路的时候，就可以来回滚修改了。

深度技巧

版本信息很重要，因为一旦你的修改被推送到服务器上，它们会以一个一个版本的形式显示。 通过书写清楚的版本信息，你可以更容易让其他人跟上你的思路并提供反馈。

开启一个 Pull Request

Pull Request 用来发起对你做的各个版本的讨论。因为 Pull Request 与底层的 Git 仓库代码是紧密相关的，任何人都能确切地看到一旦他接受了你的 Pull Request 会有那些代码合并进来

在开发过程中的任意时点，你都可以开启一个 Pull Request：当你有很少或没有代码，但想要分享一些截图或基本想法的时候， 当你陷入困境需要帮助和建议的时候，或者当你准备好让他人审核你工作的时候。通过在你的 Pull Request 信息中使用 GitHub 的 @mention 系统，你可以向特定的人或团队请求反馈，不管他们就在大厅的那边，还是离你有十个时区之遥。

深度技巧

Pull Requests 对贡献开源项目和管理共享仓库的变动是非常有用的。若你正使用 Fork & Pull 模式，Pull Resquest 提供了一种方式来通知项目维护者你希望他们考虑一下你提交的修改。若你正使用一个共享仓库模式，在提议修改被合并到主分支中之前，Pull Resquest 可以启动对修改代码的审核和讨论

讨论和代码审核

一旦开启了一个 Pull Request，审核你修改的人或团队会来提出问题和评论。有可能是代码风格符不符合项目规范， 也或者代码忘了单元测试，也可能各方面都没问题。Pull Request 就是为了鼓励这种类型的讨论而设计的。

根据对你所做版本的讨论和反馈，你也可以继续往你的分支上推送代码。若有人评论说你忘记做某件事或你的代码中存在 bug，你可以在你的分支中修复它，并提交这些修改。Github 将会在同一个 Pull Request 中展示你的新修改和任何新的反馈。

深度技巧

Pull Request 中评论是用 Markdown 格式书写的，所以你可以在评论中嵌入图片和 emoji 表情符号，使用带有格式的文本块，和其它轻量级格式。

合并分支，然后部署

一旦大家审核了你的 Pull Request 并且所有代码通过了测试，就是可以把你的代码合并到主分支了。 在把代码合并到 GitHub 上的仓库之前，如果你想测试代码，你可以先在本地执行合并操作。在你没有仓库的推送权限的情况下，这也是很方便的。

一旦合并之后，Pull Request 会保留代码的历史修改记录。因为它们是可搜索的，它们让人可以回到过去，去理解为什么做这个决定以及怎样做的决定。

深度技巧

通过在你的 Pull Request 中包含某些特定关键词，你就能用代码关联 issues。在你的 Pull Request 被合并的时候，与其相关的 issues 也会关闭。 例如，输入这个短语 Closes #32 将会关闭仓库中编号为32的 issue。更多信息，查看我们的 帮助文档。