复制Git工作区后git reset --hard耗时过长，如何提速？

问题现象 #

当Git工作区无变更时，git reset --hard执行速度很快，但将工作区复制到新目录（或从文件服务器下载工作区）后，同一命令耗时大幅增加：

# 原仓库执行（CaseA），耗时约80ms
$ git clone https://android.googlesource.com/platform/cts -b main
$ cd cts
$ git reset --hard

# 复制后仓库执行（CaseB），耗时约6000ms
$ cd ..
$ cp -a cts cts2
$ cd cts2
$ git reset --hard

根因分析 #

Git在执行git reset --hard时，会通过以下逻辑判断是否需要更新工作区文件：

1. 对比index与目标commit的文件差异
2. 检查工作区文件的修改时间（mtime）和文件大小是否与index中记录的一致
   • 若一致，Git直接信任文件内容未变更，跳过内容校验
   • 若不一致，Git会读取每个文件的内容并计算哈希值，与index中的哈希对比，这个IO密集型操作在大量文件（如27000个）场景下会导致耗时剧增

复制/下载操作会更新所有文件的mtime（即使内容未变），同时.git/index文件的内部记录也会因复制过程发生变更，导致Git需要对所有文件做内容校验，这就是CaseB变慢的核心原因。

解决方法 #

方法1：更新index匹配工作区时间戳

执行以下命令同步index与工作区的mtime记录：

git update-index --refresh

该命令会遍历工作区文件，更新index中对应文件的mtime和大小记录，使其与工作区一致。之后再执行git reset --hard，Git会跳过内容校验，速度恢复到CaseA的水平。

方法2：复制/下载时保留文件时间戳

如果是通过命令行复制，确保使用保留文件元数据的参数：

• cp命令：使用-p（保留权限、所有权、时间戳）或-a（归档模式，包含-p）
• rsync命令：添加-t参数保留mtime
• 文件服务器下载：选择支持保留原文件时间戳的下载方式

保留mtime后，工作区文件的时间戳与原仓库一致，index中的记录仍有效，git reset --hard无需额外校验。

方法3：重建index文件

删除旧的index文件并让Git重新生成：

rm .git/index
git reset

git reset会基于当前HEAD重新构建index，新index会使用工作区文件的最新mtime。之后执行git reset --hard即可恢复快速执行。

验证 #

在CaseB场景下，先执行上述任一方法，再运行git reset --hard，耗时会降至与CaseA相近的水平。

内容的提问来源于stack exchange，提问作者HirokiGotoh