java - 移动到新包后，IntelliJ 将 GIT 存储库的文件标记为未跟踪

Question

当我在 IntelliJ 2017.3 中对托管在 git 存储库上的 Java 项目进行重构时

1. 创建一个新包
2. 将现有的跟踪和提交的 Java 类移至 IntelliJ recipe 之后的新包中

这些 Java 类变成红色(即未跟踪的文件)而不是绿色(跟踪和修改的文件)。如果我提交，我会丢失文件的整个历史记录，并且注释会报告我是第一个提交的人。

我的重构是错误的还是 IntelliJ 的错误？有什么方法可以正确移动文件吗？

Answer 1

首先我们来谈谈 git，因为问题就从这里开始。

在 git 中，不存在“移动”文件这样的事情。当您更改文件的包时，您就更改了它在文件系统上的位置；但对于 git 来说，这意味着你在一个地方删除了文件，并在另一个地方创建了一个新文件。

有时 git 会报告文件已移动或重命名。如果它发现(1)一个文件消失了，(2)另一个文件出现了，(3)它根据可配置的指标(基于新文件内容与旧文件内容相同的程度)确定这可能是为了移动单个文件......然后它说文件已移动。但内心并不相信；它只是试图帮助您理解事物。

并且如果 git 报告文件已移动，那么其他命令可能至少可以选择跟踪文件移动历史记录。例如，git Blame(用于注释文件的命令)确实尝试遵循“整个文件重命名”(根据文档)。

现在，您说手动移动文件效果更好，但让 IDE 由于更改包而移动文件效果不佳。最可能的原因是文件内容在移动时的同一提交中发生了显着更改。对于包更改重构，我们知道至少有一个小的内容更改；但您可能希望在同一提交中尽量减少对文件的其他更改。

如果 git 不相信文件移动，那么 git mv 是什么？这是一种简写，在新位置创建文件，同时从旧位置删除文件(正如 git 所见)并暂存这些更改。它不会使 git 更有可能(或更少)成功地理解文件已重命名；它只是稍微自动化了这个过程。请注意，如果您在没有 git mv 的情况下移动文件，它将显示为“已删除文件”和“未跟踪文件”直到您暂存更改>，此时重命名检测将启动。

因此，当您“手动”移动文件时，您可能正在使用 git mv ，或者正在使用 IDE(它正在使用 git mv > 或等效命令)。 但是当您进行重构时，该操作可能不够智能，无法确保更改已暂存，因此它看起来有所不同。尽管如此，一旦更改被暂存并提交，无论是否使用 IDE 的重构工具来移动文件，效果都将是相同的。 (同样，对于特定文件，此行为可能取决于内容更改的数量。)