本文为大地瓜原创，欢迎知识共享，转载请注明出处。
虽然你不注明出处我也没什么精力和你计较。
作者微信号：christgreenlaw

Overall

GitHub是大家经常使用的托管工具，关于Gitflow你又有多少了解呢。你的gitflow是否杂乱无章呢。
大地瓜为大家带来的是GitHub官网的gitflow教程。

以下内容按照GitHub官网的gitflow教程一一由大地瓜人工翻译。
有读着别扭的地方可以去原网址看。如果你有更好的翻译也可以评论反馈哦。

GitHub Flow是一个轻量级、基于分支（branch）的工作流，它支持团队合作以及经常部署的工程。这个guide解释了GitHub Flow为什么以及如何工作。

创建一个分支（Create a branch）

当你搞工程时，在任何给定的时间你都会有一大堆不同的特性（feature）或者想法（idea）--其中的一些可以立刻开展，而其他的不能（马上做）。分支的存在就是帮助你管理工作流（workflow）。
当你在工程中创建一个分支时，你就创建了一个可以尝试新想法的环境。在分支上做的改变不影响到master分支，所以你可以随意实验、commit变更，同时很清楚你的分支直到和你合作的人review了以后才会被合并。

专业建议（ProTip）

分支是Git中的核心概念，整个GitHub Flow就是基于此。只有一条规矩：master分支上的东西永远是可部署的。
正因此，很重要的一点就是：当你搞新的feature或者做fix时，你的新分支一定是在master之外建立的。你的分支名称应该是描述性的（descriptive)（例如：refactor-authentication, user-content-cache-key, make-retina-avatars），这样别人就能明白这个分支是干嘛的。

添加提交（Add commits）

你的分支建立好后，就该开始做变更了。你添加、修改或删除一个文件，你就应该做一次commit，并将其添加到你的分支上。当你在feature分支上工作的时候，这个添加commit的过程就记录了你的进度。
commit也为你的工作创建了清晰的历史，其他人可以据此明白你做了什么，为什么如此做。每一个commit都有一个相关的commit message，也就是一条描述，解释了为什么要做这个变更。不仅如此，每个commit都被认为是一个独立的变更单元（unit of change）。当你发现了bug或者你决定向另一个方向开展时，这个习惯可以让你回滚变更。

专业建议（ProTip）

commit message是重要的，尤其是因为：Git跟踪你的变更，一旦变更被推送到服务器，Git也将其展示为commit记录。通过书写清晰地commit message，你将使其他人更容易跟上（follow along）且提供反馈（provide feedback）。

开一个PR（Open a Pull Request）

Pull Request（下文将用PR）开启了关于你的cimmit的讨论。因为他们和底层的Git repo紧紧相关，任何人都能准确地看到：如果他们接受了你的request后将会合并什么变更。
你可以在开发过程中的任何时间点开启一个PR：当你没有什么代码但是想分享一些截图或者思想时，当你困惑并且需要帮助或建议时，当你准备好让其他人review your work时。通过使用GitHub上你的PR message中的@mention系统，你可以向特定的人或团队寻求反馈，不论他们就在隔壁还是十个时区之外。

专业建议（ProTip）

PR对于向开源项目贡献（contribute）以及管理共享repo上的变更来说是很有用的。如果你在用Fork & Pull Model，PR提供了一种方式，以将你的变更告知项目的维护者，让他们来考虑（是否采纳）。如果你使用Shared Repository Model， 在变更被merge到master 分支之前，PR可以帮助你开展code review以及关于提出的变更的对话。

讨论并审核代码（Discuss and review your code）

一旦开了一个PR，审核你的change的人或者团队也许会有问题或者评论。也许编码风格与项目指导不匹配、变更缺少了单元测试或者也许一切都不错。设计PR就是用来鼓励和捕获这类对话的。
在关于你的commit的讨论或者反馈的启发下，你也可以继续向你的分支push。如果有人评论到你忘了做什么事或者代码中有bug，你可以在你的分支中修复，然后推送变更。GitHub将会将你的新commit展示出来，你接收到的任何额外的反馈都在同一个的PR view中展示出来。

专业建议（ProTip）

PR评论是用Markdown写的，所以你可以嵌入图片或者emoji，使用预先格式化好的文本块，以及其他轻量的格式化。

部署（Deploy）

一旦你的PR审核好了，分支通过了测试，你就可以将变更部署以在产品中确认它们。如果你的分支引起了问题（issue），你可以通过将现存的master部署到产品中来进行回滚。

合并（Merge）

现在你的变更已经在产品中确认过了，是时候将你的代码合并到master分支了。
一旦合并后，PR会在代码的历史变更中生成一个记录。因为它们是可被搜索的，它们可以让任何人及时的回过头去理解这个决定是为什么做的，如何做的。

专业建议（ProTip）

通过在PR的文本中嵌入特定的关键字，你可以将issue和代码关联起来。当你的PR被合并时，相关的issure也就关闭了。例如，输入Closes #32就会关闭repo中的32号issue。更多的信息请参阅我们的help article。