当我在IntelliJ 2017.3中为git存储库上托管的Java项目进行重构时
这些Java类变为红色（即未跟踪文件）而不是绿色（跟踪和修改的文件）。如果我提交，我将丢失文件的整个历史记录，并且注释报告我是第一个提交的。
我是在进行重构错误还是来自IntelliJ的错误？有没有办法正确移动文件？
答案 0 :(得分：2)
首先让我们谈谈git，因为问题从那里开始。
在git中没有“移动”文件这样的东西。更改文件包时，更改其在文件系统上的位置;但是对于git，这意味着你在一个地方删除了文件并在另一个地方创建了一个新文件。
有时git会报告文件已被移动或重命名。如果它看到（1）文件消失，（2）出现另一个文件，并且（3）它基于可配置的度量确定 - 基于新文件内容与旧文件内容相同的程度 - 这可能是为了单个文件的移动...然后它说文件移动了。但在内部却不相信它;它只是试图帮助你理解事物。
如果如果 git报告文件已被移动，那么其他命令可能至少可以选择跟踪文件移动历史记录。例如，git blame（注释文件的命令）确实尝试遵循“整个文件重命名”（根据文档）。
现在，您说手动移动文件效果更好，但是由于更改包而让IDE移动它们的效果很差。最可能的原因是文件内容在与移动相同的提交中发生了显着变化。对于包更改重构，我们知道至少有一个小的内容更改;但您可能希望在同一次提交中最小化对文件的其他更改。
因此，如果git不相信文件移动，那么git mv是什么？它是一种速记，可以在新位置创建文件，同时从旧位置删除它（因为git看到的东西）和会对这些更改进行分阶段。它不会使git更多（或更少）成功地理解文件被重命名;它只是使过程自动化了一点。请注意，如果您移动文件没有 git mv，它将显示为“已删除文件”和“未跟踪文件”，直到您进行更改，点重命名检测将启动。
因此，当您“手动”移动文件时，您可能正在使用git mv，或者您正在使用IDE（使用git mv或等效命令）。 但当您执行重构时， 操作可能不够智能以确保更改已暂存，因此它看起来不同。尽管如此，一旦更改分阶段并提交，无论IDE的重构工具是否用于文件移动，效果都是相同的。 （同样，对于特定文件，此行为可能会受到更改内容的影响。）
答案 1 :(得分：-1)
保留已移动文件的历史记录：
git rm（在执行git status时将其标记为已删除）