我將克隆回購文件（我將其在ubuntu上的一個文件夾）綁定到一臺新機器上，我得到了：christopher@christopher-laptop:~/source/personal$ git clone ~/Ubuntu\ One\ Side\ Work/projects.git/Cloning into 'projects'...done.fatal: unable to read tree 29a422c19251aeaeb907175e9b3219a9bed6c616christopher@christopher-laptop:~/source/personal$ 因此，我嘗試查看此處提出的其他許多類似問題，其中大多數都說要運行git fsck --full，然后在嘗試時得到。christopher@christopher-laptop:~/Ubuntu One Side Work/projects.git$ git fsck --fullChecking object directories: 100% (256/256), done.Checking objects: 100% (447/447), done.broken link from commit 235ae1f48701d577d71ebd430344a159e5ba4881 to commit 984c11abfc9c2839b386f29c574d9e03383fa589broken link from tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b to blob 25a742dff0a403b2b3884f2ffddf63eb45721facbroken link from tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b to blob dd4e97e22e159a585b20e21028f964827d5afa4ebroken link from tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b to tree 29a422c19251aeaeb907175e9b3219a9bed6c616broken link from tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b to tree 8084e8e04d510cc28321f30a9646477cc50c235cbroken link from tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628 to blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eabbroken link from tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628 to blob e9052d35bfb6d30065b206fc43f4200a04d5281bbroken link from tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628 to blob 1a3a5e4dd2502ac121c22f743c4250e254a94eebbroken link from tree 4aa336dc1a5838e8918e03b85580069d83f4ad09 to tree 8cc55ec952dc192a233e062201d1e7e873ac3db0broken link from tree e5674a91a53e15575a1f3bf5786bc5cc719fb483
3 回答
江戶川亂折騰
TA貢獻1851條經驗 獲得超5個贊
Git并沒有真正按照您的想法存儲歷史記錄。它基于祖先鏈在運行時計算歷史記錄。如果您的祖先缺少斑點，樹木或提交，那么您可能無法完全恢復歷史記錄。
從備份還原丟失的對象
您可以嘗試的第一件事是從備份中還原丟失的項目。例如，查看是否有保存為的提交備份.git/objects/98/4c11abfc9c2839b386f29c574d9e03383fa589。如果是這樣，您可以將其還原。
如果提交已經被打包，并且為了存儲庫手術的目的將其返回到一個松散的對象，您可能還想研究git-verify-pack和git-unpack-objects。
手術切除
如果您無法從備份中替換丟失的項目，則可以刪除丟失的歷史記錄。例如，您可以檢查歷史記錄或reflog來查找984c11abfc9c2839b386f29c574d9e03383fa589的祖先。如果發現一個完好無損，則：
將您的Git工作目錄復制到某個地方的臨時目錄中。
對未損壞的提交進行硬重置。
將當前文件復制回Git工作樹，但請確保不要將.git文件夾復制回去！
提交當前的工作樹，并盡最大努力將其視為所有丟失的歷史記錄的壓縮提交。
如果有效，您當然會失去介入的歷史。在這一點上，如果您有可用的歷史記錄日志，那么最好修剪一下歷史記錄并重新引用所有無法到達的提交和對象。
完全還原和重新初始化
如果您的存儲庫仍然損壞，那么希望您有一個未損壞的備份或克隆，可以從中還原。如果不是，但是您當前的工作目錄包含有效文件，那么您始終可以重新初始化Git。例如：
rm -rf .git
git init
git add .
git commit -m 'Re-initialize repository without old history.'
這太劇烈了，但是如果您的存儲庫歷史記錄確實不可恢復，那么這可能是您唯一的選擇。YMMV。
PIPIONE
TA貢獻1829條經驗 獲得超9個贊
在嘗試本頁上描述的任何修補程序之前，我建議您制作一份您的倉庫，僅在此副本上進行操作。然后，如果可以修復，最后將其與原始文件進行比較，以確保在修復過程中不會丟失任何文件。
對我有用的另一個替代方法是使用以下命令將git head和index重置為其以前的狀態：
git reset --keep
您也可以通過打開Git GUI并選擇每個“分段的更改”，然后單擊“取消分段”來手動執行相同的操作。一切就緒后，您現在應該可以壓縮數據庫，檢查數據庫并提交。
我還嘗試了以下命令，但它們對我不起作用，但它們可能對您有用，具體取決于您遇到的問題：
git reset --mixed
git fsck --full
git gc --auto
git prune --expire now
git reflog --all
最后，為避免此同步問題損壞您的git索引（DropBox，SpiderOak或任何其他云磁盤可能會發生這種情況），您可以執行以下操作：
.git通過使用：將文件夾轉換為單個“捆綁” git文件git bundle create my_repo.git --all，則它應該與以前一樣工作，但是由于所有內容都在單個文件中，因此您再也不必擔心同步會損壞git repo。
禁用瞬時同步：SpiderOak允許您將檢查更改的時間表設置為“自動”（這意味著它可以盡快通過OS通知來監視文件更改）。這很糟糕，因為它會在您進行更改后立即開始上傳更改，然后下載更改，因此它可能會刪除您剛才所做的最新更改。解決此問題的解決方案是將更改監視延遲設置為5分鐘或更長時間。這也解決了即時保存筆記應用程序（例如Notepad ++）的問題。
- 3 回答
- 0 關注
- 2526 瀏覽
添加回答
舉報
0/150
提交
取消