正式员工挂着实习生的 MR，等自己晚开发的分支合入了再让其解冲突完合入，这是正常现象吗
finnlewis · 2021-06-29 23:28:02 +08:00 · 3908 次点击这是一个创建于 1280 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人实习生，在某大厂实习，已经经历过 3 个不同正式员工要我解冲突，而不是自己解这种事了
具体 timeline 是，不考虑休息日，假设我在第 1 天开始开发需求 1，第 3 天正式员工 A 开始开发需求 2，第 4 天我完成需求 1 提 MR，正式员工 A review 我的 MR 并提出若干建议，当天我完成修改并更新 MR （更新 MR 后 A 会收到消息提醒）。此后我的 MR 状态一直无变化、无新 CR 评论。第 6 天正式员工 A 完成需求 2 并提 MR，当天合入。此时我的 MR 已显示有冲突需要解决。可以认为，这三天我的分支都是在等着正式员工 A 代码合入后再被做出是否合入的决定的。冲突并不会多，我只是好奇为什么在这种情况下，正式员工不偏向于按照正常代码合入顺序来决定该谁解决冲突，而是偏向于让他人代劳。
 |
1
shiji 2021-06-29 23:38:52 +08:00
要不你下次改完了 ping 一下 A 。
我们公司 jira bitbucket 系列的邮件巨多，大部分人要么忽略，要么单独弄个收件夹规则，没到实在没事儿干的情况不会去看里面的邮件。 |
 |
2
jones2000 2021-06-29 23:39:23 +08:00
只能说你们太有钱了, 小公司基本 1 个模块就对应一个人, 每个模块都是单独的文件, 根本就不会涉及到冲突. 除非是项目的工程文件有可能需要合并, 但这些都是很少的. 也不涉及到代码, 都是配置性的东西.
|
 |
3
liprais 2021-06-29 23:49:41 +08:00 via iPhone
解冲突又不难，就解呗
公司不是学校，同事也不是老师 |
 |
4
BrettD 2021-06-29 23:52:32 +08:00
因为你好欺负 :)
|
 |
6
foam 2021-06-30 00:06:14 +08:00 via Android
同 1 楼。下次改完了要往下走的时候，记得 push 下对应的同学，因为别人可能是太忙，忘了。
个人认为，贪图方便让实习生代劳的可能性不大。毕竟新人不熟悉业务，解决冲突的时候，万一把自己刚写的代码给干掉了，就更麻烦了。 |
 |
7
SingeeKing 2021-06-30 00:08:54 +08:00 via iPhone
别多想真的就是单纯没看到… 一天各种乱七八糟通知几十甚至有时候上百封邮件根本看不过来，我都是直接自动归档来自内部 git 通知邮件的
|
 |
8
dayeye2006199 2021-06-30 01:55:55 +08:00  1
只要我的手速够快，冲突就找不上我。
下次记得 ping 一下 reviewer 。还有如果不是功能或者架构性质的意见，（例如只是改改格式，重命名一下函数名之类的没营养的 comment ），建议直接 approve 之后，交给 MR 作者改正更新后直接自行合入。 |
 |
9
allan888 2021-06-30 02:04:59 +08:00
"可以认为，这三天我的分支都是在等着正式员工 A 代码合入后再被做出是否合入的决定的。"
这个应该不是，一般就只是单纯不知道你需要重新 review 而已，像楼上说的，下次改完了记得 ping 一下 A |
 |
10
AntiGameZ 2021-06-30 02:05:51 +08:00
冲突一般都是谁合并的时候发现谁解决吧。你这个事情的特殊之处，是你认为 A 明知道你的 MR 存在并且冲突来自于他的代码。为什么他不和你协调好 merge 顺序，是吗？
|
 |
11
ryd994 2021-06-30 08:37:11 +08:00
1. 正常来说不应该有大量冲突，否则你们架构可能没搞好
2. A 可能就是忙着写码没考虑你的事情 3. 这种情况下你应该找别人 review，而不应该傻等 |
 |
12
glfpes 2021-06-30 09:45:35 +08:00 3
很简单，因为他先 merge 了。
只有一个准则：谁的 MR 与主干冲突，谁自己在 MR 里处理。 至于为啥你的 MR 提交的早却 merge 的晚，那是另外 1 个问题。 |
 |
13
sam90 2021-06-30 10:05:19 +08:00 2
真是戏多, 能沟通解决的事情, 你非要别人来将就你?
|
 |
14
hbin 2021-06-30 12:12:17 +08:00
12 楼说的对，你需要解决的是另一个问题
|
 |
15
mara1 2021-06-30 13:44:33 +08:00
@finnlewis 你说的 MR, 是不是“Pull request”？ 我一直简称“PR", 这就是谁的 PR 有冲突谁解决啊， 你 PR review 完了就赶紧 merge 进去。
|
 |
16
zengxs 2021-06-30 14:02:13 +08:00
@mara1 这个功能在 GitHub，BitBucket 里面叫 Pull request，GitLab 里面叫 Merge Request
一直感觉 Merge request 这个叫法更易懂点。 刚用 GitHub 的时候看着这个 pull request 摸不着头脑，也不知道到底是 request 个啥 😂 |
 |
18
dingyaguang117 2021-06-30 22:50:51 +08:00
赞同 12 楼。 你应该催着把自己的代码先合并了，而不是等着。。
|
 |
19
HankAviator 2021-07-01 01:08:01 +08:00 via Android
冲突的确是谁遇到谁处理，但感觉已有的 mr 最好能占着坑避免同时开发
|
 |
20
MintZX 2021-07-01 01:48:34 +08:00 1
很正常啊，一般分给实习生的任务可能本来就不是很重要。基本上就是能有最好没有也暂时无所谓的。这个时候大家肯定偏向先解决主要问题。
另外一个就是信任问题，实习生一般有一个 mentor 。其他人对实习生没有任何了解，所以一般不倾向给你 approve 。如果你有 mentor 的话，那么一般是你的 mentor 给你 approve，同时他也要承担你代码炸了服务器的后果。 说白了，不是人家故意让你去处理分支冲突，而是一般正式员工根本就不想给实习生 approve 任何代码让他做提交。 |
Select Language