2

Gerritは、コミット履歴の初期にあり、リポジトリの別の「ブランチ」にある、レビューされていない可能性のある変更をマージします。次に例を示します。

  1. チェックアウトジェリットブランチdevel
  2. file1.txtを作成し、追加し、コミットし、プッシュしますrefs/heads/temp_branch
  3. file2.txtを作成し、追加し、コミットし、プッシュしrefs/for/develてコードレビューを行います

file2.txtが受け入れられてマージされると、file1.txtはアップストリームであり、レビュー中としてフラグが立てられた別の変更ブランチにないため、マージされます。これは潜在的に非常に問題があり、私が思いつく唯一の解決策はすべてのブランチにプッシュされたすべての変更をコードレビューするように強制します。これは理想的ではありません。1つのグループの承認者がいるブランチや、コードレビューがないブランチ（コードスワッピングの場合）が必要な場合があるためです。

ここでの解決策は、file1.txtが同じリポジトリ内の別のブランチにプッシュされなかった場合のように、履歴内のすべてのコミットをコードレビューに強制的に配置することです。

このルールを課す設定はGerritにありますか？refs/heads/他のブランチを汚染するリスクを冒すことなく、自由にプッシュできるワークフローを誰かが考えることができますか？

どうもありがとう。

4

1 に答える 1

2

ステップ3のコミットには、ステップ2のコミットが親として含まれているため、この動作が発生していると思われます。すべての親が送信されていない限り、コミットを送信することはできません。これはGerritのバグのように思われることに同意します。ステップ2が送信されるまで、送信を拒否する必要があります。

この回避策を試してください-ステップ2の後にステップ2aを追加します。

2a。develブランチをもう一度チェックアウトします

コミットが2つの異なるブランチに送られる場合、それらが線形であるのは意味がありません。

もう1つの考え-このプロジェクトにどのマージ戦略を使用していますか？チェリーピックの場合は、必要に応じてマージに変更してみます。チェリーピックでない場合は、チェリーピックに変更してみます。ここでの動作は、マージ戦略間で異なると思います。

于 2012-02-28T15:55:43.453 に答える