在我們的本地 Bitbucket 實體上，我可以通過壓縮功能分支的所有更改（通過 Git rebase）將功能分支“合并”到我們的主分支中。這樣做時，提交訊息包含所有壓縮提交的 Git 提交 ID/哈希。此提交附加到主分支，功能分支將被洗掉。
我曾懷疑在洗掉功能分支時舊的提交也會被洗掉，但事實并非如此。由于主分支上的提交訊息包含所有壓縮提交的提交 ID，因此我能夠通過 URL 訪問 Bitbucket 中的每個舊提交。但是，由于提交不再屬于某個分支，因此我無法從 UI 中找到該提交 - 無論是在 Bitbucket 中還是在任何其他 Git 客戶端 UI 中。
因此，現在來自功能分支的壓縮提交只是“隱藏”，但它們仍然存在于 Git 存盤庫中。
現在我的（相當學術的）問題：
- 總是這樣嗎？即使先前關聯的分支已被洗掉，Git 是否始終保留壓縮的提交？
- 有什么方法可以提取以前壓縮的提交的提交 ID，即使“舊”提交 ID 不是壓縮提交訊息的一部分？
- 是否可以“硬洗掉”舊提交？
提前致謝！
uj5u.com熱心網友回復：
- 總是這樣嗎？即使先前關聯的分支已被洗掉，Git 是否始終保留壓縮的提交？
不。Git 可能會或可能不會保留原始提交一段時間，甚至永遠，但是對此沒有硬性規定，除了通常的：如果提交是可訪問的（通過某個名稱，例如分支或標簽名稱），必須保留。
（GitHub 有自己的簡單規則：永遠不會洗掉提交。這可以解決您使用他們使用的分叉模型可能遇到的一些問題。Bitbucket 可能自己也可能沒有添加相同的規則。這條規則有一些缺點，可能引導這些托管站點實施更高級的規則，畢竟允許洗掉未參考的提交。）
- 有什么方法可以提取以前壓縮的提交的提交 ID，即使“舊”提交 ID 不是壓縮提交訊息的一部分？
不。
- 是否可以“硬洗掉”舊提交？
僅當您可以直接控制存盤庫時。在這種情況下，您可以使用某些維護命令（git gc、git prune等）。
你也可以克隆一個倉庫，然后洗掉原來的（如果你有正確的訪問/權限，安裝新的克隆來代替原來的，使整個操作對“外人”不可見，除非停機時間有多長所有這些）。克隆通常不會復制任何未參考的（“除哈希 ID 外不可見”，名義上已洗掉）提交，因此這為您提供了一種在錯誤后進行清理的簡單方法。但這通常意味著使用鏡像克隆并直接登錄訪問托管存盤庫的任何站點。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/389532.html