@skankhunt42 @cookygg
场景一：a.txt 里面有 500 行代码，现在有个新功能 b.txt ，和 a.txt 功能完全一致，就只用改某一行的几个字

场景二：a.txt 里面有 2000 行代码，现在要把里面后半部分 1000 行拆分到 b.txt 里，拆分出来的代码新文件要有原来的历史记录

我算是看明白了.
假设 a 文件是 1 年前创建的,有 100 条修改记录.

OP 想的是,根据 a 文件复制出一个 b 文件来.同时在 git 中可以看到 b 文件也是 1 年前创建的,也有这 100 条修改记录.

这不是造假么...

你想让「文件 b 」和「文件 a 」具备一样的历史记录，不仅仅是内容的拷贝。我觉得`git`应该无法满足你这个奇怪的需求，这相当于是“伪造”了「文件 b 」的历史记录（仿佛开启了月报宝盒）。

如楼上的几个答案所说，这和“版本控制”的理念是矛盾的。

@whoosy @xubingok “伪造” “造假”
比如：新文件 b.txt 提交的时候会有新建文件的记录，显示是从 a.txt 复制。就像 mv 一样 显示从 a.txt 改名 新文件名可以看到以前的老文件名记录

维护一下这个记录很难的嘛🙏

https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904

基本原理是：

- blame 在 merge commit 处会追踪文件来自各个 parents 的部份。
- 让文件 a 和 b 来自 merge 的两个 parents 。
- 让文件 a 来自更早的 a 。
- 仍文件 b 来自更早的 a 。

我的做法和 Raymond Chen 不一样，假设当前在 branch "current":

1. 重命名当前文件

git checkout -b copy
git mv a _
git commit -m 'Prepare to copy file.'

2. 把当前文件在第一个分支上恢复为原来的名字

git checkout -b copy1
git mv _ a
git commit -m 'Restore name of file.'

3. 把当前文件在另一个分支上重命名为副本的名字

git checkout -b copy2 copy
git mv _ b
git commit -m 'Copy file.'

4. 合并两个修改

git checkout copy
git merge --no-ff -m 'Finish copying file.' copy1 copy2

5. 回归原分支

git checkout current
git merge --no-ff -m 'Copy `a` to `b`.' copy

6. 删除中间分支

git branch -d copy copy1 copy2

@magggia #9
@mercury233 #10
@mangoDB #19
见 #22

@xubingok #17 这当然不是造假，考虑各种变种需求：文件拆分成两个，希望各自保留历史；两个文件合并，希望保留各自的历史。

@Trim21 #21 模糊识别重命名确实有这个问题，但是 Git 的原理保证：如果一个 commit 里面只发生不同内容文件的重命名（没有内容修改、没有多个同内容文件重命名），那么历史可以正确用 blame 追溯。（不满足此条件则会有模糊匹配的问题，所以我给文件改名的时候都是一个 commit 只做改名一件事的。）

本身 git 的哲学就是“保持历史真实性”，你这个需求就是“篡改历史”

相违背了。

@xiangyuecn #15 ，mv 是重命名啊，怎么到你这边就变成删文件+新建文件了……
基于“文件”进行操作，给这个 mv 操作添加到对应文件的 commit 历史中。

