Question

我之前从未遇到过这种情况，因为Git一直认为重命名的文件在我的经验中被添加/删除，但我们在repo中生成了基于repo中另一个文件的修改的文件（它最初由其他人以这种方式设计，我们决定在重组的回购中使用它，并且它正在考虑将这些文件的每次新迭代重命名为＆＃34; （97％相似度）即使旧文件被完全删除并且创建了新文件（其自身的文件名部分基于校验和）。

我们正在使用BitBucket来合并拉取请求，现在尝试合并分支变得很痛苦，因为它认为在添加或删除文件时，合并两侧都有文件重命名。

对此有任何解决方案吗？

Answer 1

Git实际上无法识别文件重命名，它也不关心它。 Git所做的是跟踪完整存储库的内容。如果您修改文件，添加文件或删除文件，Git只需获取存储库的另一个独立快照并为其创建提交。

一些瓷器工具，即最终用户通常使用的那些命令，确实具有识别文件重命名的概念。或者至少，他们试图检测它。由于Git没有重命名的概念，他们只能做好猜测。为此，他们对内容进行了比较。如果之前的文件内容与之后的文件内容类似，则会将其视为重命名或副本（如果原始文件仍然存在则复制）。

但这实际上只是一个视觉辅助工具，可以帮助您确认您的行为，以防您真正执行合并。毕竟，如果重命名整个文件夹，实际上是删除了该原始文件夹中的所有文件，并添加了新文件夹中的所有文件。至少这是Git所看到的以及它所追踪的内容。但是对于查看更改的用户来说，看到文件都保持不变并且只是移动到新路径会更有帮助。

底线是你不需要关心这个。这只是Git为您提供的前端工具的一个指标。它对Git实际上做了什么没有任何影响，并且无论是重命名还是文件被删除并在其他地方读取，它都没有区别。

Answer 2

如何合并重命名或类似的文件？

您还可以尝试-Xrename-threshold=X降低重命名相似性检测阈值。

git merge ... -Xrename-threshold=<20> 
// Where 20 is the % of similarity in files

diff.renameLimit
    The number of files to consider when performing the copy/rename
    detection; equivalent to the git diff option -l.

merge.renameLimit
    The number of files to consider when performing rename detection
    during a merge; if not specified, defaults to the value of
    diff.renameLimit.

来自git help merge（也在git help pull中）：

rename-threshold=<n>
    Controls the similarity threshold used for rename detection.
    See also git-diff(1) -M.

来自git help diff：

-M[<n>], --find-renames[=<n>]
    Detect renames. If n is specified, it is a threshold on the
    similarity index (i.e. amount of addition/deletions compared to the
    file’s size). For example, -M90% means git should consider a
    delete/add pair to be a rename if more than 90% of the file hasn’t
    changed.

Git认为添加/删除的文件已重命名为

2 个答案:

如何合并重命名或类似的文件？