我们遇到过这样一种情况：开发人员进行了提交，更改了两个文件（显示在提交中），但实际上还有更多文件被更改了。即我们可以查看上一次提交中的文件，查看一些内容，然后查看违规提交中的同一文件，该文件不同（缺少内容），但该文件未显示为在违规提交中发生了变化。这怎么可能？
我们假设违规提交的开发者在推送和推送旧版本之前没有提取，但我希望看到所有意外更改的文件以及所需的更改。由于我没有看到这些变化，我想知道是否还有其他事情发生。
以下是我们所看到的（仅针对一个包含更改但未提交的文件）
我在GitHub中查看提交历史记录。单击commit并显示已更改的文件。在违规提交中，列出了两个文件。但是，再次在GitHub中，如果比较违规提交和先前提交之间的问题文件（查看提交时浏览文件按钮），则会更改违规提交中列出的 文件。
我检查了父母（在GitHub中）并且它表明了我期望的两个承诺，因为父母是父母。然而，我也开始怀疑，如果我跟着父母走得太远，我们就会遇到问题。我最终使用 SourceTree 查看分支......哇......在地震发生后看起来像洛杉矶自由系统。
明显的原因是违规提交是基于开发分支中的一个非常旧的提交，正如Mark Adelsberger所建议的那样。我没有确认，但很确定提交者用Google搜索足以使用-f开关。
我还发现了一个后来的提交，它确实显示了对文件的更改。我很确定另一个开发者然后从现在的fubared分支进行合并，然后在他们的提交中更新所有这些文件。他们显然没有看到他们提交的文件，注意到有3个文件改变了，而不是60+。事情现在正在理顺。
答案 0 :(得分：1)
由于您没有指定导致结论的确切命令和输出，因此无法得出许多明确的结论。但是，我可以保证两件事：
1）正常尝试推送而不拉动将不擦除已经推送的更改;它会产生错误。在分布式开发中，这种情况一直发生，所以如果它导致更改被删除，那么git首先不会是一个可行的版本控制系统。 （处理该错误的错误程序看起来大致与您所看到的一样;但我会回过头来看。）
2）没有一个程序，其中提交A与其父提交P的不同之处在于未显示为A补丁中的更改。这是因为提交总是存储为项目的快照，并且通过检查提交及其父项来计算更改（＆＃34;补丁＆＃34;），因此在几乎数学水平上声明这样的情况是没有意义的。
因此，假设您所说的一切都是准确的，并且只改变您暗示/显然假设的内容，最合理的解释是y不是x的父提交。 }。
可能发生的一种方式是，使x的开发人员在一个单独的分支上（可能是在A之前创建的分支）：
o -- A -- o ... o -- y <--(master)
\
x <--(branch)
在这种情况下，您可以简单地将分支合并为主。
如果开发人员仍然在master（没有分支），但是试图在不拉动的情况下推动，并且在呈现时，可能意外地进入非常类似的状态错误已回复
git push -f
这将执行＆＃34; force push＆＃34;，它可以删除分支历史记录中的提交。它不应该是任何人的常规工作流程的一部分，并且通常被配置服务器禁止。结果将在服务器上
o -- A -- o ... o -- y
\
x <--(master)
和其他尝试提取master的开发人员应该会收到错误，因为master已经以意想不到的方式移动。
在这种情况下，我让创建x的开发人员执行以下操作来清理它：
首先，在x创建一个新分支并推送它。然后
git checkout master
git reset --hard *<ID-of-commit-y>*
git push -f
其中＆lt; ID-of-commit-y＆gt; 是提交ID或解析为的其他表达式，提交y。 （如果您正在检查提交y，那么您必须使用这样的表达式来查找它。）
然后你会回到
o -- A -- o ... o -- y <--(master)
\
x <--(branch)
并且可以将branch合并到master（或将branch重新合并到master然后快进[{1}}，如果您愿意的话）。