4

git には master/ と 1.7/ の 2 つのブランチがあります。チェリーピックを使用して、master/ から 1.7/ にいくつかの修正をバックポートします。(一部の変更のみが必要なため、マージは使用していません。):

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

その後、1.7/ を master/ にマージして戻します。これは、1.7/ に加えられたすべての変更 (cherry-picks テーマ自体を除く) をメインラインにマージして戻すためです。

$ git checkout master
$ git merge 1.7

私の問題は、これが(元は master/ からの) チェリーピックを master/ に再度コミットすることです:

$ 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
4

1 に答える 1

2

チェリーピックの場合、早送りオプションを使用していない限り、-ff新しいコミットを作成しているため、マージバックすると、事実上ノーオペレーションである場合でも、git はそれらのコミットをマージする必要があります。

マージの代わりに、ここでリベースが役立つ場合があります。

git rebase master 1.7

次に、ブランチをマージします (必要な場合)。

チェリーピックは、他の方法では破棄するブランチから小さな変更を取得する場合に最適です。ワークフローは、必要に応じてマージまたはリベースに基づいている必要があります。

于 2011-12-21T07:31:29.600 に答える