【问题标题】:How to squash a merge commit with a normal commit?如何用普通提交压缩合并提交?
【发布时间】:2018-06-01 23:15:57
【问题描述】:
commit b0e5db36ed68d4562275adeb08001b1316a4da52
Merge: ea38baa 8220bb1

commit ea38baa3f46a48722987b8dd3892d2b8d81c4d1a

在这种情况下,我如何压缩这两个提交

我正在使用

git rebase -i HEAD~2

但这不起作用,因为它删除了合并提交并且不可用于压缩

【问题讨论】:

  • '请帮忙。'每次我读到这篇文章时,我的喉咙里都会发生一些事情......我将此问题标记为重复:stackoverflow.com/questions/30136558/…
  • 显然 not 是“如何压缩中间有合并提交的提交”的副本,因为这个问题是关于如何用合并提交本身压缩 。 (要明确:相同的 answer 可能有效,但它不是同一个问题,搜索此问题的人不太可能找到另一个问题并认为这是解决方案。)
  • 我会说“不要”,但也许如果你告诉你为什么需要你应该做的其他事情

标签: git github merge commit squash


【解决方案1】:

正如公认的答案所说,git rebase -i(又名--interactive)支持附加选项-p(又名--preserve-merges)。但是,与公认的答案不同,我想指出,这实际上似乎可以很好地达到预期的结果,因此如果您这样做 git rebase -i -p HEAD~2 合并提交将出现在交互式 rebase 文件中:

pick abcdeff Merge branch 'feature' into develop
pick abcdefc Extra changes

现在您可以编辑此 rebase 文件以标记第二次提交以进行压缩并完成 rebase。一切似乎都很好。

但是,我不明白为什么 git 文档 warns against using using -i -p 的复杂性(并且在某些但不是所有版本的文档中说 -p 已弃用)所以你的里程可能会有所不同。似乎主要问题出现在尝试重新排序使用此时显示的提交时......所以不要这样做!

已弃用的-p 选项的推荐替代方案似乎是git rebase -i -r;但这会产生一个非常长且复杂的交互式 rebase 文件,它看起来与我所期望的完全不同(即上面显示的简单 rebase 文件)。

如果有人可以添加一个答案,详细解释 git rebase -i -p 在这种情况下是否以及为什么可以(或不),那将非常有帮助。

【讨论】:

    【解决方案2】:

    所以这里要考虑两个因素:

    首先,rebase 在某些方面并不总是能很好地处理合并提交。我会再讨论几次。

    其次,您期望的结果并不完全清楚。如果现在你有类似的东西

    x -- x -- M -- C <--(master)
     \       /
      A --- B
    

    你想结束

    x -- x -- ABC <--(master)
    

    x -- x -- MC <--(master)
     \       /
      A --- B
    

    如果你想要ABC 的版本,这很简单。虽然 M 没有出现在 rebase 的 TODO 列表中,但所有被 M (即在此示例中为 AB)引入主线的提交是。所以只需将BC 标记为“壁球”。唯一要记住的是这是一个历史重写,所以如果你已经推送了任何可以到达ABMC 的引用,那么可能需要进行一些清理(参见rebase 文档在“从上游变基中恢复”下)。

    如果你想要MC的版本,那么问题就很多了。并不是说你不能得到它,但我认为你不能通过rebase 得到它;而且,MC 将是一个“邪恶的合并”,这可能会导致未来的rebase 尝试出现问题(除其他外)。

    默认情况下,rebase 会尝试生成线性历史记录并且不会生成合并提交。您可以使用--preserve-merges 选项让它生成合并提交,但这与-i 的交互效果不佳(如果您尝试通过这样做来修改合并,我预计可能会出现几个问题)。

    如果你不担心在合并提交中隐藏更改的问题,并且真的想产生像MC 这样的提交,那么这样做的方法是:

    首先,将master 引用移回M,同时将C 的更改保留在索引中。

    git checkout master
    git reset --soft HEAD^
    

    然后将更改直接重新应用到合并提交

    git commit --amend
    

    【讨论】:

      猜你喜欢
      • 2021-03-26
      • 2015-07-20
      • 2016-05-22
      • 1970-01-01
      • 2023-01-12
      • 2018-11-05
      • 2023-02-23
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多