这是一个创建于 2424 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2019-04-29 09:04:52 +08:00
描述场景更细化一些。 是两个独立团队。两个团队对业务团队负责。业务（更高第三方，不懂技术）根据事先签署好的协议，分割需求和改进。
当然如果有熟悉整个项目整体的人，负责主框架，那就更好了的。
我是在工作中遇到这方面的问题。所以。。。 谢谢大家集思广益
暂时整理下大家的结论 共 14 个回答
master 负责合并：5 个
谁开发谁合并，谁解决冲突：6 个
谢谢讨论，集思广益
大家相对认可一些的是 在有 master 负责时，专人负责。
没有人负责时，各自负责各自的，保证各自合并到主分支后，项目可用。
谢谢大家
当然如果有熟悉整个项目整体的人，负责主框架，那就更好了的。
我是在工作中遇到这方面的问题。所以。。。 谢谢大家集思广益
暂时整理下大家的结论 共 14 个回答
master 负责合并：5 个
谁开发谁合并，谁解决冲突：6 个
谢谢讨论，集思广益
大家相对认可一些的是 在有 master 负责时，专人负责。
没有人负责时，各自负责各自的，保证各自合并到主分支后，项目可用。
谢谢大家
 | 1 mooncakejs 2019-04-28 10:25:02 +08:00 review 后合并啊。不然就是 master 负责合并，谁开发谁合并会出问题的 |
 | 2 mars0prince 2019-04-28 10:26:43 +08:00 肯定老大合并啊 |
 | 3 maichael 2019-04-28 10:32:30 +08:00 谁开发谁合并，跟直接用一个分支开发有什么区别。 |
 | 4 zizaiv2 OP @maichael @mooncakejs 如果是两个团队呢？ 两个独立团队，各自有互相独立的分支和开发进度。 |
 | 6 yylucifer 2019-04-28 10:45:56 +08:00 review 后合并，谁开发谁在 dev 分支合并； 如果冲突了，谁后提交，谁合并，合并完后应该没冲突，再提交一次 review，review ok 后合到主分支。 |
 | 7 lofbat 2019-04-28 10:46:37 +08:00 1.谁开发谁解决冲突 2.合并到生产分支需要有专人审核&&review |
 | 8 wu67 2019-04-28 10:51:11 +08:00 不是应该专人审核合并吗, 至于冲突, 肯定是谁后来的谁解决冲突. 当然最好的情况是个人改个人的文件, 这样就没毛病了 |
 | 9 TomVista 2019-04-28 10:53:15 +08:00 合并分支要有人审核,再就是合并的几个分支是谁写的,就要坐到一起,看下合并的代码.两个独立团队,必然分支独立互不影响,随便合并(要不就是代码结构,开发体系规划错误,两个独立团队互相调用??干死架构师和 cto) |
 | 10 reus 2019-04-28 11:02:22 +08:00 你说的“合并”是简单 merge 一下，还是解决 conflict ？ 如果有 conflict，那应该 rebase 到最新的，再提交 review review 完再由有权限 merge 的人操作，或者 review 够了自动合并 |
 | 11 passerbytiny 2019-04-28 12:57:25 +08:00 @zizaiv2 #4 同一套代码怎么可能有两个团队？你这明显该拆分成三个项目，其中一个只负责聚合，另外两个一个团队一个。 |
 | 12 9hills 2019-04-28 13:00:15 +08:00 via iPhone 后提交的负责合并，先提交的为王 |
 | 13 SharkIng 2019-04-28 14:04:33 +08:00 一般都是负责人合并，开发者提交 PR 之类的，负责人审核测试后合并，不都这样的么？ |
 | 14 behanga 2019-04-28 17:58:41 +08:00 确实是谁开发谁合并，多团队多分支，都需要合并到主分支，那么进行排队，每个团队合并分支完成后，需确保主分支可以编译。 |
 | 15 mritd 2019-04-29 09:50:19 +08:00 via iPhone 统一由 master 权限者合并，一般是老大，开发分支遵循 gitflow，特殊情况可开启多人 LGTM 模式 |
 | 16 flame90 2019-04-29 11:46:43 +08:00 merge request 了解一下 |
Select Language