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 一下， 这样冲突少很多。 要是功能开发时间太长 那合并的时候是真看不懂

[avenger]

没有单元测试的锅

[bleutee]

當然是 rebase 啊。
流程上我覺得沒問題

[zyqhi]

不同 feature 之间不应该尽量正交吗？

[pkookp8]

rebase 可以把 dev 分支的内容合并到你的分支
解决冲突后如果需要可以 merge，没需要继续改就行了

[0x400]

深入贯彻 git 之父的思想😂

[Lin0936]

这种我一般 rebase

[sonxzjw]

要我就以其人之道还之其人之身
just do it

[rosu]

这已经不是 git 的范畴了。任何 git-flow 都无法杜绝“他改了一个全局的东西，然后也没测试，就直接 merge 了，就不管了“。
这个上游有 bug，下游肯定受影响啊。不过 merge 还是 rebase，都会把 bug 合并进来。

[chinese_zmm]

@CEBBCAT 赞同，留下证据，找组长讨论解决

[ArtIsPatrick]

应该测完了再往一个分支上合，而不是 review 完就合。保证你只合测过的可以上线的代码。

[sgissb1]

这属于分工边界不清晰的问题。用分支来管理特性边界是错误的做法。分工上边界清晰了，就算再同一个分支里面开发也不存在类似问题。

[xuanbg]

只有两个分支的同一个文件都有修改，合并才会有冲突，所以理想情况下是不允许两个分支同时去修改同一个文件的。你们组长的分支策略没错，但不同 feature 居然会修改很多相同文件，显然是项目的模块划分有很大的问题。

[passerbytiny]

一个功能一个分支的多分支开发，请每天首先从主分支向个人分支 rebase，就像以前 SVN 的每日 update 一样。这样你就可以尽早的发现冲突，虽然不能减少总的冲突解决时间，但是能让你的工作计划更合理。

记得每日 rebase 的时候截图一下冲突情况，对于多次发生的同一种冲突要及时上报。

[Salvation]

@ericgui 他测了对自己的影响，dev 的代码在他自己的逻辑里面是 OK 的？那这个时候 dev 的代码到底是 ok 的吗？是说你的代码合并上去之后有问题，还是这个时候 dev 的代码已经有问题了？

[yogogo]

改全局的东西不相互通知下吗

[wizardoz]

你们都不写单元测试的吗？

[ericgui]

@Salvation dev.不 ok 啊，但没有单元测试啊

[sliwey]

只要你手快，冲突就影响不了你

[winterbells]

这种弱智就往上报啊
我这边也有个，每次推一堆 bug，找组长找老板

谁污染，谁治理。谁开发，谁保护😋

[jzphx]

分支策略没啥毛病，有问题的是你那同事的业务水平

[8355]

不是自己分支 提 merge request?
全程跟其他人的分支有啥关系啊

[lspvic]

讲道理，流程上一点问题也没有。就是你组长不该把有问题的 pr 通过，二一个就是你改的时候尽量避开你同事可能会改的地方，比如全局的东西不要每次都在最后加代码，可以写到中间

[avalon8]

我们是 feature 分支提交到 dev 分支测试通过后，再把 feature 分支提到 release 分支，测试过后，再把 release 合并到生产环境。提交代码之前先在本地合并解决冲突后在提交 PR，涉及到谁的 bug 找谁就行了

[syrupofplum]

我也同意一个功能一个 branch，自己的 branch 自己维护。还是应该和组长多沟通，dev 分支的问题，这个不应该由你来处理。

[hantsy]

@ericgui 你们不写测试吗？不做 CI 吗？ CI 都跑不过的话，怎么可能合并代码。

另外建议功能 Branch 尽可能的小，一个 Task 最好能控制在一天内完成，否则分细些（用一个 Task 包含多个 checklist, 或者用一个 epic 管理）。这样尽可能的频繁更新，冲突也少。

[hantsy]

@wizardoz 对，这才是关键问题所在。如果有测试，肯定要让所有的测试通过，才能到 Dev 分支上去。

[ericgui]

@hantsy 没办法的，现在 MVP 阶段，变动特别大，没有测试，没有 CI CD

至于一个 pr 尽可能小，我们也在努力，但每次都是大几十上百行的删减，没有小 pr

总之就一句话，MVP 阶段， 啥也没有，而且有一个 deadline，必须月底上线

我就是抱怨几句，其实这也没办法的

[GzhiYi]

改上游跟 rebase 和 merge 什么关系，这种没法避免，只能说养成接冲突的习惯。

[newtype0092]

改全局的东西别混在 feature 里啊，修改底层基础的东西单独提交，你 rebase 下来的时候注意下又没有跟你相关的改动注意下就行了。

