如何将代码重构为新文件并保留GIT历史记录？ [英] How do I refactor my code to a new file and preserve git history?

问题描述

因此，我希望将大文件的一部分提取到新文件中，并保留git历史记录，这样我就可以运行git blame并像重构之前一样查看更改。

推荐答案

在Git中，历史是提交。没有文件历史记录。这与大多数其他版本控制系统不同：跟踪"文件标识"的那些其他VCS需要您通知它们新文件path/to/new.ext派生自path/to/existing.ext，以便它们可以将新文件的历史记录与旧文件的历史记录相关联。类似地，他们需要您通知他们有关文件重命名的信息-尽管有些，如ClearCase，可以通过简单地充当工作树的文件系统来自动检测重命名。Git不需要任何这些，因为它不是以这种方式工作的。^%1

相反，在Git中，当您将一个提交(称之为a)与另一个(b)进行比较时，Git会尝试(在比较时动态地)发现某个文件a/path/to/name是否与另一个文件b/some/other/path/to/anothername"相同"。比较程度和判定这些是相同文件还是不同文件的算法取决于Git命令。git diff命令从查看实际路径名开始：如果它们相同，则文件相同，²否则，它们可能不同。"可能"部分是重命名检测的用武之地，如果您已经启用它的话。常规git diff还具有-C和--find-copies-harder来启用"文件复制自"检测。使用-C两次(或--find-copies-harder)将设置为查找要从a提交中的任何文件复制的新文件(这被认为成本太高，无法自动执行；通常情况下，只有被认为"已修改"的文件才会被视为副本源候选文件)。

git blame命令略有不同(a和b提交只是自动成为每个提交的父级和子级)，但它仍然有-C选项。它的-C工作方式略有不同：一个-C查找-C从a和b之间修改的文件中复制的行。使用-C两次查找从COMMITa中的任何文件复制的此类行，并使用三个-C标志，它将"更难找到副本"：它将查看每次COMMIT中的每个文件，以查找复制的代码。

因此，在大多数情况下，您只能在git blame上使用一个-C。如果复制的代码来自未修改的文件，则应使用-C -C。如果您认为某些代码在很多转之前就被删除了，然后又复活了，并且您想要找到原始源代码，那么可以使用三个-C。请注意，git blame的-C选项启用git blame的-M选项，该选项检测移动的代码(因此与git diff的-M选项-文件重命名检测完全不同，git log --follow、³始终处于启用状态)。

---

¹与其他VCS相比，这是Git的一个很好的优势，因为Git可以检测人类忘记的情况，还可以在比较"相距很远"的版本时检测重命名。这对Git来说是一个可怕的缺点，因为它必须检测案例，即使人类不会忘记，因此也会错过重命名。这对Git来说是一个很大的优势，因为未来更智能的算法会以更好的方式利用现有的数据。简而言之，为什么它更好，为什么它更糟，这是有争议的，但最终只是不同。

²对于git diff，您可以使用其-B选项有条件地分离这些自动配对的"同名表示相同文件"配对。这对git blame不可用，但对于不进行这种配对的git blame是不必要的。

³由git log中的--follow启用的代码是一个可怕的黑客攻击，基本上只适用于git blame所需的一种情况。请勿尝试将--follow与逆序git log一起使用。

这篇关于如何将代码重构为新文件并保留GIT历史记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！