在 git 存储库中,我有一个分支,我定期在其中合并 master 分支:
A -- B -- C -- D -- E -- F -- G (master)
\ \ \
U -- V -- M1-- X -- Y -- M2 -- Z (feature)
其中
M1
和 M2
提交将 master
合并到 feature
。
我想压缩连续提交
U
和 V
并保留结构的其余部分。
直观地说,应该可以做到这一点,而不必再次解决
M1
和 M2
中的合并冲突,因为通过将 U
和 V
压缩在一起,我不会更改正在合并的工作树的状态通过 M1
,也不是合并基础。
但是,如果我使用
git rebase -i A --rebase-merges
(pick U
后接 fixup V
)执行此操作,我需要再次解决 M1
的合并冲突。
有没有办法指示 Git 重新使用
M1
并按原样进行以下提交?
正如评论中所指出的,git 无法检测到要合并的两个提交碰巧与我们已经知道合并的其他两个提交的文件树处于相同的状态。
Git 的
rerere
工具有助于解决一些合并冲突,但根据我的经验,即使合并与之前的合并完全相同(例如在一侧删除了某些文件),它仍然可能会留下一些未解决的冲突。
但是,可以强制 git 重用先前合并提交的内容。我编写了一个小脚本来帮助解决这个问题,在变基过程(以
--rebase-merges
开始)在冲突合并停止后使用。
如果你处于这样的状态:
$ git status
interactive rebase in progress; onto 123ab26c2a
Last commands done (123 commands done):
pick 3baea80fd Change some files
merge -C bb894b46f main-2 # Merge branch 'main' into feature
(see more in file .git/rebase-merge/done)
...
然后你可以调用这个脚本
reuse_commit bb894b46f
它检查提供的提交是否是合并,并且其父提交与要合并的当前提交具有相同的内容(
HEAD
和MERGE_HEAD
)。如果这些内容匹配,那么它会检索合并提交的内容并使用它来创建新的合并提交(具有相同的元数据)。然后你就可以git rebase --continue
。