工作流的设计是日常开发工作中必须考虑的问题，关乎团队的协作模式，所谓「流」就是保证项目平稳、顺畅地向前迭代，本文介绍三种主要的 Git workflow
Git flow
出现最早，应用最广的一种工作流程，基于”版本发布”的工作流
- 项目存在两个长期分支：主分支
master、开发分支develop；三种短期分支：功能分支feature、补丁分支hotfix、预发分支release master用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版develop用于日常开发，存放最新的开发版release分支源于develop分支，用于发布之前（即合并到master之前）的预发布测试，结束以后必须合入develop和master分支- 一旦完成开发，三个短期分支就会被合并进
develop或master，然后被删除 - 优点：清晰可控
- 缺点：相对复杂，需要同时维护两个长期分支。对于有”持续发布”需求的项目，代码一有变动就需要部署一次，
develop需要频繁地合入master，导致这两者的差别不大，没必要维护两个长期分支
Github flow
Github flow是Git flow的简化版，专门配合”持续发布”。它是Github.com使用的工作流程
- 它只有一个长期分支，就是
master，使用流程如下： - 第一步：根据需求，从
master拉出新分支，不区分功能分支或补丁分支 - 第二步：新分支开发完成后，或者需要讨论的时候，就向
master发起一个pull request（简称PR） - 第三步：
Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码 - 第四步：你的
Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可） - 优点：简单，对于”持续发布”的产品是最合适的流程
- 缺点：假设了合入到
master就能立刻发布，没有考虑发布窗口，往往需要另外新建一个production分支跟踪线上版本
Gitlab flow
Gitlab flow是Git flow与Github flow的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利
- 最大原则叫做”上游优先”（
upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支 - 对于”持续发布”的项目，它建议在
master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production - 开发分支是预发分支的”上游”，预发分支又是生产分支的”上游”。代码的变化，必须由”上游”向”下游”发展
- 对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从
master分支拉出一个分支，比如2-3-stable、2-4-stable等等
关于 rebase 和 merge
rebase的含义是改变当前分支branch out的位置，merge负责功能分支合并到主分支
git rebase其实可以把它理解成是「重新设置基线」，将当前分支重新设置开始点，这样才能知道当前分支和需要比较的分支之间的差异rebase并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面- 只对尚未推送的本地修改执行
rebase操作清理历史，从不对已推送至别处的提交执行rebase操作，即不要在公共分支使用rebase