[wangyzj]

@ericgui 咦。。。你们的开发经理有问题啊，而且 CI 呢？

[holy_sin]

review + 测试通过才可以合？

[conn4575]

如果你同事对这个变量的改动因为测试没发现有 bug，那么就是他的问题。如果在他提交 PR 的阶段是没有问题的，那么问题就在你，一个长期的分支应该每隔几天就和主分支同步一次，这要保证最终 PR 时不会有大量冲突。
话说改全局的东西不事先沟通一下吗？我一般都要先根据 git log 跟原来的人沟通一下才会改的。

[liuxliang]

1.你们的流程有问题，可以建议修改
2.你们的的沟通有问题
3..local 文件了解一下，可以设置自己的配置，不上传就行，改只需要改自己的配置
4.有问题想办法解决

[hantsy]

@ericgui 跟 MVP 没关系，从来没有听说 MVP 可以省掉一些必要的东西。
相反越是越 MVP 阶段越应该把测试，CI、CD，项目自动化做到位。你们这样的下去，项目债务一直积累，项目最终会成为一团滥泥。

[ericgui]

@hantsy 我们已经决定了，MVP 之后的第一件事就是迁移到 ts，加上 unit test

[hantsy]

@ericgui 这种想法我以前在公司上班听过好多次，最终都是各种理由，不了了之。

就我之前的经历，后面再加上的可能性太小。

很多习惯一开始就需要培养的，到了一定时候，想再改过来，操作上太难，人都是有惰性的。到时你会发现之前做 MVP 赶的那点时间都是白费，你可能还要另外多花一两倍时间去写测试（当然这是要写测试的话）。

[Freeego]

全局的东西应该有个框架部门专门负责，业务部门都不应该有这个权限 merge 上去

[tabris17]

简单，你把它修改的全局部分再改回去

[noobcoder1]

一看就是自己一个人在那写着一身劲。。长时间不 merge 主线引来的冲突还怪同事把你 feature 搞坏了 。。

每天码代码前不知道 pull 看下么。。。

姿势不对还怨人。。

[y_ding]

此已非 git 或者其它衍生工具的问题了，任何工具或者系统，都很难解决 “他改了一个全局的东西，然后也没测试，就直接 merge 了，就不管了“ 的问题。

[FrankHB]

你自己的 branch 难道不是你做主？不给 force push ？
只要你用的 DVCS，你就应该有底气你的工作以你为准。

[janus77]

我刚毕业写代码的时候也犯过这个问题。改了一个全局的东西影响别人了。
这个和分支关系不大，主要是你同事他太菜了。不知道什么能改什么不能改。
测试只是辅助的手段和规则，但是作为开发者本人应该是有意识的，团队协作本身就是呆着脚镣，即使开了分支也一样。他完全不在乎，当成自己的私有地盘了。

[FrankHB]

@noobcoder1 在 feature branch 上每天先 pull 是典型的没约定职责清楚边界的错误姿势。
正常的做法是维护 feature branch 的人员不需要同时关心 merge 足够大的 milestone 以外的版本，要 merge 也是从 feature branch 往 dev 由专人负责，否则根本就没开 feature branch 的意义，还用毛线 DVCS。

[FrankHB]

@janus77 这里看上去一方面是改的人太菜，一方面也是做 review 的人菜，没搞清楚第一时间把整个项目的公共配置恢复到正常可用的（不会动不动就累积冲突的）状态。
协作 review 代码的职责不只是为了验证代码的实现情况，更重要的是了解当前别人的工作情况并协调工作进度保证不会对项目的全局目标引起灾难性后果——不 review 的情况下只要作者自己靠谱前者的问题还可能不大，而后者……冲突一频繁整个项目的进度可能就完蛋了。
还可能是因为负责人太氵，根本就没安排资源去做配置管理，没让人搞清楚只允许改哪些地方……当然，对过大的、沟通路径太多的项目，使用权限管理不够强的 VCS （如 git 这种一开始就只考虑 bazaar model 项目协作的）时，可能加物理分隔（分 repo/submodule ）来强制更可靠一点。

[fzy0728]

可以 fork 到自己的 repo,然后 remote add ,之后修改自己 repo 的自己分支下的内容，然后再 merge 不就好了么

[n1ck3dcydoom]

我喜欢随时 fetch 一下，发现如果要合并的分支有改动，就 rebase 过去，解决冲突，然后再 merge 就不会有冲突了

[yinft]

正常操作，尽量少动自己开发文件以外的文件

[Solace202]

还是我一个人一个项目舒服，所以省去了 feature，直接 dev 开发

[likefly]

单元测试的重要性不言而喻，你这个就是血淋淋的例子

