是否可以在 Git 中移动/重命名文件并维护其历史记录？

Question

我想重命名/移动 Git 中的项目子树，将其从

/project/xyz

到

/components/xyz

如果我使用普通的git mv project components ，那么xyz project所有提交历史都会丢失。 有没有办法移动它以保持历史？

Answer 1

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

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

http://git-scm.com/docs/git-log

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

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

Answer 2

不。

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

有传言说git log --follow --find-copies-harder会起作用，但它对我不起作用，即使文件内容的更改为零，并且已使用git mv进行了移动。

（最初我使用 Eclipse 在一个操作中重命名和更新包，这可能让 Git 感到困惑。但这是一件非常常见的事情。如果只执行mv然后执行commit和mv --follow似乎确实有效不会太远。）

Linus 说你应该全面了解软件项目的全部内容，而不需要跟踪单个文件。 好吧，可悲的是，我的小脑袋无法做到这一点。

真的很烦，这么多人漫不经心地重复了 Git 自动跟踪移动的说法。 他们浪费了我的时间。 Git 不做这样的事情。 按照设计（！）Git 根本不跟踪移动。

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

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

（有一些太聪明的 hack 会返回并重新提交旧工作，但它们相当可怕。请参阅 GitHub-Gist： emiller/git-mv-with-history 。）

简而言之：如果Subversion 这样做是错误的，那么 Git 这样做也是错误的 - 这样做不是某些（错误！）功能，而是一个错误。

Answer 3

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

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

现在，既然你还和我在一起，你可能是一个重命名一个完全隔离的文件的独立开发者。 让我们使用filter-tree移动文件！

假设您要将old文件移动到文件夹dir并将其命名为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

将重做分支中的每个提交，在每次迭代的刻度中执行命令。 当你这样做时，很多事情都会出错。 我通常会测试该文件是否存在（否则它尚未移动），然后执行必要的步骤以根据我的喜好硬拔树。 在这里，您可以通过文件 sed 来更改对文件的引用等。 把自己打昏！ :)

完成后，文件被移动并且日志完好无损。 你感觉像一个忍者海盗。

还; 当然，只有将文件移动到新文件夹时才需要 mkdir 目录。 if将避免在历史记录中创建此文件夹早于您的文件存在。

Answer 4

git log --follow [file]

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

Answer 5

我愿意：

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

Answer 6

我想重命名/移动 Git 中的项目子树，将其从

/project/xyz

到

/组件/xyz

如果我使用普通的git mv project components ，那么xyz项目的所有提交历史都会丢失。

否（8 年后，Git 2.19，2018 年第三季度），因为 Git 会检测目录 rename ，现在有更好的文档记录。

请参阅提交 b00bf1c ， 提交 1634688 ， 提交 0661e49 ， 提交 4d34dff ， 提交 983f464 ， 提交 c840e1a ， 提交 9929430 （2018 年 6 月 27 日），以及提交 d4e8065 2018 年 6 月 2018 年 6 月 2018 日cdrenja 提交 d4e8062 （ 新人 18 cdrenja 2 提交 18 cdren newren
^{（由Junio C gitster合并-- gitster -- in commit 0ce5a69 ，2018 年 7 月 24 日）}

现在在Documentation/technical/directory-rename-detection.txt ：

例子：

当所有x/a 、 x/b和x/c都移动到z/a 、 z/b和z/c ，很可能同时添加的x/d也希望移动到z/d提示整个目录“ x ”移动到“ z ”。

但它们还有许多其他情况，例如：

历史的一侧重命名x -> z ，另一侧将一些文件重命名为x/e ，导致合并需要进行传递重命名。

为了简化目录重命名检测，这些规则由 Git 强制执行：

目录重命名检测适用时的几个基本规则限制：

1. 如果给定目录在合并的两侧仍然存在，我们不认为它已被重命名。
2. 如果要重命名的文件的子集有文件或目录妨碍（或将相互妨碍），“关闭”这些特定子路径的目录重命名并向用户报告冲突.
3. 如果历史的另一侧将目录重命名为您的历史侧重命名的路径，则忽略来自历史另一侧的特定重命名以进行任何隐式目录重命名（但警告用户）。

您可以在t/t6043-merge-rename-directories.sh看到很多测试，其中也指出：

• a) 如果重命名将目录拆分为两个或多个其他目录，重命名次数最多的目录“获胜”。
• b) 避免对路径进行目录重命名检测，如果该路径是合并任一侧的重命名源。
• c) 仅当历史的另一侧是进行重命名的人时，才对目录应用隐式目录重命名。

Answer 7

是的

1. 您可以使用git log --pretty=email将文件的提交历史转换为电子邮件补丁
2. 您在新目录中重新组织这些文件并重命名它们
3. 您可以使用git am将这些文件（电子邮件）转换回 Git 提交以保留历史记录。

局限性

• 不保留标签和分支
• 历史在路径文件重命名（目录重命名）时被剪切

---

用例子一步一步解释

1.以电子邮件格式提取历史记录

示例：提取file3 、 file4和file5历史记录

my_repo
├── dirA
│   ├── file1
│   └── file2
├── dirB            ^
│   ├── subdir      | To be moved
│   │   ├── file3   | with history
│   │   └── file4   | 
│   └── file5       v
└── dirC
    ├── file6
    └── file7

设置/清理目的地

export historydir=/tmp/mail/dir       # Absolute path
rm -rf "$historydir"    # Caution when cleaning the folder

以电子邮件格式提取每个文件的历史记录

