这是一个创建于 1782 天前的主题，其中的信息可能已经有所发展或是发生改变。
开发团队中同一个人，因为同时开发多个需求或者 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 年 2 月 28 日  1 如果两个 MR 是相互独立的，最好的办法是从 master checkout 出第二个 MR 的分支，这样第二个 MR 就不会包括第一个 MR 的内容了。 如果第二个 MR 依赖第一个，那要么等第一个 merge 了再开第二个要么 target branch 就应该是第一个 MR 的分支，等 merge 了再改 target branch 。 |
 | 2 mxalbert1996 2021 年 2 月 28 日 via Android 1 正确的工作流程难道不应该是每个需求或 BUG 都从 master 切出一个新的分支开发么？ |
 | 3 guog 2021 年 3 月 1 日 via Android 1 不要分别 push，只需要 push 到对应修复 bug 的分支或者此 feature 分支，其他的分支自行 Cherry pick |
 | 4 jinliming2 2021 年 3 月 1 日 2 一楼说的对，如果独立，则每次都应该从 master 的最新代码切出分支来开发，而不是基于上一次提交。 如果不独立，新提交依赖旧提交，那此时旧提交还在 review 过程中，如果代码不合格，出现 require change，那么此时代码可能还会发生变化，后续的提交如果基于这个提交来的话就会出现问题。所以新提交的 MR 应当标记为 WIP，等待旧提交完成 review 后确定 merge 之后，再 rebase 到最新代码解决冲突，然后再去掉 WIP 标记开始 review 。 |
Select Language