重命名/移動修改后的文件后，Git 不跟蹤歷史記錄

Question

問題：我需要更改存儲庫中整個目錄的位置。 為此，我使用git mv ，如果需要，我將包含頭名稱更改為當前正確的名稱。 問題是當我在一次提交期間采取兩項行動時。 在這種情況下，文件歷史記錄丟失（git 認為這是刪除和創建新文件）。

解決方法：如果我將這些操作拆分為單獨的提交，則不會發生該問題。

問題再次出現：但是，即使我使用上述解決方案，在與 master 合並期間問題仍然存在。 我有義務只使用 no-ff 合並。 在這種情況下，對 master 分支的新提交是由兩個提交和...的更改組成的。無論如何，歷史記錄都沒有正確跟蹤。

另一個丑陋的解決方法：我可以將這些提交單獨交付給 master。 我無法提供不可編譯的代碼，但如果我將其排除在構建過程之外，它可能是可行的......但它很丑陋而且錯誤......

我想知道是否有更好的解決方案來解決這個問題。

Answer 1

如果您熟悉幾乎所有其他版本控制系統 (VCS)，則可能很難理解 Git 對文件歷史做了什么。

事實是，Git不會有文件歷史記錄。 它在這里的 VCS 中可能是獨一無二的（盡管我對許多更神秘的 VCS 沒有經驗）。 它的近親 Mercurial確實有文件歷史記錄：添加到 Mercurial 的每個文件都會在 Mercurial 稱為manifest的文件中分配一個唯一的編號，這決定了文件的身份。 如果您更改一個文件的名稱——或者一個充滿文件的整個目錄——它們會保留它們的身份，因為這些信息存在於清單中。

Git 完全摒棄了這個概念。 Git 根本沒有文件歷史記錄。 Git 只有commits 。

每個提交都存儲一個源樹的完整快照。 每個提交也有一定數量的父提交，通常只有一個。 這更像傳統的基於提交的 VCS：可以跟蹤各種提交，或查看文件歷史記錄。 但是由於 Git 沒有文件歷史記錄，它唯一擁有的就是提交歷史記錄。

為了實現git log --follow和其他有用的項目，Git 提供的不是文件歷史記錄，而是重命名檢測。 Git 可以查看任何一個特定的提交，並將該提交與其父提交進行比較——或者對於合並提交，與它的所有父提交進行比較。 當它進行這種比較時，它提供了檢測通過該提交重命名的文件的選項：在父級中具有一個名稱但在子級中具有不同名稱的文件。 ¹

在比較兩個任意提交時，Git 甚至提供這種重命名檢測，而不僅僅是父子提交。 跑步：

git diff --find-renames $hash1 $hash2

比較兩次提交，並且只要有“ $hash1路徑為a/b/c.txt文件看起來很像$hash1路徑為d/e/f.log的$hash2 ”的$hash2 ，Git 可能會聲稱該文件被重命名（然后也可能被修改）。 不過，重要的是要記住，Git 只是綜合了一種將第一個文件轉換為第二個. 兩次提交中的兩個實際文件以這種方式永久存儲。 它們永遠無法更改：只要這些提交存在，這兩個文件就會以這種方式存儲在這兩個提交中。 這兩個文件實際上根本不相關，除非您希望它們是. Git 通過比較它們的相似性來“尋找”重命名。 給 Git 一組不同的“相似性”標准——例如， -M75%而不是-M50% ——Git 可能會選擇一組不同的“足夠相似”的文件。

任何提交都沒有發生任何事情。 他們都被時間凍結了。 但是使用一組不同的“重命名閾值”值、“中斷閾值”等，Git 可能會配對不同的路徑名。 鑒於--no-renames ，Git 永遠不會配對不同的路徑名（盡管它仍然會配對具有相同名稱的文件）。

（這種動態重命名檢測很重要， git diff --find-rename在合並時很重要，因為合並運行兩個git diff --find-rename操作，從合並基礎提交到正在合並的兩個分支提示提交中的每一個。如果 Git 找到了rename，它相信。如果沒有找到rename，它認為在tip中刪除了base文件，在tip中創建了不同的文件。您可以控制rename閾值，但不能設置break或copy閾值，至少在今天的 Git 版本中是 2.15。）

---

¹這是什么意思是合並提交不太清楚，因為有多個父：這是什么意思文件child.txt有過的名字p1.txt在父母＃1和p2.txt父＃2？ 傳統的 VCS 以其獨特的內部編號系統確定文件身份，在這里分配了明確的含義，但在實踐中，這種含義並不總是有用的，Linus Torvalds 在這里選擇完全取消這個概念，可能已經在部分反應。

Answer 2

您可以將--follow選項設置為git log命令的默認值：

git config --global log.follow true