Git 作为一个代码版本管理系统，利用它强大的版本控制和branch，我们能做出一些优雅的团队协作的工作流。
这也是之前我在Git文章谈到的，Git对团队协作具有很大帮助，这篇文章我将来谈谈基于Git的三大工作流。
工作流 在英语中叫做：workflow，从名字上看出团队协作应该像流水一样，顺畅。
好的工作流能给你团队合作带来很大的好处，有条不紊的应对各种问题。坏的工作流可能会使本来一个很好的项目失败在团队协作上。所以我们来学学程序员常用到的工作流。
现在三种广泛使用的工作流程：
Git flowGithub flowGitlab flow如果你对Git还不是很熟悉，可以先阅读下面的文章。
用《只狼》教你学会Git（上）用《只狼》教你学会Git（中）用《只狼》教你学会Git（下） 一、功能驱动本文的三种工作流程，有一个共同点：都采用 “功能驱动式开发”（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
二、Git flow最早诞生、并得到广泛采用的一种工作流程，就是Git flow，相对来说是复杂度较高的，可以看到下面这张图片：
2.1 特点从上面这张图片可以看到，它最主要的特点有两个。
首先，项目存在两个长期分支。
主分支master开发分支develop master用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；develop用于日常开发，存放最新的开发版。其次，项目存在三种短期分支。
功能分支（feature branch）补丁分支（hotfix branch）预发分支（release branch）所谓短期分支就是，基于功能，补丁，预发布，一旦完成开发，它们就会被合并进develop或master，然后被删除。
2.2 优缺点Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。
大多数工具都将master当作默认分支，可是开发是在develop分支进行的，虽然让逻辑更清晰，但这导致经常要切换分支，有一定的复杂度。
但更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，也就是说如果我发布版本的频率很高，代码一有变动，就部署在master一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
所以根据具体项目情况，选择合作方式。
三、Github flowGithub flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程，也同时是参加开源项目的主要合作方式之一。
3.1 流程它只有一个长期分支，就是master，因此用起来非常简单。
定义：
合作的仓库：我称之主仓库；
个人fork之后的仓库：我称之为子仓库。
官方推荐的流程如下。
预处理：先从主仓库fork出一个子仓库。
第一步：根据需求，从子仓库的master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向中央仓库的master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
3.2 评价Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。
问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。
可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，苹果商店的APP提交审核以后，等一段时间才能上架。
这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。
另一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会导致线上版本落后于master分支。
上面这种情况，只有master一个主分支就不够用了。通常，你不得不在master分支以外，另外新建一个production分支跟踪线上版本，即在等待中进行继续开发。
不过上面所说的情况不是所有项目都能遇到的，根据实际情况随机应变很重要
四、Gitlab flowGitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
4.1 上游优先Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
4.2 持续发布Gitlab flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
4.3 版本发布对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
总结：对于三大工作流，我个人认为没有绝对的最好和最坏的合作方式.
在不同场景下，不同工作流各自有着各自的优势，根据团队情况，项目情况选择合适的工作流是最重要的。
同时可以根据实际对工作流进行修改，不必生搬硬套。
希望你有所收获～