科技 · 實用指南
Git 顯示 dubious ownership？先證明使用者、路徑擁有者與信任作用域
不要直接設定 safe.directory=*；先稽核實際 Git、系統身分、儲存庫真實路徑與受保護設定。
Git 的 dubious ownership 拒絕是安全邊界，不只是權限小錯。安全修復要先證明哪個 Git 以哪個使用者拒絕哪個真實路徑。
本指南把異常擁有者、啟動身分、共享儲存庫與設定作用域分開。
凍結失敗現場
先保存完整錯誤、命令、被拒路徑與執行環境，再變更擁有權或設定。
不要先做 chmod、遞迴 chown、重新複製或 safe.directory=*；先保留可判斷修復分支的證據。
證明實際 Git 與使用者
在失敗環境記錄 Git 執行檔、版本、whoami、id、HOME、服務帳戶與 SUDO_UID。
GUI、WSL、CI 與終端機可能使用不同程式、使用者和設定檔。
核實真實路徑與擁有者
使用錯誤中的精確路徑，以 realpath、stat、ls -ld 或 Get-Acl 檢查實路徑與父目錄。
分清個人複製的錯誤擁有者、共享服務儲存庫、掛載 UID 對映、NAS 與 WSL。
檢查信任設定來源
在同一環境顯示 safe.directory 的來源與作用域，並檢查全域和系統設定。
本地儲存庫不能自行標記可信；路徑拼法、HOME 與客戶端/伺服端差異都會造成錯置。
選擇最小修復
個人複製且擁有者錯誤時修正擁有權；刻意共享時才加入一個精確絕對路徑。
safe.directory=* 是完全退出檢查，不是診斷；不要用廣泛 chmod 或 chown 取代分析。
處理跨環境邊界
比較 GUI、WSL、容器、CI、sudo 與 SSH 實際使用的 Git、使用者、HOME 和掛載擁有者。
客戶端設定不能修復伺服端失敗；每個分支應以明確擁有者或精確例外結束。
驗證與回滾
在原環境重跑原命令與只讀檢查，再顯示設定來源，確認無關儲存庫未被信任。
記錄所有者或例外值、設定檔、原因與移除命令，確保其他位置仍保留保護。
