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

【问题标题】：Why would a commit in git updated files but not shown those files?为什么 git 中的提交会更新文件但不显示这些文件？
【发布时间】：2018-03-07 16:10:35
【问题描述】：

我们遇到过这样的情况，开发人员进行了一次提交，更改了两个文件（在提交中显示），但实际上更多的文件被更改了。 IE。我们可以查看上一个提交中的文件，查看一些内容，然后查看有问题的提交中的同一个文件并且该文件不同（缺少内容），但该文件没有显示为更改了违规提交。这怎么可能？

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

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

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

我检查了父母（在 GitHub 中），它表明我期望作为父母的两个提交是父母。然而，我也开始怀疑，如果我跟着父母走得够远，我们就会遇到问题。我最终使用 SourceTree 来查看树枝......哇......看起来就像地震后的洛杉矶免费系统。

明显的原因是违规提交基于开发分支中的一个非常旧的提交，正如 Mark Adelsberger 所建议的那样。我没有确认，但很确定提交者在谷歌上搜索到足以使用 -f 开关。

我还发现了一个稍后的提交，它确实显示了对文件的更改。我很确定另一个开发人员然后从现在的 fubared 分支进行了合并，然后更新了他们提交中的所有这些文件。他们显然没有查看他们提交的文件，并注意到更改的文件不是 3 个，而是 60+。现在事情正在理顺。

【问题讨论】：

标签： git github

【解决方案1】：

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

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

2) 不存在提交 A 与其父提交 P 不同的过程，其方式未显示为 A 的补丁中的更改。这是因为提交始终存储为项目的快照，并且更改（“补丁”）是通过检查提交及其父项来计算的，因此在几乎数学层面上，声称这种情况是没有意义的。

所以假设你所说的一切都是准确的，并且只改变你暗示/显然假设的事情，最合理的解释是 y 不是 x 的父提交。

可能发生的一种情况是，如果创建 x 的开发人员位于单独的分支上（可能是在 A 之前创建的分支）：

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

在这种情况下，您可以简单地将分支合并到 master。

如果开发人员仍在master（尚未分支）上，但尝试在不拉动的情况下进行推送，并且在出现错误时响应

，则可能会意外进入非常类似的状态>

git push -f

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

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

和其他试图拉取master 的开发人员应该会出错，因为master 以一种意想不到的方式移动。

在这种情况下，我会让创建 x 的开发人员执行以下操作来清理它：

首先，在x 创建一个新分支并推送它。那么

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

其中是提交 ID 或解析为提交 y 的其他表达式。（如果您正在检查提交 y，那么您必须使用这样的表达式来查找它。）

然后你会回来

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

并且可以将branch 合并到master 中（或者将branch 重新设置为master，然后快进master，如果您愿意的话）。

【讨论】：