2011-12-21 4 views
3

У меня есть две ветви в git, master/и 1.7 /. Я поддерживаю некоторые исправления от master/до 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 

ответ

2

Когда вы вишневый выбор, если вы не используете перемотки вперед вариант -ff, вы создаете новые коммиты и при слиянии обратно, мерзавец должен сливаются в этих коммитах, даже если они могут эффективно не работать.

Rebase может помочь вам здесь, вместо слияния: (., Если это необходимо)

git rebase master 1.7 

, а затем теперь объединить филиал

Cherry-пикап используется лучше, если вы хотите, чтобы получить небольшие изменения от ветки, которую вы в противном случае отбрасываете. Ваш рабочий процесс должен основываться на слиянии или перерасчете по мере необходимости.

+0

Да, я могу представить, что работа по перестановке, хотя в сообществе git, вызов перебазирования на ветке считается смертным грехом. Есть ли другой подход? Могу ли я использовать «git merge» для перемещения изменений с master/на 1.7 /, но каким-то образом фильтровать, какие изменения объединяются? Как вариант -i, похожий на rebase -i? И если бы я сделал это, не помню, какие изменения произошли от мастера/и не пытались снова объединить их обратно в мастер? –

+0

К сожалению, выше, чем я намеревался ввести «переадресация вызова на * публичную ветку», считается смертельным грехом ». –