所以我在專業的Git 3.1節橫跨下面這段話來了:爲什麼在提交之前blob出現在存儲庫中?
「讓我們假設你有一個包含三個文件的目錄,並準備將它們暫存並提交暫存文件計算校驗和爲每一個(我們在入門指南中提到的SHA-1散列)將該版本的文件存儲在Git存儲庫中(Git將它們稱爲blob),並將該校驗和添加到臨時區域「
我的問題是:爲什麼在我提交這些文件之前,git會「在Git存儲庫中存儲該文件的一個版本」?
所以我在專業的Git 3.1節橫跨下面這段話來了:爲什麼在提交之前blob出現在存儲庫中?
「讓我們假設你有一個包含三個文件的目錄,並準備將它們暫存並提交暫存文件計算校驗和爲每一個(我們在入門指南中提到的SHA-1散列)將該版本的文件存儲在Git存儲庫中(Git將它們稱爲blob),並將該校驗和添加到臨時區域「
我的問題是:爲什麼在我提交這些文件之前,git會「在Git存儲庫中存儲該文件的一個版本」?
Why questions are always tricky.
有一個非常機械的回答(這是我看到siride mentioned in a comment):Git的指數的內部結構,即Git使用以建立下一個犯那個神祕的對象,只存儲BLOB哈希標識。因此,爲了在的文件中有一個副本(以便它將在下一次提交中),它必須作爲blob對象存儲在存儲庫中。
有一個性能答案:通過在索引中存儲散列ID,Git非常快速地進行新的提交。
有一個數據恢復答案(這是一種弱點):通過預先在存儲庫中存儲blob,您可以通過git fsck --lost-found
找回它一段時間,如果您不小心做了不好的事情。 (這裏的弱點是,或者包括,如果blob與存儲庫中的現有blob相匹配,則它不會顯示在找不到的搜索中;並且您將丟失文件的名稱,這對理解其內容通常很重要)
有一個設計美學的答案:或許Linus認爲git add file
將文件複製到存儲庫的時間早於後面的git commit
。
你可以選擇任何這些答案,或者自己組裝!
這就是索引/分段區域的工作原理。它創建提交的所有部分,然後當您發出commit命令時,它將這些對象連接到您的歷史記錄。 – siride
您可能有興趣閱讀https://matthew-brett.github.io/curious-git/curious_journey.html – mkrieger1
澄清siride:因此git實際上並沒有在提交blob時「移動」任何文件,它只是連接他們通過引入一個提交對象來引用你的blob通過樹的歷史。如果是這樣的話,索引和存儲庫只會出現分離,但實際上依賴於相同的文件,對吧? – Jack