git-mv - Move or rename a file, a directory, or a symlink
[Git - git-mv Documentation]( https://git-scm.com/docs/git-mv)

如果按照 OP 你的意思，其实复制出来一个 b 文件。但对于你来说是知道这个文件是基于 a 文件复制出来的，但是对于 git 来说 b 文件单纯只是没有被追踪过的一个新文件。
所以你的实际操作是新增一个 b 文件，同时去按照 a 文件的编辑历史造 b 文件的整个历史，而不是共享整个历史。

@codehz #34 ，识别到 rename 是猜。但是如果猜到了，那么提交历史里面是会有标注是 rename ，而不是 add 。

```
diff --git a/test.xt b/test2.xt
similarity index 100%
rename from test.xt
rename to testTT.xt
```

@xiangyuecn #37 git cp 很难成立，原因：git mv 和 git rm 都不产生 commit ，而是修改 index 等，因此基于一致性，git cp 也应该不产生 commit 而只是修改 index ；但是 git 数据库里面每个 commit 存的是状态，而不是“怎么来的”，因此要让 git blame 认识到一个文件是另一个的副本，要么 git blame 自动检测（见下一段），要么这个信息必须存在于 commits 的历史中，用多分支的做法就是把这个信息存放在历史中，这必然要创建多个 commits ，因此 git cp 不会这样做。

目前的实现里，如果一个 commit 的惟一变化是有一个新文件 B ，并且新文件 B 和某个已经存在的文件 A 内容一样，那么 Git 会认为新文件是“手工重新写出来的”，不会认为 B 来自于 A 。我觉得这样设计的原因是很多配置文件可能确实会是内容上一样的，但更可能是基于不同的原因分别写出来的，所以不宜合并历史。

git mv 也并不保证 git blame 会认为移动前后的文件有关联性，这种信息依然是 Git 通过对比两个 commits 算出来的。

@dfkjgklfdjg #38 ，随便建了一个 test 文件，rename 的时候顺手加了个 TT 。回复的时候感觉好像改成 test2 更合适。就手动改成了 2 ，但直接发出来了，后面的 to 还没改掉。

😂 将就看吧。

@dfkjgklfdjg #30 git mv 和删除文件再新建没有任何区别。你在 #38 也说了，Git 是猜的，但

>但是如果猜到了，那么提交历史里面是会有标注是 rename

这是错误的，commits 里不会标注为 rename ，只有计算 diff/blame 的时候 Git 才会去（根据 commits 的内容）识别重命名关系。

GIT_AUTHOR_DATE=$(date -d'2012-12-12 01:00:01') GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" git commit -m '2012 init'

git 本身倒是确实支持随意设置提交时间（和提交人），但 git log 的顺序还是按实际顺序的，除非 merge

git 的优点就是能改历史。但是楼主这题有地触碰到 git 的短板了。

（爬了楼，什么狗屁哲学和理念，就是 Torvalds 随手写的一个工具）

@lnbiuc @63 “欢迎 fork 此仓库，就叫 xiangyuecn-git 如何” 不感兴趣，欢迎提点有建设性的意见。

对于源码管理，一个复制的文件，文件本身是有来源的也有历史记录，但 git 没法简单做到这个复制，这本身就是少了点什么

在本地文件目录里面，直接复制一个新文件改改提交，使用场景中规中矩，可能很多时候不会去在意这个历史记录而已

没记错的话 hg 和 svn 都是会复制文件历史。这是个非常实用的功能。

没想到某些 git 用户也有饭圈行为啊，一遇到自家没有的功能，就开始扯什么“理念”“造假”。不过能说出这些话的我估计也不是什么正儿八经的用户。

文件更名就是删除+添加。git 能追溯，是在看到 diff 并发现删除+添加这样的行为以后，去手动关联起两个文件的历史轨迹。至于为什么复制不能追溯，这个不是 git 本身的局限，而是 git 客户端（也就是 git 软件）的局限，这些软件只会在删除+添加的时候匹配文件，不能在纯添加的时候匹配文件。
要实现这个功能，不是改 git 协议/数据库，而是要改 git 客户端。你用什么客户端，你就得改什么客户端，或者另外自己去实现这个功能。而且这个更改只有用改过的客户端才能看到，别人用他们自己的客户端照样看不到。

至于为什么大多数（或者所有）客户端不实现这个功能，多半是因为计算量太大了。原本是在删除和添加的文件里做文字匹配，现在变成了所有文件和添加的文件去做匹配，假如你 git 库里有 10 万个文件，现在添加了 1 个新文件，不就要做 10 万次匹配？性能就跟不上了。

@baiyi 哈哈哈哈我也是想表达类似的观点

我估计 op 把楼上所说的“造假”理解成了一种批评，但这里说的造假只是出于 git 版本控制的出发点，历史记录是不应该被伪造的，所以 git 当然不会提供这种便捷的操作来让你伪造提交记录

但既然这些东西都是存在于文件系统，那当然会有解法，只是会麻烦一点

git log --follow 新文件

显示新文件的提交记录，包括新文件重命名之前的提交记录。

相比于 --follow 你还可以用 --follow --follow ，甚至是显式地使用 --find-copies 甚至是 --find-copies-harder ，此时你可能还需要考虑使用 -l 和 --combined-all-paths 等等

显然你自己不会去翻文档的，也不会理解 git 如何工作，对吗

@zhuisui #79 翻文档也得找到到地方，时间成本太高，前几天问 deepseek ，给的解决方案太复杂
实际压根什么都不需要做就能解决，前提是要知道怎么规避会产生影响的地方，完事

上面还有个让我 fork git 源码，自己实现这个功能😂

@xiangyuecn #78 我不确定为什么你认为 TortoiseGit 能识别 = 这是一个 Git 的基本操作。TortoiseGit 并不是 Git 。如果你期待的是存在一个基于 Git 的工具可以识别，提问的时候应该说清楚，你的答案是 TortoiseGit 的基本操作，而非 Git 的基本操作。

使用 merge 反复重命名的方法可以确保 Git 本身可以识别，这一点在你需要远程查看 git blame 的时候十分重要——毕竟没法要求 GitHub 远程帮你运行 TortoiseGit 。

@geelaw #86 测试结果来看，git 本身是支持类似 git cp 的命令的，就是提交的时候 人为的保证复制的新文件和老文件内容一致，提交上去，外行人来看他们就自动的关联到了一起了。修改新文件再提交就没有这个效果

跟用的 git 命令、还是 TortoiseGit 图形界面，在这个功能上是没有区别的

cp mv 这种应该是属于同一类基本操作，要是 git 以前能明确显式的支持 cp 命令，后面这个修改复制的文件后再提交导致的不能关联的问题，也就会不存在了

> 跟用的 git 命令、还是 TortoiseGit 图形界面，在这个功能上是没有区别的

> cp mv 这种应该是属于同一类基本操作，要是 git 以前能明确显式的支持 cp 命令，后面这个修改复制的文件后再提交导致的不能关联的问题，也就会不存在了

纯粹瞎猜，显然没看我贴得几个选项的描述，所以认为这就是 git 设计出来能很容易支持的东西。
其实这个需求 git 支持是很麻烦的，而且有很多问题的，包括可靠性和性能。
根本就不是所谓 git 基础的能力，既高级，又需要谨慎使用，又有很多限制。

“注意不要改复制的文件就行”

指的是不要改 a.TXT?

Steps:
1. mv a.txt b.txt
2. git commit -am
3. vim b.txt
4. git commit -am

第一次 commit 让 git 知道你只做了 rename ，然后历史就接上了，第二次 commit 做你认为的差异内容，历史就连上了。试试

@quqiu #91 复制的新文件 b.txt 第一次提交前，不要修改内容，提交前要保持和老文件 a.txt 一致，提交后就能关联到 a.txt 的历史记录。如果修改了不一致就会关联不上，目前测试结果是这样的

老文件 a.txt 也可以修改，修改后再复制出 b.txt ，只要提交时，两个文件内容一致，提交后就能关联上

@zhuisui #88 我也不知道是哪里的问题

“比如已有 a.txt ，我现在要个 b.txt 。 如何复制出 b.txt 这个文件，并且复制前的历史和 a.txt 保持一致？”

这句是主题里面的原文，这段话不清楚是不是有歧义，还是需求描述不够准确，也没人提这句话有没有毛病😂

@xiangyuecn #87 您似乎没有理解“TortoiseGit 不是 Git”这句话。

你可以自己试试，在 Git 2.42 上

git init
>a.txt echo 1
git add a.txt
git commit -m first
>>a.txt echo 2
git commit -am second
cp a.txt b.txt
git add b.txt
git commit -m copy
git blame b.txt

你会看到 b.txt 的每一行都是 copy 导致的，而不是 first, second 导致的。

现在，为什么 TortoiseGit 会显示 b.txt 来自 a.txt （按照你的说法是这样的，我自己不用 TortoiseGit 所以不知道）。答案是因为 TortoiseGit 会自己读取 Git 的 commit 对象并自己追踪文件，和 git blame 没有任何关系。

Git 不会认为 b.txt 和 a.txt 有相同的历史，至于 TortoiseGit 有自己的解读方式，那是 TortoiseGit 的事情。本质上来说，你自己写一个追踪复制的程序，等价于你用 TortoiseGit ，都和 Git 自带的 blame 解读没有任何关系。

我在 #86 的主要观点有两个：

1. 如果你希望用一个工具自动检查文件复制的情况，应该问“有什么工具能追踪 Git 历史中复制的文件”，而不是“Git 基操：怎么样复制一个文件，能保持历史记录”，因为后者的自然解读是“保持 Git 所认为的历史记录”，即 git blame 的结果。
2. 如果你希望确保 git blame 总是得到你希望的历史（这和其他第三方工具没有任何关系），那么单纯复制 + git add + git commit 是不行的。

这不是本来就支持的吗？不用--follow 啊
```
$ git log -p -- b.txt
commit a7d5f10cfba6f13a2eb09388bd2a941e95bfcb99 (HEAD -> main)
Date:

update b.txt

diff --git a/b.txt b/b.txt
index ce01362..3b18e51 100644
--- a/b.txt
+++ b/b.txt
@@ -1 +1 @@
-hello
+hello world

commit e30f877d34497b41feac93d56d77d5282f8bb257
Date:

add b.txt

diff --git a/a.txt b/b.txt
similarity index 100%
copy from a.txt
copy to b.txt

commit fb7f7cf2ccbd5e488bc21a684414d4c7373f82ab
Date:

first commit

diff --git a/a.txt b/a.txt
new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/a.txt
@@ -0,0 +1 @@
+hello
```
重点是`similarity index 100%`。