Git rebase忽略Merge提交

时间:2018-02-16 08:17:58

标签: git

我想将这四个提交消息压缩成一个。这些变化已被推动。

...95c2f Merge branch 'bugfix/final' of ssh://10.0.0.30:7999/mp/web into bugfix/final
...39e3c Merge branch 'version/I2-0' of ssh://10.0.0.30:7999/mp/web into bugfix/final
...cf444 Merge branch 'version/I2-0' of ssh://10.0.0.30:7999/mp/web into bugfix/final
...43d9d C0-235, CO-236, CO-215, CO-340, CO-367, CO-368 mobile order depth etc,etc...

但如果我尝试使用下面的方法进行变基,则会忽略所有合并提交消息。

git rebase -i HEAD~4

我如何实现相同以及忽略合并提交的原因。

4 个答案:

答案 0 :(得分:4)

Git(2.25.0版本1/13/2020或更早版本)起弃用标志--preserve-merges

Git CLI现在将建议您使用:--rebase-merges-r的缩写

交互式基础的用法示例:

git rebase -i --rebase-merges HEAD~4

查看文档以获取更多信息:

-rebase-merges [=(rebase-cousins | no-rebase-cousins)]

默认情况下,rebase只会从待办事项中删除合并提交 列表,并将重新提交的提交放入单个线性分支中。用 --rebase-merges,rebase会尝试通过重新创建以下内容来尝试保留要重新提交的提交中的分支结构: 合并提交。解决的任何合并冲突或手动修订 这些合并提交必须手动解决/重新应用。

默认情况下,或者指定了no-rebase-cousins时,提交 没有直接祖先将保留其原始分支 点,即git-log [1]排除的提交 --ancestry-path选项将默认保留其原始血统。如果启用了rebase-cousins模式,则改为执行此类提交 重新基于(或,如果指定)。

-rebase-merges模式在精神上与已弃用的模式相似 --preserve-merges,但可与交互式rebase一起使用,在这里可以随意对提交进行重新排序,插入和删除。

当前只能使用来重新创建合并提交 递归合并策略;只能使用不同的合并策略 通过显式exec git merge -s [...]命令。

来源: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---rebase-mergesrebase-cousinsno-rebase-cousins

答案 1 :(得分:3)

您是否尝试过改造并保留合并?假设您希望在重新定位后维护合并提交。

尝试以下方法:

heights = []
num_of_players = len(players)
for idx in len(num_of_players):
if (idx == 0 or idx == num_of_players - 1):
   if (isGoodEnough(players[idx]):
      heights.append(player.height)
else:
   heights.append(player.height)
return height

答案 2 :(得分:0)

合并提交确实没有显示,但它们在那里。必须有一个更清洁的解决方案,但我记得通过重新设置解决了这个问题(例如,您可以尝试推送空提交并使用它进行重新设置),即使未显示合并提交将包含在rebase中

答案 3 :(得分:0)

(在我写这个答案时,你可能会将提交,它们是由哈希ID识别的对象,与提交消息混合在一起,这是您在提交中编写并存储的文本。请将这些单独的概念分开。)

  

我想将这四个提交 消息 压缩成一个。

(强调我的)。但是你想用四个单独的提交做什么?每次提交都会保存一棵树(快照);这四棵树会发生什么?

  

这些变化已被推动。

那么,这四个现有提交的四个提交哈希会发生什么?现在还有其他人使用它们吗?

  

...如果我尝试使用下面的方法进行变基,则会忽略所有合并提交消息。

这是设计的:不可能以任何程度的忠诚来复制合并,而git rebase 意味着“重复git cherry-pick次操作来复制旧的和发霉的承诺闪亮的新改进的“。

git rebase --preserve-merges,它可以尽最大努力复制合并提交。由于这实际上是不可能的,而是重新运行每次合并。如果您在这些合并期间解决了合并冲突,则必须再次解决它们。 1

作为evolutionxbox suggested in a comment,您想要的结果可能是:

  1. 现在使用这四个提交的任何人都是up the creek,被遗弃,没有朋友;很难成为他们。
  2. 我们想丢弃除最后一棵树以外的所有树。
  3. 我们希望最终提交有四个父提交:...43d9d的父级,以及三个合并提交中每个提交的第二个父级。
  4. 如果是这样,您可以通过多种方式实现这一目标,但如果您真的喜欢最终树,最简单的方法是使用管道命令git commit-tree

    如果第3项错误 - 如果想要一堆父提交;如果您想要的是通过执行一系列三个git merge --squash操作(而不是真正的合并),然后是所有四个提交的交互式rebase,您将获得的效果 - 然后还有几种方法可以做到这一点,尽管此时,最简单的方法是再次使用git commit-tree

    使用git commit-tree,告诉Git创建一个新的提交对象,您的树由哈希ID提供,其父项由哈希ID提供,所有这些都在命令行上。 Git在存储库中创建提交对象,并作为命令的输出返回给您新的提交对象的哈希ID。然后,您可以创建或重新设置分支名称以指向新的提交对象。不过,我在这里建议一系列特定的命令,因为它仍然不清楚你真正想要实现的目标。