这是一个创建于 1393 天前的主题，其中的信息可能已经有所发展或是发生改变。
开发团队中同一个人，因为同时开发多个需求或者 bug 单，本地 push 代码到多个 remote 分支，然后分别 new merge request 到 master 分支，后面 new 的 mr 的 change 里会出现之前 mr 的 commit 信息，会导致 code review 时分不清楚哪些代码的变更是这个 mr 对应 issue 对应的了。
目前最笨的办法是只能先 code review 一个 mr，merge 后，在 new merge request，这样效率太低了，也很难受。
如果允许同时有多个 mr 时，又会导致 code review 时，分不清代码的问题。
请大家帮忙看看，是否有人也有相同的问题，有什么解决方法？谢谢了！
 |
1
zhzy0077 2021-02-28 23:24:43 +08:00  1
如果两个 MR 是相互独立的，最好的办法是从 master checkout 出第二个 MR 的分支，这样第二个 MR 就不会包括第一个 MR 的内容了。
如果第二个 MR 依赖第一个，那要么等第一个 merge 了再开第二个要么 target branch 就应该是第一个 MR 的分支，等 merge 了再改 target branch 。 |
 |
2
mxalbert1996 2021-02-28 23:56:45 +08:00 via Android 1
正确的工作流程难道不应该是每个需求或 BUG 都从 master 切出一个新的分支开发么？
|
 |
3
guog 2021-03-01 00:13:43 +08:00 via Android 1
不要分别 push，只需要 push 到对应修复 bug 的分支或者此 feature 分支，其他的分支自行 Cherry pick
|
 |
4
jinliming2 2021-03-01 00:29:44 +08:00 2
一楼说的对，如果独立，则每次都应该从 master 的最新代码切出分支来开发，而不是基于上一次提交。
如果不独立，新提交依赖旧提交，那此时旧提交还在 review 过程中，如果代码不合格，出现 require change，那么此时代码可能还会发生变化，后续的提交如果基于这个提交来的话就会出现问题。所以新提交的 MR 应当标记为 WIP，等待旧提交完成 review 后确定 merge 之后，再 rebase 到最新代码解决冲突，然后再去掉 WIP 标记开始 review 。 |
Select Language