git存儲庫可以處理的提交數量有上限嗎？

Question

我想知道是否有一個git倉庫可以處理的提交數量的上限。

在我現在正在開發的獨立項目中，我一直在本地進行編碼，在git中提交/推送更改，然後在我的開發服務器上進行更改。

我將此視爲一個更加容易的選擇到當地工作，並通過FTP上傳的變化......幸運/不幸的是這樣一個簡單的工作流程，我有時會經歷很多編輯 /提交/推/拉/瀏覽器的刷新週期同時編碼。

我想知道這是否會扭轉並咬我的下線。如果這可能是一個問題，我想知道我該如何避免這種麻煩......看起來好像是一個重新組織可能要走的路，特別是因爲我不必擔心衝突的分支機構等。

Answer 1

那麼「上限」很可能是發生SHA1衝突的點，但由於SHA是40個十六進制數字（16^40〜1.4x10^48種可能性），它非常接近於零的可能性它甚至不好笑。因此，至少在接下來的幾千年裏，您幾乎有百分之零的機率會遇到任何問題。 （只是爲了好玩）：1 commit/minute（只是改變一個文件 - >使用了三個新的SHA（文件，提交，樹）= 3新的使用的shas/minute = ... = 1.6M使用了shas /年= 1.6十億shahs /千年= 1x10^-37 ％使用每千年...（在1000個文件/ commmit/min，它仍然是3.6x10^-35％）

這就是說，如果你想要清理你的歷史，用rebase壓扁它們可能是你最好的選擇，只要確保你理解了這個含義就可以了，如果你已經公開分享回購

你也可能想在重新綁定釋放一些空間（但是，確保rebase先運行，並且您可能需要告訴它收集所有內容，或者默認情況下，它不會收集比兩週之前更新的內容）。

Answer 2

我很肯定你根本不用擔心:)

Git使用SHA-1散列來檢查文件，散列衝突的概率接近於零。所以玩得開心！

我個人做了大約30天沒有問題的承諾。

但是避免使用版本化二進制文件:)它對於它是什麼非常沉重。

Answer 3

我認爲git可以處理的提交次數沒有很大的限制，只有你可以親自消化。對於大型項目和多個開發人員，您會看到比您自己創建的活動更多的活動。

如果你願意，你可以保留一個你每週合併到的次要分支，但是git永遠不會關心你有多少次提交。只要你能理解你在做什麼就瘋了。你總是可以將幾個提交區分開來，或者使用對分等工具來找出歷史問題。