避免重複提交時，櫻桃採摘從主到分支，然後從分支合併回到主

我在git，master /和1.7 /中有兩個分支。我使用cherry-pick將master/fix中的一些修復恢復到1.7 /。（我使用的不是合併，因爲我只想要一些變化。）：避免重複提交時，櫻桃採摘從主到分支，然後從分支合併回到主

$ git checkout 1.7 
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>

再後來，我合併1.7 /回到主/，因爲我想那已經進入所有更改1.7 /（除了櫻桃挑選themeselves）將被合併回主線：

$ git checkout master 
$ git merge 1.7

我的問題是，這種重新提交的櫻花選秀權（最初是從主/）進入主/再次：

$ git log --oneline 
8ecfe22 Merge branch '1.7' 
fe3a60d master change 2 (cherry picked from commit f5cca9296e45d5965a552c45551157ba 
9c25f53 master change 1 (cherry picked from commit 8fae2a68a356f5b89faa8629b9a23b23 
f5cca92 master change 2 
8fae2a6 master change 1 
ffa10bf initial commit

在我的真實情況它甚至造成合並衝突。

所以我的問題是，我可以避免（如果是這樣，如何）？

命令的完整列表重現此問題：

$ git init 
<create Dialog.js file> 
$ git add Dialog.js 
$ git commit -am "initial commit" 
$ git branch 1.7 

<edit Dialog.js file> 
$ git commit -am "master change 1" 
<edit Dialog.js file> 
$ git commit -am "master change 2" 
$ git log 

$ git checkout 1.7 
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA> 

$ git checkout master 
$ git merge 1.7 
$ git log

來源

2011-12-21 Bill Keese

當櫻桃挑，除非您使用的是快進選項-ff，你正在創造新的提交，當你重新合併，git的有合併在這些提交中，即使它們可能實際上沒有運行。

再次基於可能會幫助你在這裏，而不是合併：（如果需要）

git rebase master 1.7

，然後現在，合併分支

當你想獲得小的變化

摘櫻桃，最好使用來自你在其他方面拋棄的分支。您的工作流程應基於合併或重新組合。

來源

2011-12-21 07:31:29 manojlds

是的，我可以想象rebase工作，雖然在git社區中，調用分支上的rebase被認爲是一種致命的罪。還有另外一種方法嗎？我可以使用「混帳合併」將更改從主/移動到1.7 /，但以某種方式過濾哪些更改它合併？像一個類似於rebase -i的-i選項？如果我確實這樣做了，會記得哪些變化來自master /，而不是以後嘗試將它們重新合併回master？ –

哎呀，我打算打字「在* public *分支上打電話rebase被認爲是一種致命的罪行」。 –

避免重複提交時，櫻桃採摘從主到分支，然後從分支合併回到主

回答

相關問題