了解GitHub工作流
GitHub流是一个轻量级，基于分支的工作流，它使得小组和项目的部署变得标准化。这个向导解释了GitHub流是如何以及为什么工作的。
创建一个分支
当你工作在一个项目中，你可能会在任何时间产生不同的想法和特性计划–这些都是准备完成的，或者其他不准备完成的。分支的存在可以帮助你管理工作流。
当你在自己的项目中创建一个分支的时候，也就等于创建了一个尝试自己想法的环境。你在这个分支修改的东西不会影响到主分支，所以你可以尽情的测试和提交改变。这些改变直到你的合作伙伴审查过，确保安全才会被合并到主分支中。
分支是Git的一个核心概念，并且GitHub流完全基于这个概念。只有一个规则，那就是master分支必须是可部署的。
因此，当你在修复bug或者创建新功能时，你的新分支必须创建在master之外。你的分支名称应该是自描述的（如：refactor-authentication，user-content-cache-key，make-retina-avatars），所以其他人可以了解什么正在进行。
增加提交
一但你的分支创建完成，就可以进行修改了。不管你进行了增加、修改或者删除一个文件，你都可以进行提交代码，将他们增加到分支中去。这个过程可以保持跟踪你对一个特性分支工作的发展。
提交同样为你的项目创建了一个清晰的历史，这样别人就可以了解你做这些的原因以及内容。每一个提交有一个相关的描述，这个描述可以解释你具体做了什么修改。另外，每一个提交都应该是分开的修改单元。这个使得你可以在发现bug的时候回滚修改，或者你决定朝向不同的方向。
提交描述是非常重要的，尤其因为Git跟踪你的改变并且在他们被推送到服务器上的时候显示他们。通过写出清楚的提交描述，你可以使得别人容易遵从和提供反馈。
开启一个Pull Request
Pull Request最初开始于对你的提交的讨论。因为他们紧密集成在Git库下，如果你的请求被接受，所有人可以看到被合并的改变具体包含什么。
你可以开启一个Pull Request在开发过程工任何部分：当你有少量代码，或者你希望分享一些截图或平常的想法，或者当你被卡住希望获得帮助及建议，又或者当你准备好让别人来审查你的工作。通过在请求描述中使用GitHub的 @方式 ，你可以向某一个人或者团队要求反馈，不论他们不在线或者在别的时区。
Pull Request对于开元项目的管理和分享都非常有用。如果你使用一个Fork&Pull模型，Pull Request提供了一个方式来告知项目管理者他们希望关注的改变。如果你使用Shared repository Model，Pull Request有助于开始审查和讨论即将合并到master分支的改变。
讨论并审核你的代码
一但一个Pull Request被开启，负责审核代码改变的人们或团队可能会有一些问题或者评论。可能代码风格不符合项目指导，修改缺少单元测试，或者所有修改都做的非常好。Pull Request被设计来促进和不活这种类型的会话。
在对你提交进行讨论和反馈的过程中，你可以继续推送你的分支。如果有人评论你忘了做一些事情，或者有一些bug在你的代码中，你可以在自己分支中修复并且推送这些修改。GitHub将在统一的Pull Request视图中给你显示新的提交和其他额外的反馈。
Pull Request评论用Markdown写成，所以你可以嵌入图片和表情符号，使用pre-formatted的文字块，和高亮的格式。
合并和部署
一但你的Pull Request审核通过并且分支通过测试，这些代码就可以被合并到master分支以便部署。如果你需要在合并到GitHub库前进行测试，你可以在本地先进行合并。这些在你推送到库中前都是非常容易控制的。
一但被合并，Pull Request会对你的代码保存一个历史修改记录。因为它们是可搜索的，所以所有人都可以回顾到历史纪录去了解一个决定是为什么或者怎么完成的。
通过在Pull Request的文字中包含某些关键字，你可以关联代码和issues。当你的Pull Request被合并，相关的issues同样会被关闭。比如，输入Closes #32将会关闭库中的32号issue。想要获得更多信息，点这里。
注：本文译自[原文]；
评论