2014-01-20 86 views
4

我擁有大部分主分支,看起來像是一個鏈表而不是一棵樹。也就是說,我所做的大多數合併都是快速合併。我想我會遵循"A successful Git branching model"工作流程,這將指示我避免快進合併,而是留下我的功能和功能分支連接的軌跡。假設這是一個好主意。如何重寫git歷史記錄以匹配流行的git工作流程

如何最輕鬆地返修我的樹?

即說我有這樣的日誌:

* hash1 great feature #1 - almost done 
* hash2 side work 
* hash3 side work 
* hash4 great feature #1 - added y 
* hash5 great feature #1 - added x 
* hash6 documentation - added more docs 
* hash7 documentation - removed stuff 
* hash8 project-wide: added deployment descriptors.... 

我想這種日誌(或任何類似的版本):

* merged side work into branch develop 
|\ 
* * hash2 (feature branch) side work 
* * hash3 (feature branch) side work 
|/ 
* merged great feature into branch develop 
|\ 
* * hash1 (feature branch) great feature #1 - almost done 
* * hash4 (feature branch) great feature #1 - added y 
* * hash5 (feature branch) great feature #1 - added x 
|/ 
* merged documentation into branch develop 
|\ 
| * hash6 (feature branch) documentation - added more docs 
| * hash7 (feature branch) documentation - removed stuff 
|/ 
* hash8 project-wide (develop branch): added deployment descriptors.... 

我有超過40提交和我的樹是一個整件事情比我在這裏提出的要複雜得多,所以從init創建一個新的分支和挑選單個提交是最痛苦的。我猜想rebase - 交互是它可能有所幫助的地方,但是我不確定是否會。 rebase使樹變平,我需要將它擴大。我已經顯示合併feature分支到develop,但我也可能在某些時候合併develop分支到master。怎麼樣?

回答

0

正如你所說,首先你沒有太多的承諾,所以你可以做的是重寫你的歷史,問題是你將不得不推動 - 最後。

git rebase HEAD~40 -i 

然後在這裏你可以壁球通過改變小號(合併2一起提交),並通過改變è

其他解決方案,編輯您的提交信息你再說一遍,歷史只是一個歷史,你可以跟蹤你以前的「工作流」,並隨時開始新的工作。即使它不是完美的,你仍會保持真實的歷史。

國際海事組織,儘可能擠壓,編輯一點你的歷史,並開始你的新工作流程。

+0

我仍然有一些麻煩,看看這將如何工作。我不一定要壓縮提交,但我確實想從主分支中創建新的分支以獲取特徵,我將合併回主分支。在重建期間創建一個新的分支似乎沒有太大的作用。我只是有點困惑。我想我確實需要跳過某些分支的提交,然後再合併它們。 rebase只適用於單個分支,或者我錯誤地使用了它。 – Dennis

+0

在我看來,我可能需要啓動幾個rebase,一個用於每個分支,然後在它們之間玩弄提交,以創建這個工作流程?如果是這樣,也許我應該繼續前進並離開我的git歷史記錄 – Dennis

+0

根據您從其他分支機構對您的主人所做的合併,您必須定期重新定位分支機構。 你還可以** git合併功能/ branchA --no-commit --no-ff **檢查你的合併,做一些改變或解決衝突,並做你的** git commit ** – Franck