共计 738 个字符，预计需要花费 2 分钟才能阅读完成。
问题描述
线上项目有一个小 bug，我修改了 xx.js 中的一行代码解决了问题，然后 webpack 打包，准备提交代码。
git add .
git status
这时候我发现，git status 的输出为：
renamed: xx.1.js -> xx.2.js
我发现这不太对啊：renamed 虽然可以体现出来 webpack 打包的时候改掉文件名 hash 值这个重命名的过程，但不能体现我改了文件内容啊。
我觉得应该这样输出才对：
deleted: xx.1.js
new file: xx.2.js
于是开始找答案，看为什么和我想的不一样。
问题解决
搜了一圈，最终有些收获，结论先行：
git 把文件标为 renamed 的意思是并不是很具体的指这个文件重命名了。他是一个泛指，这是一个种所谓 heuristic(启发式，不懂不懂)的用法。
关于这个问题没有找到足够的资料，但是通过我的测试，发现：
一个文件的改动的行数低于总行数的 50% 的，并且进行重命名操作就会出现这种被标为 renamed 的情况
测试方法如下：
a.txt，里面内容为 0 -99 的数字，每个一行，共 100 行。
把这个文件做 commit
重命名 a.txt 为 b.txt
删除 49 行内容，然后做 add 操作，然后做 git status 操作
删除 50 行内容，然后做 add 操作，然后做 git status 操作
删除 51 行内容，然后做 add 操作，然后做 git status 操作
同时在找资料的时候我也尝试了下面两个链接里提到的方式，但是在我的版本 (2.19.2.windows.1) 都没有成功复现。
参考文档
git status shows rename but it’s incorrect
What’s git’s heuristic for assigning content modifications to file paths
