贵公司的分支机构战略是什么？转载本文请在twitter上大胆联系Yu公众号。在基于git的工作流中，master一般进行持续集成。开发人员在功能分支中进行开发。测试完成后会合并到master上进行集成测试。如果测试通过，就意味着master可以部署了。但是现实中feature分支自测是ok的，但不代表真的ok。测试人员还没有测试过，所以此时的master分支其实还没有准备好（从master具体的commitid到生成的分支其实是有一定难度的）我们目前的做法是有一个SIT系统集成分支在master分支之前，也就是说这个分支是专门给QA人员测试的。测试ok后，将feature分支的代码合并到pre分支。如果模拟环境没有问题，将feature分支合并到master分支中，然后release。SIT分支相当于做集成测试，保证master的代码相对可靠。那么什么代码合并到SIT分支呢？不管项目有多少，或者这些项目的具体上线时间，都可以将feature分支合并到SIT分支，然后由QA人员统一测试（相当于提前测试多个项目）。正因为如此，上线时无法从SIT分支合并到master分支。这样的工作流程多了一个步骤，难免会有副作用。首先，合并到SIT分支时，如果有冲突，SIT分支不要解决冲突，因为SIT分支只是做测试，不会上线，所以冲突不要解决。;其次，很多人说为了避免冲突，我经常将SIT分支上的代码合并（也就是pull）到feature分支上，这也是很不好的，因为这个feature分支不是孤立的。所以正确的做法，如果merge和SIT分支有冲突，应该自己解决冲突，但是怎么找那个分支的冲突呢？还有，SIT分支和master分支的时间点和作用不同，所以不需要保持代码同步。理论上pre分支和master分支应该是同步的。上线时之所以没有选择将SIT分支合并到master分支，是因为cherry-pick还是有一定的复杂度，merge具体的commitid也有复杂度，所以我们选择从feature分支的时候合并到master中，需要思考一个问题。预分支测试是否通过主分支测试？如果prebranchtomaster是快进的话，理论上是不需要重复测试的。还有一种方法和我们的类似，就是有一个看不见的SIT分支。一旦feature分支被提交到远端，它会自动合并到SIT分支，检查是否有冲突。如果有冲突，会提醒开发者解决。确保持续集成。最后说一下特性分支。我们也喜欢按照迭代周期做一个大分支。事实上，这个大分支包含了很多子功能，也就是说，它可以拆分成多个子分支。这两种方法的优缺点是什么？?如果在大的分支，可以减少一些冲突，但是不能做隔离。如果你频繁拉取，你应该选择merge还是rebase？你应该选择合并。pushedtoremotebranches不推荐rebase，会导致很多问题。其实既然选择了大分支，那么git历史难免难看，基本没有可追溯性。如果确实要使用大分支，建议不要过于频繁的向远端提交，提交前尽量做自测。SIT部署的环境（QA）是供测试人员测试的，应该保证一定的稳定性。它们不是供开发人员调试的。建议还是分行。一方面，有些功能可能哪天上线，支行适合；此外，还可以隔离支行；当然可能会有很多合并冲突的问题。分支有冲突（暂时想不出办法）。git工作流有很多选择，主要看整个团队对git的理解，并行项目的数量，CI/CD方式等，没有绝对的好坏，只要有意义，没有缺点明显，工作流程还不错。
