【问题标题】:git rebase interractive before merge with conflict与冲突合并之前的 git rebase 交互
【发布时间】:2021-11-09 11:37:21
【问题描述】:

我正在尝试从必须解决冲突的合并之前修改提交(特别是,我想在合并之前将新提交压缩为一个,但仅重写提交消息会导致相同的问题)。

当我使用时:

git rebase -i --rebase-merges SHA~1

我必须再次解决合并的冲突,这真的很耗时,我不明白为什么会再次出现冲突。

有没有办法在合并之前修改提交而不必再次解决冲突?

【问题讨论】:

    标签: git merge rebase git-merge-conflict


    【解决方案1】:

    一个常规的 rebase 复制提交,就好像使用(或有时字面意思是)git cherry-pick,并且每个cherry-pick 操作一个合并。 --rebase-merges rebase 副本通过对使用较早的樱桃挑选步骤所做的旧提交的新副本重新执行合并来进行合并。因此,如果有 47 个原始提交要复制,其中 3 个是合并,那么 git cherry-pick 将有 44 个机会产生合并冲突,git merge 将有 3 个机会产生冲突。

    如果您之前有过冲突,那么您很可能会再次遇到相同的。在这里,git rerere 会很有帮助。有谈论在未来的 Git 版本中默认打开它。在那之前,由于您已经进行了一些合并,请考虑使用rerere-train:参见Smarter rebase avoiding redundant work? 另请参见What is git-rerere and how does it work?

    【讨论】:

      猜你喜欢
      • 2019-07-16
      • 2011-12-16
      • 1970-01-01
      • 1970-01-01
      • 2011-12-19
      • 1970-01-01
      • 1970-01-01
      • 2018-07-15
      • 1970-01-01
      相关资源
      最近更新 更多