TMD，我的 branch 又被同事搞烂了，我都不知道怎么修

[ericgui]

我们组长的思维方式是，你们各位同时做不同的 feature，一个 feature 一个 branch

然后做完了就提 pr，review 过了就 merge 到 dev 分支。

那么，如果你的 branch 还没做完，你就应该及时合并 dev，拿到最新的 feature

已经发生无数次了，我的 branch 被 dev 分支搞乱，结果我要花大量的时间来解决冲突，甚至修 dev 分支的 bug。 这 TMD，岂不是谁动作快，谁就可以把烂摊子甩给别人？

烦死了

大家有什么好的解决方案吗？

[CEBBCAT]

为虾米会被 dev 分支搞乱捏？那边的代码不都是经过 review 吗？

但有了问题找组长应该是一个常见解法吧，楼主效果如何？

[findingpan]

你的 PR 和 dev 有 merge conflict 的時候肯定是你要去 solve 啊， 改 BUG 不应该是另一个 branch 吗 为啥你要去改

[xiadong1994]

merge 上游分支当然要解决冲突，不然等你 merge 到 dev 的时候冲突更多。

pr 的明显 bug 有 CI 自动测试的话这个 pr 根本就没法合并。如果已经有了就把你的分支回滚到 merge 之前，然后谁写的 bug 谁去修

[wangyzj]

你的 branch 怎么会让你的同事去动！

[nvkou]

理想情况 features 之间不会有交集。所以这样安排也没啥问题。但如果经常动公共 code base 就是你组长分工没分好。或者项目分离没做好了

[ericgui]

@CEBBCAT review，但没有单元测试

[ericgui]

@wangyzj 他改了一个全局的东西，然后也没测试，就直接 merge 了，就不管了。

[ericgui]

@nvkou 他显然不合格

[ericgui]

@wangyzj 准确来说，他自己测了一下这个全局变量对自己的影响， 然后没问题，就提 pr 了，又没有单元测试，组长就让他过了。

[poplar50]

rebase 吗? 加 feature 不应该造成大量冲突的。。

[ericgui]

@poplar50 merge

[ericgui]

@nvkou 你们一般怎么做的？

[downdowndown30]

感觉是没有单元测试的锅啊。。。

[leoaqr]

少用 merge，多用 rebase。一个 feature 一个 branch 没毛病，pr 过了要回 master branch 的时候先 squash 成一个 commit，然后 merge。如果怕 conflict 过大，可拆分成多个小 commit，手动 cherry-pick。

[jedihy]

有冲突不应该能 merge 成功啊，至少我们不能。

[ericgui]

@downdowndown30 是的，2 个月要完成一个 MVP，没有测试。

[msg7086]

@leoaqr 不建议 squash 成一个。

[reus]

没有测试开发个鸡巴，辞职！

[zjsxwc]

多写新文件，少改旧文件

[weixiangzhe]

dev 更新就及时 rebase 没事就 rebase 一下， 这样冲突少很多。 要是功能开发时间太长 那合并的时候是真看不懂