把文章檔案改名後，對新路徑跑git log只看到改名那次，以為先前的修改紀錄不見了。先看查詢是不是只按新路徑篩選：較早提交裡檔案還叫舊名字。Git log的–follow可以在單一檔案的歷史查詢裡繼續追過改名，但它不是替所有檔案建立永久身分證。
路徑篩選與完整提交歷史不同
git log --oneline -- new-name.txt這段查的是與new-name.txt路徑相關的歷史，並不是整個儲存庫所有提交。雙連字號把修訂參數與路徑分開，避免同名分支或其他參數混淆。文件如果以前叫old-name.txt，只查新名稱就可能沒有列出舊路徑的變更。
不要為了讓畫面出現舊紀錄，就立刻恢復舊檔名或重新提交。先用只讀查詢核對改名前後的路徑，以及改名提交到底做了什麼。歷史查詢的顯示範圍與檔案是否仍存在，是兩個不同問題。
用純改名案例核對follow
本次使用Git 2.47.1的新隔離儲存庫，沒有遠端，也沒有對產品儲存庫執行命令。先建立old-name.txt並提交，再增加一行與第二個提交，最後只把路徑改成new-name.txt，不修改正文。這讓Git辨認到百分之百相似的純改名，避免把內容大改與改名混在同一次觀察裡。
git mv old-name.txt new-name.txt
git commit -m "rename only"
git log --format=%s -- new-name.txt
git log --follow --format=%s -- new-name.txt只查新路徑時，輸出只有rename only。加–follow後，輸出依序是rename only、edit old file、create old file。三個訊息與新儲存庫實際建立的三個提交對應，不是補寫到log裡的示範文字；案例保存每個命令與原始輸出，可直接核對。
–format=%s在這裡只列提交訊息標題，是為了讓差異容易讀。它不改變要追查的提交集合，也不能單憑相同訊息就證明是同一個提交。真實排查可用–oneline或包含完整hash的格式，將觀察結果與確切提交對上。
確認改名提交，而不是只相信檔名
git show --summary HEAD案例的摘要顯示old-name.txt改成new-name.txt，括號是100%。這代表本次Git的改名偵測結果，把這兩個路徑視為相同內容的改名。它不是說所有未來修改都必然追得回來，也不是Git在每次提交時永遠保存了一個不變的檔案編號。
Git以提交快照與比較來判斷改名關係。若同一次提交既改路徑又大量重寫內容，相似度與偵測設定就可能影響結果。此時先查看實際diff與改名摘要，再決定是否需要調整查詢選項；不能拿這個純改名成功的案例，保證完全重寫的檔案也一定被識別。
git mv會更新工作目錄並協助更新索引，但仍需要提交才能形成這次歷史。它不是在背景為檔案增加永久追蹤標籤。本例先提交改名，再查詢新路徑；沒有把尚未提交的移動當成已存在的歷史節點。
follow用在單一檔案，不是整個目錄
Git log文件對–follow明確限定單一檔案。複雜合併情況仍應核對具體提交關係。查資料夾、多個路徑或複雜合併時，不要只加同一個選項就宣稱完整追蹤。本例是線性的三個提交、一個檔案，沒有合併、複製或拆成多檔的情境。
先選你要讀的那個路徑，核對它在目前提交中的實際拼寫與大小寫。路徑相對於你執行命令的位置時，也要確認目前目錄。檔名若含空白，使用引號保護整個路徑參數，不能把空白拆成兩個檔案條件。本文使用簡單名稱，沒有把其他平台的大小寫行為當成實測。
如果要從指定歷史起點往回找，可明確指定已經核對的提交，再接雙連字號與路徑。修訂表示式決定從哪裡走，路徑決定篩選什麼；兩者都對上，結果才有可重現的範圍。不要看到查詢空白就猜測整個儲存庫的紀錄已經被刪除。
要讀舊版本正文，另用確切路徑與提交
log回答哪些提交影響這條歷史；show可以進一步查看某個提交的變更或物件。選出一筆舊提交後，要讀其檔案正文，仍應使用該提交當時存在的路徑。新名稱在舊提交裡可能不存在，不能因為follow找得到提交，就假設新路徑也已存在於那個快照。
這篇只實測log的篩選與純改名摘要，沒有執行恢復舊版本、覆蓋當前檔案或重設分支。這些修改工作目錄的操作與只讀歷史不同。如果目標只是查看舊內容，先停在只讀查閱，不必把現在的文件改回去。
用三個輸出驗收改名歷史
這些查閱命令不會新增提交，也不會把舊名稱重新放回工作目錄。案例最後仍只有新名稱的檔案，status乾淨；讀完歷史再核一次工作狀態，就能確認查詢沒有混入其他編輯操作。
先保存一般路徑log，確認它只列rename only；再保存follow的三個提交訊息；最後用show摘要核對100%純改名。三項互相支持，才能解釋為什麼較早提交會沿著舊名稱出現。只截一張三行log，沒有改名上下文，仍不足以知道查詢用的是哪個路徑與起點。
真實檔案可以再核對改名前一筆的舊路徑，確認當時確有你要找的內容。這一步用來排除同名不同檔案或選錯提交，不是要求每次都手動遍歷所有歷史。先用follow縮小範圍，再對關鍵提交核對內容，通常比直接猜測哪個檔名曾經存在更清楚。
如果輸出沒有預期的舊紀錄，保留Git版本、目前提交、新舊路徑與相關改名diff。檢查資料是否存在於你當前的本地儲存庫、查詢起點是否正確，以及改名是否被識別。本例沒有淺克隆或遠端資料取得，不能把本地查詢失敗解釋成遠端一定沒有那些提交。
讀歷史時也別把提交日期順序當成所有操作的完整故事。這個小案例沒有分支合併，三筆直接連成一條線；真專案的歷史圖可能不是線性。文件已限定–follow用在單一檔案，遇到複雜情況要核對具體提交關係，避免把工具輸出的簡化路徑說成唯一真實演變。
檔名改了，歷史不一定斷了；但可追查的結果來自明確的路徑、提交與改名偵測。把這三個條件保存，再用單檔follow核對，才能找到舊內容的入口，而不會為了看歷史就改動現在的工作。
評論0