好的,基於菲利普的回答,我對移植,替換和過濾分支做了一些研究。
因爲我想要實現的是重寫歷史,假裝我正確地放置了我的存儲庫,我決定要實現這個目標的方法是將每個分支的頭部移植到前一個分支,然後運行git filter-branch以使更改永久化。
在新的工作流程,當一個變化完成並準備進入發佈,將被合併到發佈分支。如果您檢查歷史記錄,我希望它看起來像是發生了合併,並得到了有利於任何原始分支頭像的解決方案。
如果在結果看得太仔細,你會發現,其實有沒有合併提交 - 每個嫁接的「合併」可直接通向然後下次提交。這對於我來說並不是什麼大問題,因爲有數十個備用分支在四處漂浮,所以我會讓它無法解決。
嫁接
我創建的文件.git/info/grafts
。在這個例子中,移植文件中會有兩個條目 - 每個新的分支父條目都有一個條目。
我做了忘記包括提交以及原母公司的第一個錯誤 - 我一半的附件高手消失了,我花了大約過程中注意到的一半。
第二次,我得到了移植文件正確
[commit] [parent] [parent]
hash2 p2 hash1
hash4 p3 hash3
的內容清潔
我結束了與已在早些時候犯下漂浮被刪除了一些未跟蹤文件在我的工作目錄中。我不知道他們是如何結束了那裏的機制,但我知道,他們在我提交歷史會保留下來,所以我剛剛刪除的工作目錄拷貝跑git reset --hard
的良好措施。
分支-C是在新版本分支的末端已經指向,所以我只是將其重命名:
% git branch -m branch-C release
在移植過程中的下一步將是使移植物常駐。 這將需要使用git filter-branch
完全重寫提交樹
改寫歷史是好的,對我來說,現在,因爲我只是究竟是誰使用這個倉庫的人。有趣的故事,我正在清理它的主要原因是因爲我打算很快與其他人分享回購協議,而且我不想讓他人頭疼,試圖在其他人依靠穩定後修復佈局歷史。
因爲我會重現那些提交,我不希望老枝指針流連,讓我的老,死棵提交可見。
% git branch -d branch-A
Deleted branch branch-A (was hash1).
% git branch -d branch-B
Deleted branch branch-B (was hash3).
由於移植,沒有掛提示git抱怨,所以刪除順利。
我還同步存儲庫異地,所以我的跟蹤分支打算留住那些枯樹爲好。這個問題稍後將在push --force
上得到解決,但現在,我只是要放棄我的遙控器,以便在我本地仔細檢查我的更改時不會讓我感到困惑。
% git remote remove origin
改寫歷史
好吧,是時候做不可想象的。我的git倉庫在本地擁有正確的分支佈局,除了發佈和主分支的提示外,沒有指向任何提交的指針。
我已檢出release
分支。
沒有參數,git filter-branch
將沿着樹走下去,並重寫歷史記錄以使我的所有移植物永久。
% git filter-branch
Rewrite (...) (73/73)
Ref 'refs/heads/release' was rewritten
到目前爲止,我還沒有創建任何那些我在原計劃想閃亮的標籤 - 這是因爲標籤指針會被指向已不存在提交哈希值。
現在我已經檢查了結果,並且我的資源庫看起來是我想要的結果,我將清理嫁接文件並添加這些標記。
.git/info/grafts
現在正在移植我不關心的提交,因此,在保密的情況下,我可以完全刪除文件或清除違規項目。
% rm .git/info/grafts
提交樹仍然看起來是正確的,所以我已經通過並添加了我想要的各種版本的所有標籤。
重寫歷史記錄的最後一步是 - 我想要同步到的遠程存儲庫。
我正在重新添加我的遙控器,這將使我的提交樹看起來都糾纏不清,生病了一段時間。
% git remote add origin (...)
一開始我嘗試只是在做一個普通git push --force --all
,但實際上並沒有刪除已不存在的分支。有一個選項,它被稱爲--prune
。
% git push --force --all
Counting objects: 161, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (61/61), done.
Writing objects: 100% (86/86), 9.06 KiB, done.
Total 86 (delta 48), reused 0 (delta 0)
To (...)
* [new branch] release -> release
% git push --force --all --prune
To (....)
- [deleted] branch-A
- [deleted] branch-B
- [deleted] branch-C
一切都完美,所以我也刪除了備份信息是git的過濾分行發佈分支提出:
% rm .git/refs/original/refs/heads/release
根據您的圖片,還有就是做這個沒有真正的方法,因爲它看起來並不像實際上將分支上的更改合併回'master'。例如:'branch-B'不包含'branch-A'中所做的更改。如果你現在以某種方式使'branch-A'的HEAD成爲'branch-B'第一次提交的父代,那麼你必須將所有從'branch-A'的更改合併到'branch-B'中,從而有效地創建全新的歷史與您實際發佈爲「版本B」的版本無關。 –
啊,這很清楚地解釋了我的幾個合併衝突的問題。在我完全瞭解合併機制之前,在每個分支的頂端發生了一些特定的發佈準備更改。 – Kiirani