混乱的合并和还原后，特定文件中的Git历史记录和文件更改丢失

发生了什么：

His Commit #4 
    |        \
    |          \  
    |            \
    |             |
    |        My Commit #2
    |             |
    |        My Commit #1
    |             |
His Commit #3     |
     \           /
        \      /
          \ /
 Common Ancestor Commit

我向师父做了两个承诺

---

一位同事后来向master作出了两次承诺，作为发布的一部分。他有一些合并问题，他不确定，做了一些未指明的恢复，然后设法推动。他绝对没有做过一次git的推力器

Git现在处于一种奇怪的状态：

如果我做git日志，那么我可以看到我的提交，但是如果我对他们更改的文件做git日志，我就看不到他们。编辑：@Cupcake建议在带有-full history标志的文件上运行git日志。当我这样做时，我可以看到“丢失”提交

我的更改不在主分支的提示中，但相关文件上没有显示任何更改的提交

在“His提交4”中，没有显示正在更改的文件

在gitk中，我按照提交的时间顺序对提交进行了编号：

His Commit #4 
    |        \
    |          \  
    |            \
    |             |
    |        My Commit #2
    |             |
    |        My Commit #1
    |             |
His Commit #3     |
     \           /
        \      /
          \ /
 Common Ancestor Commit

git show[His commit 4 hash]的输出：

git diff[His commit 4][My commit 2]的输出：

---

看起来他的提交4是一个合并提交，它不添加他的更改，而取消还原您的更改。有什么方法可以验证吗？我原以为一个恢复了更改的合并提交会有一个它所做的恢复列表附在它上面git show{his commit 4 SHA}的输出是什么？他有一些他不确定的合并问题，做了一些未指定的恢复。。。你不能指望人们根据这些模糊的信息来解决你的问题，是吗？为什么不让你的同事再做一次合并，或者你帮他做合并呢？这样，您至少可以确切地看到正在采取的步骤。还要记住，git log默认情况下会简化历史记录，如果您想查看文件的完整历史记录，有时需要使用git log-full history。然而，如果在这种情况下你不得不依赖它，你应该把它作为一个信号，也许你应该重新进行合并，这样你就不必为了验证合并是正确的而跳过所有这些障碍。

<Small code change made in His Commit #3>

<All of my changes from My Commit #1, My Commit #2 and His Commit #3>