本文转载自微信公众号「虞大胆的叽叽喳喳」，作者虞大胆 。转载本文请联系虞大胆的叽叽喳喳公众号。
在基于git的工作流中，master一般是做持续集成的，开发人员在特性分支开发，经过测试后，就会merge到master做集成测试，测试通过就表示master可部署了。
可现实情况下，特性分支自测没问题，不代表就真的没问题，测试人员还没测试呢，所以此时的master分支其实是没准备好的(从master特定commit id到生成分支其实是有一定难度的)
我们目前的做法，在master分支之前还有一个SIT系统集成分支，也就是说这个分支是专门给QA人员测试的，测试没问题后，将特性分支的代码合并到pre分支，仿真环境如果没问题，再将特性分支合并到master分支，然后进行发布。
SIT分支相当于做集成测试了，保证了master的代码是相对可靠的。
那什么代码合并到SIT分支呢?不管几个项目，也不管这些项目具体的上线时间，特性分支都可以合并到SIT分支，然后统一给QA人员测试(相当于提前测试多个项目了)，正因为这样，上线的时候无法从SIT分支merge到master分支。
这种工作流多了一个步骤，必然会有副作用，首先merge到SIT分支的时候，如果有冲突，SIT分支不应该解决冲突，因为SIT分支只是为了测试，不会上线的，所以不应该解决冲突;其次很多人说为了避免有冲突，那么我就经常性的将SIT分支上的代码merge(也就是pull)到特性分支，这也非常不好，因为这个特性分支就不隔离了。所以正确的做法，如果merge到SIT分支产生冲突，应该自己去解决冲突，可如何找到和那个分支冲突呢?
还有SIT分支和master分支因为时间点和作用不一样，没有必要保持代码是同步，可pre分支和master分支理论上应该保持同步，上线的时候没有选择merge SIT分支到master分支的原因是cherry-pick还是有一定复杂度的，merge特定commit id也是有复杂度的，所以我们选择从特性分支合并到master，那必然要思考一个问题，pre分支测试通过代表master分支测试通过吗?如果pre到master是一个fast forward，理论上不用再重复测试。
还有一种做法和我们的做法类似，就是有一个隐形的SIT分支，特性分支一旦提交到远端，就自动merge到SIT分支，查看是否有冲突，如果有冲突，就提醒开发者去解决，从而保障能够持续集成。
最后说说特性分支，我们还喜欢根据迭代周期去弄一个大分支，实际上这个大分支包含了很多子功能，也就是说可以拆分为多个子分支，那这两种方式有什么优缺点呢?
如果在一个大分支，能够减少一些冲突，但做不到隔离了，如果频繁的pull，是选择merge还是rebase呢?应该选择merge，推送到远端的分支不建议做rebase，会产生很多问题。其实既然选择了一个大分支，那git历史记录必然会很难看的，基本没有追朔性。如果实在要使用一个大分支，建议不要太频繁的提交到远端，尽量做好自测再提交。SIT部署的环境(QA)是为了测试人员测试的，应该保障一定的稳定性，它们不是给开发人员调试用的。
建议还是子分支，一方面说不定有一天就上线部分功能，子分支就合适了;另外子分支也能做到隔离;当然可能会遇到很多merge冲突的问题，这时候就需要自己甄别与那个分支发生冲突了(目前没有想到办法)。
git工作流有多种选择，主要看整个团队对git的理解程度，并行项目数量，CI/CD方式等等，没有绝对的好坏，只要能说得通，没有明显的缺点，那就是好的工作流。
