“不积跬步无以至千里。”
说明
本文主要内容翻译自 github 官网。
关于 github 入门，欢迎参考我的译文 Github 10 分钟入门。
有些词还是用的英语，个人学识浅薄，无法用中文表达出该有的味道。
欢迎阅读，不足之处，还请指正，谢谢！
前言
GitHub Flow 是一种支持团队和项目定期部署 ( made regularly ) 的基于分支的轻量级工作流程 ( workflow ) 。
这篇指南解释了 GitHub Flow 是怎么样工作以及这样工作的原因。
创建分支
你在做一个项目过程中，将会有许多不同的功能特性和想法，一些已经准备好了，还有一些没有准备好。那么分支的存在就是去帮助你管理这些 workflow 。
当你在项目中创建一个分支的时候，也就意味着你创造了一个可以尝试新想法的环境。你在分支中所做的更改不会影响主分支 ( master ) ，所以你可以自由的尝试和提交更改。你可以安全的知道你的分支不会被合并，直到准备好由你的合作者复审。
提示
分支是 Git 中的核心概念，并且整个 GitHub Flow 都是基于分支的。只有一条规则：主分支 master 的任何内容都是可部署的 ( deployable ) 。
因此，在处理特性和做修复时，你的新分支是分离于主分支 master 创建的是极其重要的。 你创建的分支名字应该是描述性的 ( 例如，refactor-authentication, user-content-cache-key, make-retina-avatars ) ，以便让其他人明白正在做的工作。
添加提交
分支创建好了，就可以开始做改动了。
无论何时添加、编辑或者删除一个文件，你都可以提交，并且添加到你的分支。
添加提交显示了 ( keep track of ) 你为一个功能分支工作的过程。基于此，如果发现 bug 或者决定转到一个不同的方向时，你就可以回滚 ( roll back ) 更改。
提示
提交信息 ( commit message ) 十分重要，因为一旦提交信息推送到服务器，那么 Git 就会监测 ( track ) 到你所做的更改并且显示为提交。
清晰的提交信息可以方便他人遵循和提供反馈。
发起请求
发起请求 ( Pull Request ) 就是开始讨论你的提交。因为它们紧密的集成在 Git 的底层 ( underlying ) 仓库，任何人，只要同意接受你的更改，都可以确切的看到将要合并的改动。
在开发过程中，你可以在任何时候发起请求：
- 即使没有代码，仅仅是想分享一些截图或者想法时；
- 当你不知所措 ( stuck ) 需要帮助或建议时；
- 当你准备好让他人检验你的工作时。
在你的获取请求中，通过使用 GitHub 的 mention system ，你可以向特定的人或者团队请求回馈 ( feedback ) ，不管他们是在楼下还是 10 个时区之外。
提示
发起请求 ( pull request) 对于向开源项目贡献和管理共享仓库的更改都很有用。
如果你使用的是 Fork & Pull 模式，发起请求提供的是通知项目维护者 ( maintain ) 关于你希望他们可以考虑的更改的一种方式 (比较拗口) 。
如果你使用的是共享仓库 ( Shared Reposity ) 模式，在将更改合并到主分支之前，发起请求有助于开始代码审查和提交修改的对话。
讨论和审查代码
一旦开启了 pull request ，审查你所做更改的人或者团队可能会有一些问题或者看法。可能是代码风格不符合项目指南，修改缺少 ( missing ) 单元测试，又或者可能是一切看起来都很不错而且有序。Pull Request 用于鼓励和获取这种类似的对话。
你有可以根据 ( in light of ) 讨论和反馈继续推送你的分支。如果有人提醒你忘记了去做某些事或者程序中有 bug ，你可以在你的分支中修复，然后推送更改。
GitHub 会将你的新提交和可能收到的任何反馈展示在统一的 Pull Request 界面。
提示
Pull Request 评论是用 markdown 语法写作的，所以你可以嵌入图片和表情符号，使用预先格式化的文本块和其他轻量级的格式。
部署
一旦你的 pull request 通过了代码审查和你的测试，你就可以在产品里部署 ( deploy ) 你的更改来验证它们。
如果你的分支出现了问题，你可以通过部署已经存在的主分支来回滚程序。
合并
既然你的修改已经在产品中验证过了，是时候将你的代码合并到主分支了。
一旦合并， pull request 会在你的代码中保留一份历史修改的记录。因为记录是可搜索的，它们可以让任何人返回去看时，及时理解为什么这样决定以及这个决定是怎样做的。
提示
在你的 pull request 中加入确定的关键字，你可以将代码和问题 ( issues ) 联系在一起。当你的 pull request 合并之后，相关的 issue 也就关闭了。举个例子，输入 Closes #32 会关闭仓库中的 32# 问题。
结束语
祝贺你，完成了这篇指南教程。
GitHub Flow 基本就是这样，更精确的指导请关注 GitHub 官网。
愿你我都是有态度的人，相识于有温度的文字中。
最后，感谢阅读。
