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

Question

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

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

我認為這是在本地工作和通過FTP上傳更改的更簡單的替代方案...幸運/遺憾的是，這是一個如此簡單的工作流程，我有時會在編碼時經歷許多編輯/提交/推/拉/瀏覽器刷新周期。

我想知道這是否會轉過來讓我陷入困境。 如果它可能是一個問題，我想知道如何避免這種麻煩...看起來像一個rebase可能是要走的路，特別是因為我不必擔心沖突的分支等。

Answer 1

那么“上限”可能是發生SHA1碰撞的點，但由於SHA是40個十六進制數字長（16 ^ 40~1.4x10 ^ 48種可能性），所以它幾乎沒有可能性甚至不好笑。 因此，至少在接下來的幾千年里，你幾乎有百分之百的機會遇到任何問題。

雙曲線示例（只是為了好玩）：1次提交/分鍾（只更改一個文件 - >使用三個新的SHA（文件，提交，樹）= 3個新shas使用/分鍾= ... = 1.6M shas used / year = 1.6億萬/千年= 1x10 ^ -37 ％使用每個千年......（1000檔/每分鍾/分鍾，它仍然是3.6x10 ^ -35％）

話雖如此，如果你想要清理你的歷史，用rebase壓扁它們可能是你最好的選擇。 如果您公開分享回購，請確保您了解其含義。

您可能還希望在重新定位后進行垃圾收集以釋放一些空間（確保首先使用rebase工作正常，並且您可能需要告訴它收集所有內容，否則默認情況下不會收集任何超過兩周的內容舊）。

Answer 2

我很確定你根本不必擔心:)

Git使用SHA-1哈希來檢查文件，哈希沖突的概率接近於零。 所以玩得開心!!

我個人每天做大約30次提交沒有問題。

但是避免版本化二進制文件:)它真的很重要。

Answer 3

我認為git可以處理的提交數量沒有很大的限制，只有你可以個人消化的數量。 對於較大的項目和多個開發人員，您將看到比您自己生成的更多活動。

如果您願意，您可以保留每周合並的輔助分支，但git永遠不會關心您擁有多少提交。 只要你能理解你在做什么，就去瘋狂。 你總是可以將幾個提交分開，或者使用像bisect這樣的工具來找出歷史問題。