git-flowとgithubによるコードレビュー

Question

通常のgitおよびgithubを使用すると、masterブランチに取り組んでいる機能ブランチのプルリクエストを作成するだけで、コードレビューを実行できます。 git-flowでコードレビューを行うにはどうすればよいですか？ 「git flow feature finish」のようなワークフローでは、コードレビューが実際にどこで行われるか、そしてgit-flowまたはgitがそのレビューをどのように促進できるかについて混乱しています。

Answer 1

最近、この正確な問題に遭遇しました。私たちはgitフローが非常に好きです。これは、適切なレベルのセマンティックを使用するため（チームディスカッションで使用するのと同じレベルを使用する：「ブランチを作成してチェックアウトする」よりも「機能Aを開始します」）、 gitは非常に「実装」レベルです（これも優れていて便利ですが、異なります）。

私たちが抱えている問題は、git feature finish、ブランチを開発にマージするので、プルリクエストを送信し、（これは重要です）レビュー担当者がマージチームの所有権を強調するために、コミッターではありません。

現在のソリューション：

1. 誰かがgit flowを使用して機能ブランチを作成します
2. 完了したら、彼はプルリクエストを作成します（githubを使用）
3. レビューが行われ、潜在的に追加のコミットが行われる
4. プルリクエストはマージされますレビューアによるGitHubを使用。
5. Gitフロー機能の終了はありません（ブランチは既にマージされているため）

これは私たちの慣例と一貫しており、ブランチを自分で削除する必要があるという欠点があります（gitフローの終了を行わないため）。私たちの次のステップはおそらくこれを考慮に入れるために（主にgitコマンドのチェーンについて）gitフローの一部を再実装することです（マージのない仕上げの「クリーニング」部分があります）。

Answer 2

私が作業しているチームがこれを使用するプロセスは次のとおりです。

1. 機能ブランチを作成します：git flow feature start module_1
2. コードは機能ブランチで更新されます
3. 変更がコミットされると、GitHubにプッシュされます（または、必要に応じて最後に1回）。
4. 機能が完了すると、developと機能ブランチmodule_1を比較して、GitHubでプルリクエストが開かれます。
5. チームはプルリクエストを確認し、コメントを作成します
6. プルリクエストからの変更は機能ブランチに対して行われます
7. すべての変更が機能ブランチに組み込まれると、機能ブランチは終了します：git flow feature finish module_1
8. developブランチがGitHubにプッシュされます（これが発生すると、GitHubはプルリクエストを自動的にクローズ/マージ済みとしてマークします）

通常、このプロセスはすべて元の作成者が行いますが、それは必須ではありません。私たちのチームの誰もが、いつでもこのプロセスに介入し、このプロセスを開始できます。彼らがしなければならないのは、機能ブランチをチェックアウトしてプロセスを続行することだけです。これまでにgit flow feature finish module_1を実行すると、ローカル機能ブランチの贅沢が削除されますが、ブランチをチェックアウトした他のユーザーは、git branch -D feature/module_1のようなものを使用する場合は手動でこれを実行する必要があります。

ホットフィックスについては、同様のアプローチを使用し、ホットフィックスを完了する前にGitHubでプルリクエストを作成します。

Answer 3

ここに別の提案があります。

1. 通常のgitフロープロセスを実行して機能を作成しますが、終了またはマージしないでください。
2. プルリクエストを作成、ただしマージしないでください。承認者がコメントを残すまで待ち​​ます。コメントは承認の印です。
3. git flow finishを実行します。 （チームの同意に応じて、承認者または開発者のいずれかがこれを行うことができます。）プルリクエストは、githubでマージ済みとしてマークされます。 Originのブランチを削除する必要があります。

Answer 4

コードレビューを行っている場合は、「公式」コードを含む中央リポジトリがあると想定します。開発者は、この中央リポジトリからプルおよびプッシュします。

Gerrit を使用すると、Gerrit自体が中央リポジトリになります（組み込みのSSHサーバーとHTTPサーバーがあり、ユーザーは基本的にはこれまでと同じように操作できます）。 Gerritを使用する場合、ワークフローは次のようになります。

1. 開発者はブランチに変更を加え、ローカルにコミットします。
2. 開発者はこれらの変更をGerritにプッシュします。
3. Gerritは、他のユーザーがレビューできるようにレビューアイテムを作成します。
4. ピアはコードをレビューし、コメントを作成し、コミットを承認または拒否します。
5. コミットが受け入れられると、thenGerritはそれらの変更を他のユーザーがブランチからプルできるようにします。

中央リポジトリを使用する場合、他の開発者はステップ2の後に送信された変更を確認できます。Gerritはコードレビューワークフローを導入しているため、他の開発者はステップ5の後で送信された変更のみを確認できます。

Gerritは任意のブランチで行われた変更のレビューをサポートしているため、これはgit-flow（または他の任意のブランチスキーム）でうまく機能します。