Gerrit を使用して「git-flow」のようなワークフローを実装しようとしていますが、パズルの最後のピースを理解できないようです。
私の問題には2つの前提条件があります：
- Gerrit は 1 つのブランチへのマージのみを実行します
- マージ コミットを Gerrit にプッシュすることは許可しません。マージは、変更が承認された後に Gerrit が行う必要があります。
解決したいことは以下です。この git の状況を考えてみましょう:
Master 0
\
\
Develop 0-----0-----0-----0
1 つのコミットを持つ master ブランチと、複数の追加コミットを持つ master からフォークされた開発ブランチがあります。しばらくすると、develop ブランチが master にマージされ、次の製品リリースが作成されます。開発者は、develop からのトピック ブランチと厳密なリベースを使用して作業します。彼らのコミットは、プッシュする前に常に最新のアップストリーム開発の上にリベースされます。これにより、履歴が線形になり、早送りコミットのみが行われます。
ここで、誰かが master からホットフィックス ブランチを作成し、master にマージしたとします。
Master 0--------0 HF
\
\
Develop 0-----0-----0-----0
このコミットはマスター ブランチにのみマージされるようになりましたが、開発者は変更にバグ修正を組み込むために開発ブランチでこのコミットを必要とします。通常、マスター ブランチをマージして開発ブランチを開発しますが、私の前提条件を考慮すると、ローカル マージ コミットが作成されるため、これは不可能です。
私の質問は、開発者による新しい変更にバグ修正が含まれるように、マスター ブランチからローカルの開発ブランチに新しいコミットを組み込むにはどうすればよいですか? 理想的には、スクリプトを変更して、最初にバグ修正の変更をローカルの開発ブランチに適用し (マージしますが、マージ コミットは行いません)、次に開発者のコミットとプッシュをリベースします。このようにして、バグ修正は新しい変更に自動的に追加され、別のコミットではなく、新しいコミットの一部として表示されます。
私は可能な解決策について考えてきました：
- 開発ブランチへのコミットをチェリーピッキングします。次回開発がマスターとマージされると、これは常に重複したコミットになると思います。これを回避する方法はありますか？
- ここで説明されているようにリベース: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。これは、開発ブランチが公開されているため、おそらく問題を引き起こしますか?
私の質問が明確であることを願っています。さらに明確にする必要がある場合はお知らせください。私は自分のワークフローにかなり厳格であることを知っていますが、Gerrit と組み合わせると理想的です。それができない場合は、おそらくマージコミットを許可します...