这是一个创建于 2035 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 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