cd my_repo/dirB
find -name .git -prune -o -type d -o -exec bash -c 'mkdir -p "$historydir/${0%/*}" && git log --pretty=email -p --stat --reverse --full-index --binary -- "$0" > "$historydir/$0"' {} ';'

不幸的是，选项--follow或--find-copies-harder不能与--reverse结合使用。 这就是为什么在重命名文件时（或重命名父目录时）历史会被删除的原因。

电子邮件格式的临时历史记录：

/tmp/mail/dir
    ├── subdir
    │   ├── file3
    │   └── file4
    └── file5

Dan Bonachea建议在第一步中反转 git log 生成命令的循环：不是每个文件运行 git log 一次，而是在命令行上使用文件列表运行一次，并生成一个统一的日志。 这种方式修改多个文件的提交在结果中保持单个提交，并且所有新提交保持其原始相对顺序。 请注意，在（现在统一的）日志中重写文件名时，这也需要在下面的第二步中进行更改。

---

2.重新组织文件树并更新文件名

假设您想在另一个仓库中移动这三个文件（可以是同一个仓库）。

my_other_repo
├── dirF
│   ├── file55
│   └── file56
├── dirB              # New tree
│   ├── dirB1         # from subdir
│   │   ├── file33    # from file3
│   │   └── file44    # from file4
│   └── dirB2         # new dir
│        └── file5    # from file5
└── dirH
    └── file77

因此重新组织您的文件：

cd /tmp/mail/dir
mkdir -p dirB/dirB1
mv subdir/file3 dirB/dirB1/file33
mv subdir/file4 dirB/dirB1/file44
mkdir -p dirB/dirB2
mv file5 dirB/dirB2

您的临时历史记录现在是：

/tmp/mail/dir
    └── dirB
        ├── dirB1
        │   ├── file33
        │   └── file44
        └── dirB2
             └── file5

更改历史记录中的文件名：

cd "$historydir"
find * -type f -exec bash -c 'sed "/^diff --git a\|^--- a\|^+++ b/s:\( [ab]\)/[^ ]*:\1/$0:g" -i "$0"' {} ';'

---

3. 应用新历史

你的另一个回购是：

my_other_repo
├── dirF
│   ├── file55
│   └── file56
└── dirH
    └── file77

从临时历史文件中应用提交：

cd my_other_repo
find "$historydir" -type f -exec cat {} + | git am --committer-date-is-author-date

--committer-date-is-author-date保留原始提交时间戳（ Dan Bonachea的评论）。

你的另一个回购现在是：

my_other_repo
├── dirF
│   ├── file55
│   └── file56
├── dirB
│   ├── dirB1
│   │   ├── file33
│   │   └── file44
│   └── dirB2
│        └── file5
└── dirH
    └── file77

使用git status查看准备推送的提交量:-)

---

额外技巧：检查仓库中重命名/移动的文件

要列出已重命名的文件：

find -name .git -prune -o -exec git log --pretty=tformat:'' --numstat --follow {} ';' | grep '=>'

更多自定义：您可以使用选项--find-copies-harder --reverse或--reverse完成命令git log 。 您还可以使用cut -f3-和cut -f3- complete pattern '{.* => .*}'删除前两列。

find -name .git -prune -o -exec git log --pretty=tformat:'' --numstat --follow --find-copies-harder --reverse {} ';' | cut -f3- | grep '{.* => .*}'

Answer 8

我遇到了“在不丢失历史记录的情况下重命名文件夹”的问题。 要修复它，请运行：

$ git mv oldfolder temp && git mv temp newfolder
$ git commit
$ git push

Answer 9

重命名目录或文件（我对复杂情况了解不多，所以可能会有一些警告）：

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

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

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

expressions.txt是一个文件，里面充满了像literal: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以强制重写。 （在执行此操作之前，您可能希望创建存储库的备份。）

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

Answer 10

我按照这个多步骤过程将代码移动到父目录并保留历史记录。

第 0 步：从 'master' 创建一个分支 'history' 用于保管

第 1 步：使用git-filter-repo工具重写历史记录。 下面的这个命令将文件夹 'FolderwithContentOfInterest' 移动到一个级别并修改了相关的提交历史

git filter-repo --path-rename ParentFolder/FolderwithContentOfInterest/:FolderwithContentOfInterest/ --force

第 2 步：此时 GitHub 存储库丢失了其远程存储库路径。 添加远程参考

git remote add origin git@github.com:MyCompany/MyRepo.git

第 3 步：在存储库上拉取信息

git pull

第四步：连接本地丢失分支和源分支

git branch --set-upstream-to=origin/history history

步骤 5：如果出现提示，解决文件夹结构的合并冲突

第 6 步：推！！

git push

注意：修改后的历史记录和移动的文件夹似乎已经提交。 enter code here

完毕。 代码移动到父目录/所需目录保持历史完整！

Answer 11

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

对于给定的git log使用 -M 选项：

git log -p -M

使用当前版本的 Git。

这也适用于git diff等其他命令。

有一些选项可以使比较或多或少严格。 如果您重命名文件而不同时对文件进行重大更改，则 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 时都有效，而不仅仅是使用git log 。 例如：

$ 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 版本可能是正确的。}

Answer 12

首先创建一个仅重命名的独立提交。

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

Answer 13

只需使用以下命令移动文件和舞台：

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 帮助页面。

Answer 14

我移动文件然后做

git add -A

将所有已删除/新文件放入存储区。 这里git意识到文件被移动了。

git commit -m "my message"
git push

我不知道为什么，但这对我有用。