[likefly]

大量冲突难道你们分工有很多重复的地方？

[rajame]

你这是因为没有测试覆盖和代码 review 造成的

[Flicker]

我觉得流程没问题啊，很多人建议用 rebase，我觉得这个地方更适合 merge 吧，graph 才能更清晰吧。
其实 pr 尽可能的小很重要，积极沟通更重要。
你们看过同事抢先 push 代码后呵呵笑的表情吗？

[chinawrj]

建议转行。代码对你来说可能有点不像你想得那样运转

[jkmf]

？？这不叫搞坏吧，明显是你们同时改了相同的 feature,才会有冲突。是不是分工有问题？引入 bug 的话是另外一个问题，codereview 没做好？

[wingyiu]

git reset --hard localcommithash
git push -f origin

去他喵的

[Fule]

分支策略层面：

1. 不同分支应该尽量处理项目中不同区域的问题，以此降低冲突的概率。
2. 公共代码的修改应该由专人从那些分支的主干上进行修改，然后“散布”到各个子分支上去。

按 feature 进行分支本身没问题，但是如果 2 个 feature 涉及到大量公共的内容，比如同一块功能的 2 个新特性，那么应该放在一个分支上顺序实现。否则 git 也无法从根本上解决冲突的发生。

个人工作层面：

1. 尽量频繁的将自己分支的代码 rebase 到最新的父分支上，降低最终代码合并到主干时冲突的可能性，同时频繁 rebase 自己的代码，即使发生冲突，其规模也会相对较小，而且冲突的解决是在你自己的分支上，别人不受任何影响。
2. 如果涉及到公共代码的调整，一如分支策略 2 所述，要么告知负责公共代码的专人在主干上调整，然后 rebase 到你自己分支上，要么你自己在主干上调整，然后 rebase 到你自己分支。

[nicebird]

你们的模块划分有问题，理论上划分清晰的话，合并根本没有什么冲突，也就不需要没事对齐 master.

[alvin2ye]

多用 rebase, 如果冲突, 马上解决, 有疑问马上结对 review. 这个步骤越快, 技术债务越少

[vjnjc]

跟楼上说的 rebase 都没关系，甚至跟 git 也没关系。
确实是谁手快就谁生效。
但根据你的描述 merge 进 dev 会 review，为啥他没被 review，或者是 review 不严格？？感觉这里出问题了。

[noobcoder1]

@FrankHB 长偏大论 屌用没有 ，想法很好，但不切实际。。 因为一个团队中水平不一，你永远想不到你的队友会干啥！不要指望 code review 会有多负责，你自己写的代码什么卵样自己心里没个逼数？ 还指望人 review ？ 频繁 pull 我认为并没有什么问题，而且不 pull 你怎么知道主线上有哪些傻叼改了代码？ 我建议务实一点，自己编码时尽量在自己的分支上干，遇到 bug 自己本地开分支改好主动合，每天编码前多 pull 看下研发主线分支的改动，尽量把最新的代码合到自己分支上再继续开发，有冲突尽早的解决，功能好了没问题就尽早往主线合，不要等做完了再合，这样冲突应该会很少，即使有也不会觉得很乱。

[FrankHB]

@noobcoder1 Review 不清楚的后果自负。说好的不听还能干啥？打得过有主线 force push 权限有本地访问权限的配置管理员？不想自己维护的计算工作量的分支整个历史被编辑掉就老实听话，哪来那么多事儿。
你似乎没搞清楚，一般情况下，所有 remote 上所有（不是以团队成员命名的）公开的 feature branch 的工作是有需要就要准备移交的，从来就不可能完全是“自己的”分支，这样的分支上历史出偏差是要负责任的。而真正所谓“自己”的分支，要么是提前约好的专用分支，要么干脆是不 push 都随便的本地分支（当然，不算在工作量里），本来想怎么搞就怎么搞。
还有，你的“最新的代码合到自己分支上继续开发”“尽早解决冲突”的做法根本没法保证“冲突应该会很少”；即便冲突真的不多，历史也可能因为到处非 ff 的 merge 整个乱了。
原则：只要是往上 push 的东西，就应该清楚这些工作会影响到别人的 base。对应地，自己到底依赖的是什么 base 分支也必须清楚（这不只是管理的要求，不守规矩可能自己这边重现 bug 都可能呵呵），而且除非你自己保证负责 squash 掉，否则就不应该无脑尽早解决——要是你依赖的 base 更新了再回退，难道你这里还非得多 merge 几次才更好看？搞清楚你的历史 merge 后也会进被合的分支里。不要搞得 push 完到处意义不明的 merge，让别人看不下去再替你 rebase 浪费时间。