相信任何一个开发人员在看到冲突消息时都会沮丧地撕扯头发。试图解决合并冲突是每个开发人员都讨厌的事情，特别是当准备进行生产部署时。而这就是正确的git workflow可以解决的问题。当然，正确的git workflow不能解决所有问题。但这是朝着正确方向迈出的一步。
如何设置git workflow取决于项目、团队的发布时间表、以及团队的规模等， 本文将带你了解5种不同的git workflow、它们的优缺点以及应该在什么时候使用它们。
1. 基本的Git Workflow
最基本的git workflow只有一个分支——master分支。在这个workflow中，所有提交都被直接添加到mastser分支，并部署到staging环境和生产环境中。
除非这是一个小项目，并且你想快速上手， 否则不推荐使用这种workflow：
- 团队协作时会有很多冲突
- 将Bug提交到master的的几率变高
- 很难维护一套干净的代码
2. Git 特性分支 Workflow
Git 特性分支 Workflow适用于多个开发人员协作的情况。假设有一个开发人员正在开发一个新特性，另一个开发人员正在开发第二个特性。如果两个开发人员都在同一个分支工作，并向他们添加提交，这将使代码库变得非常混乱，并产生大量冲突。
为了避免这种情况，这两个开发人员可以从master分支中创建两个独立的分支，完成了自己开发的特性后，就可以将各自的分支合并到master分支，并且无需等待其他特性完成就可以进行部署。
3. Git dev+特性分支 Workflow
这种workflow是开发团队中比较流行的workflow之一。它类似于Git特性分支workflow，但多一个dev分支，该分支是并行添加到master分支的。
在这个workflow中，master分支的代码总是用于部署生产环境。dev分支反映了下一个版本最新交付的开发变更的状态。开发人员从dev分支创建分支，并开发新特性。一旦特性的开发完成，就对它进行测试，然后与dev分支合并，同dev分支的合并的代码一起进行测试，以防重复合并。
4. Gitflow Workflow
Gitflow Workflow 与我们之前介绍的其他workflow也非常相似， 它分为
热修复（hot-fix）分支
热修复分支是唯一从master分支创建并直接合并到master分支而不是dev分支的分支。它仅在必须快速修复生产问题时使用。这个分支的优点是，它允许快速修复生产环境的问题，而不需要等待下一个发布周期。
一旦热修复合并到master分支并部署，它也应该被合并到dev分支和当前的release分支。这样做是为了确保那些fork分支的开发者也可以更新最新的代码。
版本（release）分支
版本分支是在dev分支将所有为发布而开发的特性成功地合并到其中之后从dev分支派生出来的。
只有与此版本相关的代码才会添加到发布分支中，与新特性相关的其他代码则不会添加到版本分支中。
一旦这个分支与master分支合并并部署到生产环境中，也要将它合并到dev分支中，这样当一个新特性从dev分支中派生出来时，它就会使用最新的代码。
在Windows上安装使用这个workflow， 只需要在项目中运行git flow init。
5. Git 分叉（fork）Workflow
分叉workflow在开源软件的团队中非常流行。
流程如下：
- 首先 fork 官方库， 创建一个官方仓库的副本
- 然后开发人员将库clone到本地环境
- 官方库的远程路径添加到本地repo中
- 开发人员在本地创建新特性分支，进行更改并提交。
- 这些更改连同分支一起推送到官方库的副本中
- 请求push到官方库
- 官方库的管理员检查更改， 同意将更改合并到官方库。
