不确定这是否是您遇到的问题，但听起来很像。Git 不跟踪文件，而是跟踪其内容。例如，如果您移动文件。使用git status您会看到一个文件已被删除，并且有一个新的未跟踪文件。
如果您将两个更改都添加到提交中，git 将检查它们的内容并假定文件已被重命名。哪个好。您甚至可以复制文件并添加它，因为内容相同，它会将其标记为副本。每个文件将在内部指向相同的Object. 这意味着副本或移动的文件将继承历史记录。
现在假设，在提交期间，您删除了提交的文件并在合并期间将其添加回来。（这可能是丢弃更改发生的情况）。Git 将看到该文件已被删除，然后创建了一个新文件。由于该文件在上一次提交中不存在，因此它会将其标记为新的，这是完全正确的。
另一个可能的原因是新文件有 100% 的更改。我不能肯定地说，但如果它发生了。如果 git 可能认为该文件已被新文件替换，我不会感到惊讶。
在旁注中，我建议git blame对标记为新的文件做一个。这将为您提供具有该名称的文件的更改。如果在每一行上，只有一个人和一个日期。这可能意味着该文件确实是新文件，并且 github 没有错误地将文件标记为新文件。如果有变化，那么 github 有问题。
如果还不算晚，我会考虑重做合并。如果没有新的东西被推送到合并的树中，那么修复它并不是一件可怕的事情。进行合并时，请确保将所有更改添加到变更集中。在合并期间，冲突文件不会被添加到暂存区。我不能说 mergetool 会自动将合并的文件添加到暂存中。无论如何git add {file}，对所有这些文件执行 , 。如果文件已经存在，它不会改变任何东西。一旦你确定一切都是正确的。推它。您可能会遇到一个错误，即您尝试推送将覆盖提交的非快进提交。如果它不起作用，请尝试使用“git push -f”。它应该工作。