为什么git中的提交会更新文件，但不会显示这些文件？

我们遇到过这样一种情况：开发人员进行了一次提交，更改了两个文件（如提交中所示），但实际上更改了更多的文件。也就是说，我们可以查看上一次提交中的一个文件，查看一些内容，然后查看违规提交中的同一个文件，该文件不同（缺少内容），但是该文件在违规提交中没有显示为已更改。这怎么可能

我们假设违规提交的开发人员在推送之前没有拉，并推送了一个旧版本，但我希望看到所有意外更改的文件以及所需的更改。由于我没有看到这些变化，我想知道是否发生了其他事情

下面是我们看到的（仅针对一个有更改但未提交的文件）

• 提交x（冒犯）
  • 提交中更改了2个文件
  • 文件Y没有行Z
  • 文件Y在提交中不显示为已更改的文件
• 提交y（上一个）
  • 文件Y有行Z
  • 文件Y在许多次提交之前更改
• 提交A（5天，可在y之前提交）
  • 文件Y添加行Z
  • 文件Y已提交

更新 我正在查看GitHub中的提交历史记录。单击提交，它会显示已更改的文件。在违规提交中，列出了两个文件。但是，同样在GitHub中，如果您在有问题的提交和上一次提交之间比较问题文件（查看提交时单击“浏览文件”按钮），则会更改未在有问题的提交中列出的文件

我检查了父母（在GitHub中），它指出了我期望的两个承诺，因为父母就是父母。然而，我也开始怀疑，如果我跟随父母走得够远，我们就会遇到问题。最后我用SourceTree查看树枝…哇…看起来像地震后的洛杉矶自由系统

显而易见的原因是，正如马克·阿德尔斯伯格（MarkAdelsberger）所建议的，违规提交是基于开发分支中的一个非常旧的提交。我没有得到确认，但很肯定提交人在谷歌上搜索到了足够多的信息，使用了

-f

开关

---

我还发现了一个后来的提交，它确实显示了对文件的更改。我敢肯定，另一个开发人员从现在的fubared分支进行了合并，然后更新了提交中的所有文件。他们显然没有查看他们提交的文件，注意到不是3个文件发生了变化，而是有60多个文件。现在事情已经解决了。

由于您没有指定导致得出结论的确切命令和输出，因此不可能得出许多明确的结论。但是，我可以保证两件事：

1） 正常尝试在不拉动的情况下推动不会删除已推动的更改；它将生成一个错误。在分布式开发中，这种情况经常发生，因此如果它导致更改被擦除，那么git首先就不是一个可行的版本控制系统。（不过，处理该错误的错误程序可能与您看到的大致相同；我将回到这一点。）

2） 提交A与其父提交p的不同之处在于，没有一个过程不会在A的修补程序中显示为更改。这是因为提交总是存储为项目的快照，而更改（“补丁”）是通过检查提交及其父项来计算的，因此从几乎数学的角度来看，声称这种情况是没有意义的

因此，假设您所说的一切都是准确的，并且只改变您暗示/显然假设的内容，最合理的解释是

y

不是

x

的父提交

一种可能发生的情况是，如果制作

x

的开发人员在一个单独的分支上（可能是在

a

之前创建的分支）：

这将执行“强制推送”，可以从分支的历史记录中删除提交。它不应该是任何人日常工作流程的一部分，而且通常是服务器配置所禁止的。结果将出现在服务器上

o -- A -- o ... o -- y 
 \
  x <--(master)

其中是的提交ID或解析为提交

y

的其他表达式。（如果要检查commit

y

，则必须使用这样一个表达式来查找它。）

然后你会回到我身边

o -- A -- o ... o -- y <--(master)
 \
  x <--(branch)

---

o--A--o。。。o--y那么，您是说命令：
git diff^不向控制台打印任何内容？在git中，您不能先推后拉。您是否正在GitHub上查看提交更改？还是在你的终端上？
o -- A -- o ... o -- y 
 \
  x <--(master)

git checkout master
git reset --hard *&lt;ID-of-commit-y&gt;*
git push -f

o -- A -- o ... o -- y <--(master)
 \
  x <--(branch)