2013-11-22 42 views
2

對於我正在開發的這個項目,我們使用了相當標準的git rebase工作流程。也就是說,我們將在feature分支中完成我們所有的工作。經過特點是準備進行測試,別人會:Git rebase工作流程 - 爲「穩定」分支添加錯誤修正

git checkout master 
git merge feature 

我們也有一個stable分支,它基本上是一個master出血少,邊副本。經過master的變化是由別人的徹底測試,會有人則:

git checkout stable 
git merge master 

我遇到的問題是以下情況:

  1. master有許多新的提交相比stable,因爲一項新功能剛剛推出測試。
  2. master中的提交完全沒有準備合併到stable
  3. stable中發現了一個錯誤,需要立即解決。

我不能修正錯誤的只需添加到stable,然後變基master在它的上面,正如其他人簽出master。我無法將修補程序添加到master,然後將它合併到stable中,因爲master包含完全不能使用的提交。最後,我不想只將bug修正添加到stablemaster的末尾,因爲這會使下一個git checkout stable && git merge master中斷。

如何調整我的工作流程以適應這種情況?我想避免重複提交(即stable以「相同的提交」結尾兩次,使用不同的提交哈希)或合併提交。

目前,由於這種情況並不常見,我只需將重寫爲,並確保已檢出的其他人知道。不過,我想知道是否有更乾淨的方法來實現這一點。

+0

你說錯誤是在'stable'中發現的,但是隻提到通過從'master'合併而達到穩定的代碼。當我讀到它時,這意味着這個錯誤在最後一次合併到'stable'之前被提交給'master'。它是否正確? – jthill

+0

沒錯。從理論上講,所有的錯誤在被合併到穩定之前都應該被修正。但是,從來沒有「沒有錯誤」,所以有時它們會被合併,然後我們繼續在'master'上進行開發,然後才能被檢測到。 – CmdrMoozy

+0

從註釋,你不想合併提交在主,是否合併提交從任何東西,但你試圖避免'功能',或只合並提交'穩定'? ......好的,「rebase工作流程」,從'feature'到'master'的所有合併都是快進? – jthill

回答

2

下面是一個簡單的方法,或者我希望在稍微研究一下後,它可以避免合併提交。

從文本和評論我看到你在做行軍,螞蟻招用masterstable,其中唯一的操作(至少通常)在其中一方的許可是一個快進合併:

...--X--...S      stable 
      \ 
      m--...--M    master 
         \ 
         f--...--F feature 

我的建議如下,忍耐一下,當你到這第一部分的難看的結果:

git checkout master -B m-temp # let's do this with nonce names at first 
git revert X 
# (maybe **amend** the commit to what X should have been here) 

git checkout stable -B s-temp 
git cherry-pick m-temp 

git checkout feature -B f-temp 
git cherry-pick m-temp 

生產:

...--X--...S---X''       s-temp 
      \ 
      m--...--M---X'    m-temp 
         \ 
         f--...--F---X''' f-temp 

和你所有的分支機構都只有一個修正X的問題。這看起來像一團糟,但

請注意真正的快速合併。當它的時間趕上穩定達到主,你可以用任何的

git checkout s-temp   # the slow way 
git reset --hard @{1}   # . (reset one commit from s-temp, i.e. to S) 
git merge m-temp    # . 

做是正確的或得到完全相同的效果:

git checkout -B s-temp m-temp # exactly the same, without the rube goldberg 

每個那些生產:

   X'' <-- discarded cherry-pick of X' 
      /  
...--X--...S---m--...--M---X'    m-temp s-temp 
         \ 
         f--...--F---X''' f-temp 

......而且你的分支機構仍然只有一個X的修正。當快速轉發主機的時間也是這樣做的時候,X'也被丟棄了,而X'''是你歷史上唯一的X修復,或者你可以有你的功能 - 分支devs rebase到X'上並丟棄它們自己的X''s


Git有一個用於分支的'description'配置項。這裏是有用的就擺在結賬後鉤東西:

cat >>.git/hooks/post-checkout <<\EOF 
#!/bin/sh 
# 
# if there's a stored note about this checkout, show it: 

# $3 = 1 for a full branch checkout 
if branch=`git symbolic-ref --short -q HEAD` && test $3 = 1; then 
     git config --get-all branch.$branch.description 
fi 
EOF 
chmod +x .git/hooks/post-checkout 

,然後當你要提醒自己的東西,

git config --add branch.stable.description \ 
    "reset to commit c0ffee before merging master" 

這使得櫻桃採摘任何主修正你想了解一樣簡單可以。當你想要的音符消失了,

git config --unset branch.stable.description c0ffee 

使所有正則表達式匹配的音符c0ffee消失。

+0

這看起來很不錯!我的一個問題是,最終結果(在我最終用'M'趕上'S'後),看起來最終結果將是提交將以不同的順序 - 也就是說,來自'M'的新提交將被插入*在'S'的'X'提交之前。這似乎對我來說應該是「安全的」,但只是爲了證實:如果在完成這個過程之後,在客戶端上執行'git checkout stable && git pull',它是否需要合併?如果我理解正確,似乎它應該仍然能夠快速前進。 – CmdrMoozy

+0

對於你的問題:不,X'被完全丟棄,並且(假設你像往常一樣將你的功能分支開發人員重新貼裝到主設備上)不會改變主分支歷史 - 上面的圖片包含所有相關信息, git不僅僅是概念上的。 – jthill

+0

Re客戶端拉'stable',啊,不,重置'stable'後會發生什麼事情是客戶先前拉過X'''會在他們的下一次拉動時收到重置警告,除非他們配置了'branch.stable .rebase'。好眼睛。對我來說,這似乎不是什麼大問題,沒有人「應該」將這項工作從根本上解決,對吧?修復本身,如果不是那個確切的提交,仍然會在他們的下一個拉。 – jthill

3

將錯誤修復爲stable,然後將其合併到stablemaster

git checkout -b bugfix stable 
# Make and commit changes 
git checkout stable 
git merge bugfix 
git checkout master 
git merge bugfix 

這樣的話,只有一個提交(或一組提交的),在它的bug修復,所以當你合併masterstable以後應該不會有衝突。

+0

甚至關閉'git merge-base master stable' – jthill

+0

如果我稍後在'stable'中執行'git merge master',如果我這樣做,我不會得到兩個「相同」提交副本嗎? – CmdrMoozy

+0

@jthill假設我正確理解OP的工作流程,那應該等同於'stable'。儘管如此,我想這可能不是一個錯誤修復在最後一次合併之前的某個時間點已經合併到stable中。 – Ajedi32