科技 · 實用指南
Git 顯示「detected dubious ownership」：加入 safe.directory 前先查擁有權邊界
把致命錯誤視為身分不一致，而非惱人的警告。先核對 Git 程序使用者、儲存庫擁有者、掛載路徑與設定範圍，再決定是否只放行一條精確路徑。
工作樹屬於另一身分時，Git 預設拒絕讀取該儲存庫設定，除非明確信任該路徑。安全作法是先證明誰執行 Git、規範路徑由誰擁有；意外錯置就修正擁有權，確實共享時才加入一個精確例外。
1. 記錄失敗身分與規範路徑
在真正失敗的同一 shell、服務、容器或 CI 步驟重現。記下有效使用者、Git 顯示的精確路徑與規範工作樹路徑。類 Unix 系統比較 id -u、id -g 與儲存庫和各層父目錄擁有者；Windows 則在同一 Git 用戶端情境檢查擁有者 SID。不要假設互動終端、GUI、sudo、服務與容器共用身分或設定檔。
2. 變更前先分類
有三種情況：還原、系統管理員複製、搬移磁碟或 root 建置造成意外錯誤擁有者，應修正擁有者或改用預期帳號；刻意共享造成不同擁有者，應保留並只建精確例外；檔案系統邊界回報不穩定資料時，應重複取證，並測試將儲存庫置於掛載點下一層或改掛父目錄。
3. 確認失敗程序讀到哪份設定
--global 寫入的是執行命令者的設定；另一服務帳號、容器使用者或 CI 程序可能讀取不同 HOME。在失敗情境執行 git config --show-origin --get-all safe.directory，查看有效值與來源檔案。只有管理員要制定整機政策時才使用 system 範圍。此設定只在受保護設定中生效，儲存庫不能用本機設定把自己標成安全。
4. 套用最窄修復
若擁有者是意外的，只把儲存庫樹改回預期帳號並驗證，不要遞迴放寬無關父目錄。若共享是刻意的，為真正執行 Git 的身分加入規範儲存庫路徑，並依目前 shell 正確引用。避免萬用字元 *，因為 Git 說明它會完全退出檢查；路徑末尾 /* 也會信任下方所有儲存庫，只適合受控共享根目錄。
5. 用原操作重測並涵蓋巢狀儲存庫
以原程序使用者重跑 git status 與最初命令，再分別檢查子模組、worktree 與巢狀儲存庫。若測試誤用 root 或另一個 HOME，成功沒有證明力；再次確認有效身分與 show-origin 輸出。單一路徑正常後，移除過時或萬用字元項目，並記錄為何信任該共享擁有權。
為何這項警告值得尊重
擁有權遍歷規則來自 CVE-2022-24765。GitHub 說明，多使用者系統中的攻擊者可在父層放置 .git，讓 Git 讀取可能執行命令的設定。現代 Git 因此在探索跨越擁有權邊界時停止。應問的不是「如何靜音」，而是「誰擁有路徑、為何合理、例外能縮到多小」。
