虽然作为Git的核心，Git管道不会跟踪重命名，但如果你愿意，你用Git日志“瓷器”显示的历史可以检测它们。

对于给定的git日志，请使用-M选项：

git-log-p-M

使用当前版本的Git。

这也适用于其他命令，如gitdiff。

有一些选项可以使比较更严格或更不严格。如果您在重命名文件的同时不对文件进行重大更改，则Git日志和好友可以更容易地检测到重命名。出于这个原因，有些人在一次提交中重命名文件，在另一次提交时更改文件。

每当你要求Git查找文件被重命名的位置时，CPU的使用都是有成本的，所以你是否使用它，何时使用，都取决于你。

如果您希望始终在特定存储库中报告具有重命名检测的历史记录，可以使用：

git-config diff.renames 1

检测到文件从一个目录移动到另一个目录。下面是一个示例：

commit c3ee8dfb01e357eba1ab18003be1490a46325992
Author: John S. Gruber <JohnSGruber@gmail.com>
Date:   Wed Feb 22 22:20:19 2017 -0500

    test rename again

diff --git a/yyy/power.py b/zzz/power.py
similarity index 100%
rename from yyy/power.py
rename to zzz/power.py

commit ae181377154eca800832087500c258a20c95d1c3
Author: John S. Gruber <JohnSGruber@gmail.com>
Date:   Wed Feb 22 22:19:17 2017 -0500

    rename test

diff --git a/power.py b/yyy/power.py
similarity index 100%
rename from power.py
rename to yyy/power.py

请注意，无论何时使用diff，这都是有效的，而不仅仅是使用gitlog。例如：

$ git diff HEAD c3ee8df
diff --git a/power.py b/zzz/power.py
similarity index 100%
rename from power.py
rename to zzz/power.py

作为一次尝试，我在功能分支中的一个文件中做了一个小修改，并提交了它，然后在主分支中我重命名了该文件，提交了，然后在文件的另一部分中做了小修改并提交了该文件。当我转到功能分支并从master合并时，合并重命名了文件并合并了更改。以下是合并的输出：

 $ git merge -v master
 Auto-merging single
 Merge made by the 'recursive' strategy.
  one => single | 4 ++++
  1 file changed, 4 insertions(+)
  rename one => single (67%)

结果是一个工作目录，重命名了文件，并对两个文本进行了更改。因此，Git有可能做正确的事情，尽管它没有明确跟踪重命名。

这是对一个老问题的迟来回答，因此其他答案可能在当时的Git版本中是正确的。

可以重命名文件并保持历史记录不变，尽管这会导致文件在存储库的整个历史记录中被重命名。这可能只适用于痴迷于git日志的爱好者，并有一些严重的影响，包括：

您可以重写共享历史，这是使用Git时最重要的“不要”。如果其他人克隆了存储库，您将通过此操作将其破坏。他们将不得不重新克隆以避免头痛。如果重命名足够重要，这可能是可以的，但您需要仔细考虑这一点——您可能会扰乱整个开源社区！如果您在存储库历史记录的早期使用文件的旧名称引用了该文件，那么实际上就是在破坏早期版本。为了解决这个问题，你必须多跳一点环跳。这不是不可能的，只是乏味而且可能不值得。

现在，既然你还和我在一起，你可能是一个单独的开发人员，正在重命名一个完全独立的文件。让我们使用过滤器树移动文件！

假设您要将一个旧文件移动到文件夹目录中，并将其命名为new

这可以用git-mv-old-dir/new&&git-add-u-dir/new来完成，但这打破了历史。

相反：

git filter-branch --tree-filter 'if [ -f old ]; then mkdir dir && mv old dir/new; fi' HEAD

将重做分支中的每个提交，在每个迭代的滴答声中执行命令。当你这样做的时候，很多事情都会出错。我通常会测试文件是否存在（否则它还没有移动），然后执行必要的步骤，按照我的喜好强行插入树。在这里，您可能会浏览文件以更改对文件的引用等等

完成后，文件将被移动，日志将完好无损。你觉得自己像忍者海盗。

而且当然，只有当您将文件移动到新文件夹时，mkdir目录才是必需的。if将避免在文件存在之前创建此文件夹。

Git检测重命名，而不是通过提交持久化操作，因此使用gitmv还是mv并不重要。

log命令采用--follow参数，该参数在重命名操作之前继续历史，即，它使用启发式搜索类似的内容。

要查找完整的历史记录，请使用以下命令：

git log --follow ./path/to/file

我愿意：

git mv {old} {new}
git add -u {new}

git log --follow [file]

将通过重命名向您展示历史。

只需移动文件并使用：

git add .

提交前，您可以检查状态：

git status

这将显示：

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    old-folder/file.txt -> new-folder/file.txt

我用Git版本2.26.1进行了测试。

从GitHub帮助页中提取。