使用Git处理类重命名（例如使用Resharper完成）的最佳方法是什么？
也就是说，如果类名和包含文件名一起更改并提交而没有进一步更改。
似乎Git通过改变启发式百分比来处理重命名的方式有点受打击。 对于大类，它将被识别为重命名，但对于小类，达到百分比阈值，以便将其视为删除和添加。
答案 0 :(得分：8)
请记住，在Git的历史记录中，文件重命名不存储为“这已从X重命名为Y”。相反，文件X存在于一个版本中，并且在下一个版本中存在Y（而X不存在）。例如：
Revision | Files ---------+---------------------------------- HEAD^ | a.cpp x.cpp z.cpp HEAD | a.cpp y.cpp z.cpp
在上图中，每个修订版都是一行，每行包含三个文件。在两次修订之间，x.cpp已重命名为y.cpp。存储库存储的唯一信息是每个单独修订的内容。
当Git（或其他读取Git存储库的工具）查看上述历史记录时，会注意到y.cpp是HEAD中的新文件。然后，它会查看上一个修订版，以查看是否存在类似的文件。在直接文件重命名的情况下，则是，在先前版本中存在具有相同内容的名为x.cpp的文件（并且在当前版本中不再存在）。因此，新文件显示为从x.cpp到y.cpp的重命名。
在重命名和修改的情况下，Git将查看先前版本的文件以查看一个文件是否看起来接近新文件（就其内容而言）。这是启发式的用武之地。如果大多数行是相同的，那么Git会将它显示为重命名，但如果有足够的更改行与未更改的行相比，那么Git只会说它看起来像一个新文件。
要回答您的问题，处理resharper类重命名的最佳方法是简单地执行此操作并提交新文件。 Git将旧文件和新文件存储在其存储库中。在您实际询问历史记录时，稍后会处理重命名检测。这就是git log等命令具有--find-copies和--find-copies-harder等选项的原因。
答案 1 :(得分：0)
几年后，我仍然认为这是一个怪癖，因为它是git工作方式的基础。
我现在要做的是重命名，提交，然后进行更改。重构工具有点烦人，但是没有其他解决方案可以保留历史记录（--find-copies和--find-copies-harder似乎不起作用）。