Git：ブランチで行われた変更のみをマージする

Question

G---H    // Release Branch 
/
/
A---B---E---F--- // master 
    \ 
    \ 
     C---D---  // bug fix branch 

私たちのプロジェクトの特別なニーズに基づいて、上記のシナリオが発生するのは非常に一般的です。私たちはmaster/devブランチをコミットしています。次に、バグレポートを取得し、バグブランチ上で修正を開始します（上記のCとDをコミットします）。その間にdevブランチでより多くのコミットが発生します。次に、上記のコミットB、E、Fによって導入された変更を含めることができない顧客用のリリースを作成する必要があると言われますが、バグ修正が含まれている必要があります。

だから我々はこれまでに適用された変更Bの前にDEVの分岐が、あまりにもこのリリースブランチにバグ修正を取得するための最良の方法は何ですか？ブランチのマージを実行すると、Bで行った変更が含まれますが、これは不要です。私は、コミットCとDのチェリーピックを行うことができますが、私のレポは、その後のようになりますので、私はチェリー・ピッキングは基本的に常に良いアイデアbased on this answerではないことを読む：だからC「およびD」

G---H---C'---D'--- // Release Branch 
/
/
A---B---E---F---  // master 
    \ 
    \ 
     C---D---  // bug fix branch 

として完全に表示されますCとDと異なるsha-1 IDを持つ新しいコミット。これは本当に悪いことですか？これはどのような問題につながりますか？バグ修正ブランチからリリースブランチへの変更を得る良い方法はありますか？

Answer 1

特にreleaseブランチをmasterにマージする予定がない場合は、チェリーピックを使用する際に本当の危険はありません。

一般的には、あなたがに修正をマージしたいすべての分岐に含まれているコミット上のバグ修正を基づかことにより、このような問題を防ぐことができます。 gitの自体の開発において、それは（のみの修正を受ける、すなわち、現在の安定したシリーズ）maintブランチにすべてのバグ修正をマージした後、定期的masterにそれをマージすることによって達成されます。そうすれば、修正はどこにでもあり、合併は正気です。

Answer 2

This記事では、2つのブランチをマージする代わりに、gitが重複しないコミットだけをリベースすることを推奨します。

しかしチェリーピッキングの代わりに、あなただけのブランチをリベース検討するかもしれない：

releaseはリリースブランチであると bugはバグブランチです

rebase --onto release B bug 

。

その後、

  C'---D' //Bug branch  
     /
    /
    G---H // Release Branch 
/ 
/
A---B---E---F---  // master 

のような何かを得るしかし、これはお好きな時にバグフィックスがあなたにもリリース内のすべての変更を引き起こす、マスターとバグをマージする必要があるだろうことを習得するために適用されることを意味しますマスターに追加されます。

それはあなたのために最高の作品かを決定するのはあなた次第です。それは彼らのために混乱を作成しますので、あなたは、他にpushedていた枝をリベースべきではありません

注意。

Answer 3

注：上記で説明したように、チェリーピッキングがここに受け入れられます。
その主な欠点は以下のとおりです。

• マージの場合には、あなたがあるため、重複の競合になるだろうが
  参照をコミット「Git cherry pick and datamodel integrity」
• は、機能的な依存関係を無視します。
  「How to merge a specific commit in git」を参照してください。あなたのケースでは

：

• バックマージする必要はありません。
• CとDは、Bに導入されたコードに基づいていないことがわかっている場合は、それらを必要に応じて選択してください。