Question

似乎对Eclipse git插件进行了一些崩溃和事后的恢复，导致合并提交未获得大多数应该合并的更改。

如果我在Gitlab中检查提交，则看到的文件更改远远少于我的预期。我假设基本分支的未更改文件被错误地添加到了提交中，而不是合并分支中的较新文件中。

不幸的是，这是所有几次提交（以及其他合并），并已推送到中央Gitlab存储库。

如何重新评估合并并检查实际发生的情况？我想我可以

git checkout <pre-merge-commit-hash>
git checkout -b experimental_new_merge
git merge <original-merge-branch>

重新进行合并，然后

git checkout master
git merge experimental_new_merge

将固定文件恢复为主文件。但是我认为稍后会导致许多合并冲突需要手动解决，因为合并涉及的某些文件也会有新的更改。一个很大的目标是检查完整性，而不仅仅是节省我再次进行更改的时间。

有办法避免这种情况吗？一种与旧分支再次合并的方法（现在只会说：已经是最新的）。或者以某种方式将较新的提交/合并重播到该实验分支上，然后将其重命名为母版？

A
|
A2
| \
A3  B
| \  \ 
A4  C  B2
|    \   \
F    C2   B3
| \    \    \
A6  D   C3  B4

Answer 1

您可以通过其哈希ID检出提交A6，从而导致“分离的HEAD”：

git checkout <hash of commit A6>

（您可以使用git checkout -b为这个分离的HEAD赋予新的分支名称。）现在，您可以运行git merge <hash-of-commit-D>进行 new 合并，只需像F：

...--A6--M   <-- HEAD
      \ /
       X
      / \
...--D---F--A4--...

您现在可以将新合并提交M的内容与旧合并提交F的内容进行比较，以查看合并是否正确完成。

如果不是，您有许多个选项可以修复问题；最好使用哪种取决于您的情况。一种简单的方法是将更正（F-vs-M的结果）应用于树以提交A并提交结果：

git checkout <your-branch>  # back to commit A
git diff <hash-of-F> <hash-of-M> | git apply

如果git diff产生的补丁不适用，请考虑使用-3 / --3way启用三向合并，或使用--reject应用适合的部件，然后手动解决拒收的零件。