7

私たちのワークフローに適合する、Gerrit で複数のブランチを操作する適切な方法を特定しようとしています。

現在、ブランチを使用する方法は次のとおりです。マスター ブランチとフィーチャー ブランチがあります。master は磨き上げてリリースに向けて準備したいブランチですが、feature は明らかに集中的な作業の分野です。さて、私たちの特定のケースでは、誰かがバグ修正に取り組むときはいつでも、彼らは:

  • master ブランチを対象とした変更を作成する
  • 機能ブランチを対象とした変更にチェリーピック
  • gerrit コードのレビューが完了したら、両方の変更を送信します。

今私がチェリーピックを理解している方法では、個々のコミットを選択し、それを現在の変更にマージします。その場合、最終的にマージの競合は発生しないと予想されます。実際、このワークフローは GIT だけで完全に機能します。ただし、Gerrit は、おそらくその性質 (ブランチはローカルのようにリモートでマージされず、別の sha タグを取得する) により、最終的に膨大な数の競合するファイルを一覧表示します。

今、私はマージ戦略を適用することでこれらの問題をすべて解決しました (私たちはフィーチャーに、彼らはマスターに)、しかしそれは正しくないと感じています: 何かが伝播されなかった場合、それは単に破棄されました.

私の質問は次のとおりです。最終的に gerrit とのクリーンなマージを生成する、上記のような安全なワークフローはありますか?

4

2 に答える 2

9

この場合、チェリーピックよりもマージする方が良いと思います。

チェリーピックは同じ変更を追加しますが、同じcommitは追加しません。そのため、ソースはチェリー ピック アンド マージで同じですが、git ツリーは異なります。ツリーが異なり、後でマージを行うと、git は、以前に選択したコミットが欠落していると判断し、実際のコードが既に存在する場合でも、その変更もマージしようとします。そのため、多くの競合が発生する可能性があります。

別の働き方を提案します。

  • 通常の作業を行うときは、機能を開発し、通常どおり Gerrit にプッシュします。
  • 安定した実稼働環境でパッチ (つまり、バグ修正) を行うときは、直接master (または必要に応じてローカル ブランチ) で行いますが、featureでは行いません) 。
  • パッチが Gerrit で承認されると、実際のマスターにマージされ、プルリクエストを作成してその変更をローカル コピーに取得できます。マスターのバージョンはGerritsマスターと同じになりました
  • masterのすべての新しい変更をfeatureにマージします。機能に対して既に行ったことよりも先にパッチが終了するように、必ずリベースを行ってください。
  • すべての新機能をデプロイするときが来たら、機能をmasterにマージし、Gerrit にプッシュします (権限がある場合は、これらの変更が既にレビューされているため、refs/for/master の代わりにmasterに直接プッシュすることで gerrit を渡すことができます)。
  • すべての変更が Gerritsマスターに適用されたら、マスターをプルし、リベースを使用して機能にマージし、機能をクリーンなブランチにします。もちろん、リリースごとに新しい機能を追加することは完全に有効です。どちらも正常に動作します。
于 2013-02-04T19:02:39.113 に答える
0

このフローは正常に機能するはずなので、少し混乱しています。バグ修正がレビュー/検証/提出される前に他のユーザーが変更を提出した場合、マージの競合が発生する可能性がありますが、それはまれです。

もし、あんたが：

  1. マスターのバグを修正
  2. プッシュしてレビューする (変更 A を gerrit に作成する)
  3. 機能ブランチの一番上にあるcherry-pick change A (マスターから機能への競合を解決します)
  4. 厳選された変更をプッシュしてレビューする (変更 B の作成)
  5. レビュー/検証/変更の送信 A & B

すべてがうまくいきます。マージの競合が発生する唯一の方法は、他のユーザーが手順 1 と 5 の間に変更をアップロードして送信した場合です。異なる動作が見られますか? 詳細を教えていただけますか？

于 2012-07-31T19:35:48.130 に答える