可以重命名文件并保持历史记录不变，尽管这会导致文件在存储库的整个历史记录中被重命名。这可能只适用于痴迷于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将避免在文件存在之前创建此文件夹。

Yes

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

限制

未保留标记和分支路径文件重命名（目录重命名）时剪切历史记录

---

用示例逐步解释

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

示例：提取文件3、文件4和文件5的历史记录

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 hard不能与--reverse组合使用。这就是为什么重命名文件（或重命名父目录）时会剪切历史记录。

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

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

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

---

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

--提交日期是作者日期，保留原始提交时间戳（Dan Bonachea的评论）。

您的其他回购现在是：

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

使用gitstatus查看准备推送的提交数量：-）

---

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

要列出已重命名的文件，请执行以下操作：

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

更多自定义：您可以使用选项--find copies hard或--reverse完成命令gitlog。还可以使用cut-f3-和grepping完整模式“｛.*＝>.*｝”删除前两列。

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

我想重命名/移动Git中的项目子树/项目/xyz到/组件/xyz如果我使用普通的gitmv项目组件，那么xyz项目的所有提交历史都会丢失。

没有（8年后，Git 2.19，2018年第3季度），因为Git会检测到目录重命名，现在已经有了更好的记录。

参见Elijah Newren（Newren）提交的提交b00bf1c、提交1634688、提交0661e49、提交4d34dff、提交983f464、提交c840e1a、提交9929430（2018年6月27日）和提交d4e8062、提交5dacd4a（2018年7月25日）。（于2018年7月24日由Junio C Hamano（吉斯特）在提交时合并）

现在在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强制执行：

当应用目录重命名检测：

如果合并的两边仍然存在给定的目录，我们不认为它已被重命名。如果要重命名的文件的子集有一个文件或目录在其中（或将相互妨碍），请“关闭”这些特定子路径的目录重命名，并向用户报告冲突。如果历史的另一端将目录重命名为您的历史的另一侧重命名的路径，那么对于任何隐式目录重命名，忽略历史另一端的特定重命名（但警告用户）。

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

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

只需移动文件并使用：

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帮助页中提取。

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

步骤0:从“master”创建了分支“history”以进行安全保管

步骤1：使用gitfilter 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

步骤4：将本地丢失分支连接到源分支

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

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

第6步：推！！

git push

注意：修改的历史记录和移动的文件夹似乎已提交。在此处输入代码

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

git log --follow [file]

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