假設一切都乾淨,當你做了git merge
,你可以簡單地git reset --hard HEAD^
於未執行合併,並git remote remove upstream
刪除遠程和所有upstream/*
遠程分支機構。 (您選擇的提交了做git fetch upstream
加上合併仍然會在你的倉庫,但除了佔用磁盤空間,他們應該是無害的。最後,沒有引用剩下的,他們將垃圾收集。)
請記住,雖然git merge
在工作目錄中做了很多工作,但最終,就存儲庫而言,它所做的只是創建一個新的提交,它具有作爲其第一個父代的前一個提示您所在的分支以及其父母的其餘部分,您合併分支的小費:
before merge:
...--o--o--T <-- HEAD=your-branch
...--o--o--o <-- upstream/master
after merge:
...--o--o--T
\
M <-- HEAD=your-branch
/
...--o--o--o <-- upstream/master
其中T
是您的上一個分支提示,M
是合併提交。名稱HEAD^
的意思是「查找當前分支的提示」 - 這是提交M
- 「並備份到它的第一個父母」:這是提交T
,通過合併的定義。然後,git reset --hard <sha-or-other-identifier>
告訴git做兩件事:
- 更改當前分支提示指向給定的提交。在這種情況下,這意味着:將
your-branch
的提示設置爲提交T
。
- 清理工作目錄以使其看起來像給定的提交(的
--hard
部分)。
第1步,使提交圖形看起來就像這樣:
...--o--o--T <-- HEAD=your-branch
\
M [abandoned]
/
...--o--o--o <-- upstream/master
一旦做到這一點,合併提交M
留在庫中,但沒有分支機構或其他標籤指向它,所以是我喜歡稱之爲「廢棄」的東西。當reflog條目到期並且提交被垃圾收集時,它將在30天后真正消失。如果你也然後將其刪除upstream/master
,垃圾收集M
導致提交的整個下鏈也成爲收集好,你讓你的所有磁盤空間了。
當然,而且,作爲它的「樹」,這次合併提交了合併後的工作目錄的內容。
我的意思是標籤的方式,引用日誌條目不是標籤本身。他們作爲臨時參考;它們默認持續30到90天,到期時間由兩個配置項控制。較短的(30天)期滿適用於引用日誌指向是不從尖端到相應的參考點可達提交項。
上面是複雜的,但它意味着,例如,如果你在分支devel
,你做了一些提交,那些提交進入devel
reflog。假設你做了4次提交,然後git reset --hard HEAD^
「撤消」最後一次提交。分支devel
的提示現在指向您的第三次提交。第三次提交指向第二次,第二次提到第一次。這三個reflog條目現在被認爲比第四次提交的條目「更有價值」:如果您從提交devel
名稱開始,則不能前進到第四次提交,只能向後移動。
因此,其中三個reflog條目將在您的配置中保留90天,或者任何值在gc.reflogexpire
之間。第四個只會持續30天,或者任何價值在gc.reflogexpireunreachable
。
我剛剛注意到git的新版本(哪些?)用gc.pattern.reflogexpire
和gc.ref.reflogexpireunreachable
對此進行了擴充。這意味着,例如,您可以設置gc.refs/stash.reflogexpireunreachable
以保持「上一級」擋板(如[email protected]{2}
)大於默認的30天,而不會保留其他更長時間段的引用日誌條目。
真棒!效果很好,細節+1 – jwags