【问题标题】:Git merge request to branch which is a source branch of another merge requestGit 合并请求到分支,该分支是另一个合并请求的源分支
【发布时间】:2020-02-17 17:03:01
【问题描述】:

假设我有这样的情况:

    |
   _|
  | task2
 _|
| task1
|
|
master

并且 task1 分支已经在向 master 提出合并请求。然后,我也想合并 task2。我选择目标分支task1 cuz 然后在 MR 上我只能看到那些在 task2 分支上创建的提交,而不是 task1+task2。

所以情况看起来像这样:

  <-|
<--_|
  | task2
 _|
| task1
|
|
master

将task1的请求合并到master,将task2的请求合并到task1。

我的问题很简单。合并这些的正确方法应该是什么?我应该先合并task2-&gt;task1,然后再合并task1-&gt;master,还是应该先合并task1-&gt;master,然后再合并task2-&gt;master

顺便说一句,无论哪个选项是正确的,我会以来自这些分支的独特提交结束吗?唯一的意思是master + task1 + task2,而不是master + task1 + task1的task2 + task2的一部分?

【问题讨论】:

    标签: git branch git-merge


    【解决方案1】:

    我认为 task2 应该要求合并到 master 中,而不是 task1 ......并且正确的合并顺序是第一个 task1,然后是 task 2。如果您在 task1 之前将 task2 直接合并到 master 中,则 task1 将被合并作为 task2 的一部分。

    【讨论】:

    • 我知道我在这里评论了一个 1 年的答案,但是通过这一年,我发现我非常喜欢具有快进合并的线性历史。在这种情况下,我会将 task1 合并到 master。然后 rebase task2 到 master 并合并它。这样我最终将得到我所需要的,我什至不需要(尽管我可以拥有它)指定合并的额外提交。顺便说一句,如果我按照您的建议执行此操作,我将不得不将 task1 重新设置为 master,这会将我的 task1 的提交堆叠在 master 的所有提交之上(co tastk1 + task2),所以我会复制提交
    猜你喜欢
    • 2017-12-02
    • 2013-02-21
    • 1970-01-01
    • 2019-01-04
    • 1970-01-01
    • 1970-01-01
    • 2013-11-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多