Understanding the GitHub flow
原文链接 -> 传送门
GitHub 流是一个轻量级的、基于分支的工作流，它使得团队和项目的部署更有条不紊。
这一篇指导将解释 GitHub 流是如何工作的。
创建一个分支
你在开发某个项目的过程中，难免时不时会出现一连串新的想法——有些可以当时解决，有些则不能。分支的存在可以帮助你很好地控制这些工作流。
当你为你的项目创建一个分支时，你实际上创建的是一个允许你尝试新想法的环境。你在分支上做出的更改并不会影响到主分支，所以你可以自由地进行实验和提交更改，通过小伙伴们的代码审查之后，你就可以将其安全地合并到主分支上。
专业建议
分支是 Git 的核心概念，整个 GitHub 流也是在基于分支的基础上建立的。记住只有一条规则：主分支上的任何东西总是可以被展开的。
因此，当你开发一个新功能或修复 bug 的时候，强烈建议你为此创建一个新分支。分支的名字应该是具有描述性的（比如 refactor-authentication, user-content-cache-key, make-retina-avatars），这样别人就可以很容易看出其工作内容。
添加提交
一旦你的分支创建完毕，就可以开始做一些更改了。每当你进行添加、编辑或删除一个文件时，都会提交并添加到你的分支里。当你在开发新功能的分支上工作时，添加提交的过程会跟踪你的工作进度。
提交同时还为你的工作创建了一个清晰的流程，这样别人就可以很容易理解你到底做了什么以及为何要这么做。每个提交都有相关联的提交信息，通常是用于描述“为什么进行这样的更改”。另外，每次提交都代表一次变化，这样你可以在发现bug或决定往其它方向开发时，回到之前变化的地方重新开始。
专业建议
提交信息很重要，尤其是在 Git 跟踪了你的更改，并将他们提交到服务器并显示在小伙伴们的客户端时……如果有了明确的提交消息，就可以使得他们更容易理解你的想法并提供反馈。
发起 Pull Request
Pull Requests 将发起对你的提交的讨论，因为它们将与底层的 Git 仓库紧密集成，如果接受了你的请求，任何人都可以看到具体合并的是哪些更改。
在开发过程的任何时刻，你都可以发起 Pull Request：当你仅更改了少量代码（甚至都代码都没动过），但想要分享一些快照和思路的时候；当你的思路卡住了，需要一些帮助和建议的时候；或者当你准备让其他小伙伴来帮你审查代码的时候。在你的 Pull Request 信息中，使用 GitHub 的 @ 提醒系统可以从指定的人或团队那里获得反馈。
专业建议
Pull Requests 不仅有助于开源项目的开发，也使得共享仓库的改动管理更加轻松。如果你使用分支推送模式（Fork & Pull Model），通过 Pull Requests，你可以将自己的更改建议通知给项目维护者；如果你使用共享仓库模式（Shared Repository Model），在改动被纳入主分支之前，Pull Requests 也方便了彼此之间的代码审查和改动内容的交流。
讨论和审查你的代码
当你提交一个 Pull Request，审查的人员或团队可能对你的更改有所疑问或意见……有可能是代码风格不符合项目规范，或者提交的更改缺乏单元测试，也可能所有内容都符合项目的要求。Pull Requests 就是被设计用于鼓励和记录这类型的交流。
你还可以根据有关你的提交的讨论和反馈，继续推送到你的分支。如果有人评论你忘记做某事或代码中存在 bug，你可以在你的分支中修复它并推送更改。GitHub 将在 Pull Request 视图中统一显示你的提交以及任何追加的反馈。
专业建议
Pull Request 评论是使用 Markdown 来写的，所以你可以嵌入图片和 emoji 表情，使用预格式化的文本块和其它轻量级的格式。
部署
如果你的 pull request 经过审查，并且对应分支通过了测试，这时你就可以在产品中部署你的改动并且验证。如果此分支造成了某些问题，你仍然可以退回到之前的产品进度。
合并
现在，你的更改已在生产中得到验证，现在是将代码合并到主分支的时候了。
一旦进行了合并，Pull Requests 会为你的代码的历史更改保留一份记录。因为它们必须是可搜索的，这样任何人都可以回到过去，了解为什么以及如何会做出这样的决定。
专业建议
通过将一些关键字加入到你的 Pull Request 的文本中，你可以将 issues（问题单）和代码关联起来。当你的 Pull Request 被合并的时候，相关的 issues 也将被关闭。例如，输入 Closes #32 这个短语，表示关闭仓库中第 32 号 issue。更多信息，请查看我们的帮助文档。