说明：
个人在学习git工作流的过程中，从原有的 SVN 模式很难完全理解git的协作模式，直到有一天我看到了下面的文章，好多遗留在心中的困惑迎刃而解：
我们以使用SVN的工作流来使用git有什么不妥？
git 方便的branch在哪里，团队多人如何协作？冲突了怎么办？如何进行发布控制？
经典的master-发布、develop-主开发、hotfix-不过修复如何避免代码不经过验证上线？
如何在github上面与他人一起协作，star-fork-pull request是怎样的流程？
我个人很感激这篇文章，所以进行了整理，希望能帮到更多的人。整篇文章由 xirong 整理自 oldratlee 的github，方便统一的学习回顾，在此感谢下面两位的贡献。
原文链接：Git Workflows and Tutorials
简体中文：由 oldratlee 翻译在 github 上 git-workflows-and-tutorials
一、译序
二、Git工作流指南
2.5.1 解析Pull Request
2.5.2 工作方式
2.5.3 在功能分支工作流中使用Pull Request
2.5.4 在Gitflow工作流中使用Pull Request
2.5.5 在Forking工作流中使用Pull Request
2.5.6 示例
小红fork正式项目
小红克隆她的Bitbucket仓库
小红开发新功能
小红push功能到她的Bitbucket仓库中
小红发起Pull Request
小明review Pull Request
小红补加提交
小明接受Pull Request
2.4.1 工作方式
2.4.2 正式仓库
2.4.3 Forking工作流的分支使用方式
2.4.4 示例
项目维护者初始化正式仓库
开发者fork正式仓库
开发者克隆自己fork出来的仓库
开发者开发自己的功能
开发者发布自己的功能
项目维护者集成开发者的功能
开发者和正式仓库做同步
2.3.1 工作方式
2.3.2 历史分支
2.3.3 功能分支
2.3.4 发布分支
2.3.5 维护分支
2.3.6 示例
创建开发分支
小红和小明开始开发新功能
小红完成功能开发
小红开始准备发布
小红完成发布
最终用户发现Bug
2.2.1 工作方式
2.2.2 Pull Requests
2.2.3 示例
小红开始开发一个新功能
小红要去吃个午饭
小红完成功能开发
小黑收到Pull Request
小红再做修改
小红发布她的功能
与此同时，小明在做和小红一样的事
2.1.1 工作方式
2.1.2 冲突解决
2.1.3 示例
有人先初始化好中央仓库
所有人克隆中央仓库
小明开发功能
小红开发功能
小明发布功能
小红试着发布功能
小红在小明的提交之上rebase
小红解决合并冲突
小红成功发布功能
2.1 集中式工作流
2.2 功能分支工作流
2.3 Gitflow工作流
2.4 Forking工作流
2.5 Pull Requests
一、译序
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是Git或SVN等VCS或SCM工具的使用。
这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的Pull Request功能，体系地讲解了各种工作流的应用。
行文中实践原则和操作示例并重，对于Git的资深玩家可以梳理思考提升，而新接触的同学，也可以跟着step-by-step操作来操练学习并在实际工作中上手使用。
关于Git工作流主题，网上体系的中文资料不多，主要是零散的操作说明，希望这篇文章能让你更深入理解并在工作中灵活有效地使用起来。
PS：
文中Pull Request的介绍用的是Bitbucket代码托管服务，由于和GitHub基本一样，如果你用的是GitHub（我自己也主要使用GitHub托管代码），不影响理解和操作。
PPS：
本指南循序渐进地讲解工作流，如果Git用的不多，可以从前面的讲的工作流开始操练。操作过程去感受指南的讲解：解决什么问题、如何解决问题，这样理解就深了，也方便活用。
Gitflow工作流是经典模型，体现了工作流的经验和精髓。随着项目过程复杂化，会感受到这个工作流中深思熟虑和威力！
Forking工作流是协作的（GitHub风格）可以先看看Github的Help：Fork A Repo和Using pull requests 。照着操作，给一个Github项目贡献你的提交，有操作经验再看指南容易意会。指南中给了自己实现Fork的方法：Fork就是服务端的克隆。在指南的操练中使用代码托管服务（如GitHub、Bitbucket），可以点一下按钮就让开发者完成仓库的fork操作。
:see_no_evil: 自己理解粗浅，翻译中不足和不对之处，欢迎建议（提交Issue）和指正（Fork后提交代码）！
二、Git工作流指南
:point_right: 工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种Git工作流让大家可以上手使用。
在阅读的过程中请记住，本文中的几种工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后，你可以从不同的工作流中挑选或揉合出一个满足你自己需求的工作流。
2.1 集中式工作流
如果你的开发团队成员已经很熟悉Subversion，集中式工作流让你无需去适应一个全新流程就可以体验Git带来的收益。这个工作流也可以作为向更Git风格工作流迁移的友好过渡。
转到分布式版本控制系统看起来像个令人生畏的任务，但不改变已用的工作流你也可以用上Git带来的收益。团队可以用和Subversion完全不变的方式来开发项目。
但使用Git加强开发的工作流，Git有相比SVN的几个优势。
首先，每个开发可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分修改独立开来 ——
即自由地提交到自己的本地仓库，先完全忽略上游的开发，直到方便的时候再把修改反馈上去。
其次，Git提供了强壮的分支和合并模型。不像SVN，Git的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。
2.1.1 工作方式
像Subversion一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比SVN缺省的开发分支trunk，Git叫做master，所有修改提交到这个分支上。本工作流只用到master这一个分支。
开发者开始先克隆中央仓库。在自己的项目拷贝中像SVN一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
要发布修改到正式项目中，开发者要把本地master分支的修改『推』到中央仓库中。这相当于svn commit操作，但push操作会把所有还不在中央仓库的本地提交都推上去。
2.1.2 冲突解决
中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，Git会拒绝push提交否则会覆盖已经在中央库的正式提交。
在开发者提交自己功能修改到中央库前，需要先fetch在中央库的新增提交，rebase自己提交到中央库提交历史之上。
这样做的意思是在说，『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史，就像以前的SVN的工作流中一样。
如果本地修改和上游提交有冲突，Git会暂停rebase过程，给你手动解决冲突的机会。Git解决合并冲突，用和生成提交一样的git status和git add命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，Git可以很简单中止整个rebase操作，重来一次（或者让别人来帮助解决）。
2.1.3 示例
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。
有人先初始化好中央仓库
第一步，有人在服务器上创建好中央仓库。如果是新项目，你可以初始化一个空仓库；否则你要导入已有的Git或SVN仓库。
中央仓库应该是个裸仓库（bare repository），即没有工作目录（working directory）的仓库。可以用下面的命令创建：
1
2
ssh user@host
git init --bare /path/to/repo.git
确保写上有效的user（SSH的用户名），host（服务器的域名或IP地址），/path/to/repo.git（你想存放仓库的位置）。
注意，为了表示是一个裸仓库，按照约定加上.git扩展名到仓库名上。
所有人克隆中央仓库
下一步，各个开发者创建整个项目的本地拷贝。通过git clone命令完成：
1
git clone ssh://user@host/path/to/repo.git
基于你后续会持续和克隆的仓库做交互的假设，克隆仓库时Git会自动添加远程别名origin指回『父』仓库。
小明开发功能
在小明的本地仓库中，他使用标准的Git过程开发功能：编辑、暂存（Stage）和提交。
如果你不熟悉暂存区（Staging Area），这里说明一下：暂存区的用来准备一个提交，但可以不用把工作目录中所有的修改内容都包含进来。
这样你可以创建一个高度聚焦的提交，尽管你本地修改很多内容。
1
2
3
4
git status # 查看本地仓库的修改状态
git add # 暂存文件
git commit # 提交文件
<div>
请记住，因为这些命令生成的是本地提交，小明可以按自己需求反复操作多次，而不用担心中央仓库上有了什么操作。
对需要多个更简单更原子分块的大功能，这个做法是很有用的。
小红开发功能
与此同时，小红在自己的本地仓库中用相同的编辑、暂存和提交过程开发功能。和小明一样，她也不关心中央仓库有没有新提交；
当然更不关心小明在他的本地仓库中的操作，因为所有本地仓库都是私有的。
小明发布功能
一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的git push命令：
1
git push origin master
注意，origin是在小明克隆仓库时Git创建的远程中央仓库别名。master参数告诉Git推送的分支。
由于中央仓库自从小明克隆以来还没有被更新过，所以push操作不会有冲突，成功完成。
小红试着发布功能
一起来看看在小明发布修改后，小红push修改会怎么样？她使用完全一样的push命令：
1
git push origin master
但她的本地历史已经和中央仓库有分岐了，Git拒绝操作并给出下面很长的出错消息：
1
2
3
4
5
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
这避免了小红覆写正式的提交。她要先pull小明的更新到她的本地仓库合并上她的本地修改后，再重试。
小红在小明的提交之上rebase
小红用git pull合并上游的修改到自己的仓库中。
这条命令类似svn update——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并：
1
git pull --rebase origin master
--rebase选项告诉Git把小红的提交移到同步了中央仓库修改后的master分支的顶部，如下图所示：
如果你忘加了这个选项，pull操作仍然可以完成，但每次pull操作要同步中央仓库中别人修改时，提交历史会以一个多余的『合并提交』结尾。
对于集中式工作流，最好是使用rebase而不是生成一个合并提交。
小红解决合并冲突
rebase操作过程是把本地提交一次一个地迁移到更新了的中央仓库master分支之上。
这意味着可能要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。
这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来，简化了哪里引入Bug的分析，如果有必要，回滚修改也可以做到对项目影响最小。
如果小红和小明的功能是相关的，不大可能在rebase过程中有冲突。如果有，Git在合并有冲突的提交处暂停rebase过程，输出下面的信息并带上相关的指令：
1
CONFLICT (content): Merge conflict in <some-file>
Git很赞的一点是，任何人可以解决他自己的冲突。在这个例子中，小红可以简单的运行git status命令来查看哪里有问题。
冲突文件列在Unmerged paths（未合并路径）一节中：
1
2
3
4
5
# Unmerged paths:
# (use 'git reset HEAD <some-file>...' to unstage)
# (use 'git add/rm <some-file>...' as appropriate to mark resolution)
#
# both modified: <some-file>
接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让git rebase完成剩下的事：
1
2
git add <some-file>
git rebase --continue
要做的就这些了。Git会继续一个一个地合并后面的提交，如其它的提交有冲突就重复这个过程。
如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行git pull --rebase命令前的样子：
1
git rebase --abort
小红成功发布功能
小红完成和中央仓库的同步后，就能成功发布她的修改了：
1
git push origin master
如你所见，仅使用几个Git命令我们就可以模拟出传统Subversion开发环境。对于要从SVN迁移过来的团队来说这太好了，但没有发挥出Git分布式本质的优势。
如果你的团队适应了集中式工作流，但想要更流畅的协作效果，绝对值得探索一下功能分支工作流 的收益。
通过为一个功能分配一个专门的分支，能够做到一个新增功能集成到正式项目之前对新功能进行深入讨论。
更详细内容请点击原文连接查看。
