7

大規模なプロジェクトで Gerrit の使用を検討しています。この時点で、承認された変更のマージ競合に人々がどのように対処しているかを知ることは興味深いでしょう。

さまざまなサイズの多くの変更が同時に改訂保留中であり、それらが徐々にレビューおよび検証されていると想像してください。それらの一部は同じコードを変更している可能性があるため、競合は避けられません。「インテグレーター」が単純なワークフローで手動でパッチを受け入れる場合は問題ありません。小さな競合は途中で解決できますが、Gerrit では事情が異なります。変更がレビューされて承認された後、マージの競合が発生した場合、私が理解しているように、作成者によってリベースされ、改訂のために再度プッシュされる必要があります。その場合、改訂プロセスが再び開始されます。比較的活発なプロジェクトでは、1 週間に 50 件を超える外部貢献者のコミットがあり、これは悪夢に変わる可能性があります。

質問:

  1. Gerrit は、多数のマージ競合が予想される大規模でアクティブなものを前進させる方法ではないということは正しいですか?

  2. いくつかのマージの競合は些細なことかもしれません。作成者が変更を再コミットするのを気にせずにそれらを解決する方法はありますか?

  3. 変更を安定したブランチにバックポートする必要がある場合は、チェリーピックがクリーンであっても、各ブランチの個別の変更をプッシュして改訂する必要があると思います。

Gerrit ワークフローの経験に関する一般的なコメントも歓迎します。

4

4 に答える 4

7

  1. Gerrit は、Android や関連する bsp、カーネルなどのリポジトリなど、非常に大規模なプロジェクトで使用されています。これらのプロジェクトは、週に 50 件以上の外部コミットを受けます。Qualcomm は、その程度の時間で数千のコミットを行うと思います。

  2. Gerrit には、些細な競合を自動マージする設定があります。これはリポジトリごとに設定できます。このオプションが設定されている場合、変更がレビューおよび検証され、ユーザーが [送信] ボタンを押した後、送信戦略 (チェリー ピック、必要に応じてマージ) に基づいて変更がマージされます。これについて私が見つけることができる最高のドキュメントは、http: //gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_optionsの下の --use-content-merge オプションにあります。

  3. はい、それは通常、私たちが物事を行う方法です。他のオプション (レビューのバイパス、ブランチのマージなど) がありますが、必要なブランチへのチェリーピッキングとレビューはうまく機能します。

于 2012-04-05T03:39:48.220 に答える
4

私たちは履歴をクリーンでわかりやすく保ち、合理的に直線的に保ちたいと考えています。そのため、早送りマージのみを使用するように Gerrit を構成しました。目に見える唯一のマージは、リリース ブランチとサポート ブランチ (git-flow を使用しています) のためのものであり、これにより物事がはるかに理解しやすくなります。

ただし、trivial-rebase プラグインがインストールされているため、以前のレビュー ステータスがリベースされた変更に自動的に適用されます。これは、リベースが Gerrit で ([リベース] ボタンを使用して) 行われるか、開発者がローカルでリベースして変更を再プッシュするかに関係なく発生します。

私たちの経験では、大規模なプロジェクトではソース ファイルの数がはるかに多いため、マージの競合は実際にはあまり一般的ではありません。リポジトリには約 16,000 個のファイルがあり、フルタイムまたはパートタイムの開発者は 30 人いるため、同じファイルを編集する可能性は非常に低くなります。

いずれにせよ、2 人の開発者が同じファイルの同じ部分に変更を加えている場合は、実際にお互いに話し合う必要があります。プロジェクト アーキテクチャで同じファイル (ある種の登録テーブルなど) を頻繁に変更する必要がある場合は、アーキテクチャを再設計するか、依存性注入などを使用するか、ビルドの一部としてフラグメントからそのソース ファイルを自動的に生成する必要があります。

于 2012-11-08T18:09:59.263 に答える
2

当社でマージの問題が発生すると、開発者はリベースして gerrit にプッシュします。マージが最小限だった場合、彼は (慣例により) LGTM にリベースとサブミットを許可されます。

開発者がパッチセットを更新するときにリベースする必要があるかどうか、またその時期についてはまだ議論中です。親が変更されたときにパッチセットを比較すると、UI が混乱します。

于 2012-04-26T01:08:02.093 に答える
0

機能ブランチをデフォルトモードにマージして数年間mercurialを使用した後、数週間使用していますが、gerritが嫌いです。非 gerrit モードでの Mercurial または git のマージによって自動的に解決される些細な競合を解決するオーバーヘッドが増えていることに気づきました。次に、誰もが議論を使用します android uses gerrit ergo gerrit は良いものであり、誰にとってもうまくいくはずです。

于 2014-06-13T23:46:50.550 に答える