在我的例子中，我将两个文件从“resources”目录移动到“src/main/resources”。如下代码所示，它们显示为“已删除”。

然而，在我将重新定位的文件添加到临时区域，然后添加删除的文件后，系统将它们识别为“重命名”。

当我检查这两个文件的历史记录时，它是完整的，它们的永久链接仍然有效。所以，一切都如我们所愿。

myaddress (master *)$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    resources/myaddress-schemas.sql
        deleted:    resources/select-sangdo-ro-60.sql

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        pom.xml
        src/

myaddress (master *)$ git add src/main/resources/*.sql
myaddress (master *+)$ git add `git ls-files --deleted`

myaddress (master +)$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    resources/myaddress-schemas.sql -> src/main/resources/myaddress-schemas.sql
        renamed:    resources/select-sangdo-ro-60.sql -> src/main/resources/select-sangdo-ro-60.sql

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        pom.xml
        src/main/java/
        src/main/webapp/

myaddress (master +)$
myaddress (master +)$ git commit -m "two resource files moved to src/main"
[master 0832839] two resource files moved to src/main
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename {resources => src/main/resources}/myaddress-schemas.sql (100%)
 rename {resources => src/main/resources}/select-sangdo-ro-60.sql (100%)
myaddress (master)$

首先，只需重命名即可创建独立提交。

然后，对文件内容的任何最终更改都将放在单独的提交中。

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

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

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

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

要重命名目录或文件（我不太了解复杂的情况，因此可能需要注意）：

git filter-repo --path-rename OLD_NAME:NEW_NAME

要在提到目录的文件中重命名目录（可以使用回调，但我不知道如何）：

git filter-repo --replace-text expressions.txt

expressions.txt是一个充满了文字：OLD_NAME==>NEW_NAME等行的文件（可以将Python的RE与regex一起使用，也可以将glob与glob一起使用）。

要重命名提交消息中的目录，请执行以下操作：

git-filter-repo --message-callback 'return message.replace(b"OLD_NAME", b"NEW_NAME")'

Python的正则表达式也受支持，但必须用Python手动编写。

如果存储库是原始的，没有远程，则必须添加--force以强制重写。（在执行此操作之前，您可能需要创建存储库的备份。）

如果不想保留引用（它们将显示在GitGUI的分支历史记录中），则必须添加--replace-refs delete no add。

git log --follow [file]

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

No.

简短的答案是否定的。在Git中重命名文件并记住历史是不可能的。这是一种痛苦。

有传言说，git log--follow--查找副本会更加困难，但这对我来说不起作用，即使文件内容没有任何更改，而且这些移动都是用git mv完成的。

（最初，我使用Eclipse在一次操作中重命名和更新包，这可能会混淆Git。但这是一件非常常见的事情。--如果只执行mv，然后提交mv，并且mv不太远，那么follow似乎确实有效。）

Linus表示，您应该全面了解软件项目的全部内容，而不需要跟踪单个文件。不幸的是，我的小脑袋无法做到这一点。

这么多人无意识地重复了Git自动跟踪移动的说法，这真的很烦人。他们浪费了我的时间。Git没有这样做。根据设计（！）Git根本不跟踪移动。

我的解决方案是将文件重命名回其原始位置。更改软件以适合源代码管理。使用Git，您似乎只需要第一次“获取”它。

不幸的是，这打破了Eclipse，它似乎使用了--follow。gitlog--follow有时不会显示具有复杂重命名历史的文件的完整历史记录，尽管gitlog会显示。（我不知道为什么。）

（有一些过于聪明的黑客会重新开始旧的工作，但它们相当可怕。请参阅GitHub Gist:emiller/git mv with history。）

简而言之：如果Subversion这样做是错误的，那么Git这样做也是错误的——这样做不是什么（错误！）功能，这是错误的。