5

はい、別の git フローの質問.. :(

「標準」の git rebase フローをよく知っています。

  • 開発者は、上流のブランチ (「master」など) から追跡ブランチ (「featureA」など) を作成します。
  • 開発者コード、コミット、リベースによるプル、コード、コミット、リベースによるプルなど
  • コードが完成し、開発者がコミットをスカッシュしてマスターにプッシュする

私が抱えている問題は、 master とマージする前にコードをレビューする余地がないことです。レビュアーはマスター上にある場合にのみ変更を確認するため、開発者が何かを微調整する必要がある場合、特定の機能に対してマスター上で複数のコミットが行われます。理想的には、1 つだけです。

私が知っているいくつかのオプションはこれを解決しますが、理想的ではありません:

  • 開発者に機能ブランチをリモートにプッシュしてもらいます。これに関する問題は、マスターからリベースした後、プッシュを強制プッシュにする必要があることです。この場合、おそらく安全ですが、通常どおりビジネスを行いたいとは思いません。
  • アップストリームの変更を機能ブランチにリベースしないで、それらをマージします。これにより、機能ブランチを押しつぶしてコミットをマスターにプッシュすることはできません (右??)
  • gerrit / github を使用します。純粋なgitでこれを達成する方法があると推測する必要がありますか?

より良い方法はありますか？

4

3 に答える 3

2

より高度なレビュー ワークフローを可能にするサードパーティ ツールがいくつかあります。現在、 Gerritに基づくワークフローを評価しています。

考えられる Gerrit ワークフローの 1 つは、次のようになります。

  • 開発者が機能ブランチにコミットします。完了したら、フィーチャー ブランチを押しつぶし、現在のマスターにリベースします。
  • コード レビュー ソフトウェアは、マスター ブランチに直接プッシュすることを禁止しているため、開発者は機能を (1 つのコミットに押しつぶして) レビューできるレビュー システムにプッシュします。Gerrit は、各レビュー リクエストを、レビューが完了するとマージされる個別のブランチとして透過的に処理します (チェリー ピックも可能ですが、デフォルトではありません)。
  • 変更がコード レビューに合格しない場合、開発者はコミットを修正し、コミットをレビュー システムに再度プッシュできます。ソフトウェアは、複数の (修正された) コミットが同じ機能レビュー リクエストに属しているかどうかを認識します。レビューが最終的に完了すると、最新のコミットのみが実際のマスター ブランチにマージされます。
    もちろん、すべての機能は単一のコミットにすぎないため、開発者がコード レビュー中に行った微調整を追跡することはできません (ただし、私が理解しているように、これは実際には望ましいことです)。ただし、各レビュー リクエストの履歴は Gerrit によって管理されるため、実際には何も失われません。

私たちはまだこれに似たワークフローを評価していますが、本番環境ではまだ使用していません。したがって、このアプローチが実際のシナリオで実際にどの程度うまく機能するかについては、何も言えません。ただし、Git を使用したより複雑なレビュー ワークフローに興味がある場合は、Gerrit を検討する価値があるかもしれません。

于 2013-01-23T16:18:08.840 に答える
1

このワークフローの最大の問題は、1 つのコミットに押しつぶさなければならないことです。それが Gerrit の制限です。CodeCollaborator はこの問題を回避し、私たちが好む複数のコミットを可能にします。

于 2013-01-24T02:15:06.897 に答える