git-flowおよびgithubを使用したコードレビュー

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

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

私たちが抱えている問題はgit feature finish、ブランチを開発にマージする一方で、プルリクエストを送信し、チームの所有権を強調するためにコミッターではなくレビュアーによって（重要）マージされることです。

現在のソリューション：

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

これは、ブランチを自分で削除する必要があるというデメリット（git flow finishを行わないため）のプラクティスと一致しています。次のステップは、おそらくgitフローの一部を再実装し（主にgitコマンドのチェーンに関するものであるため）、これを考慮に入れます（マージのない仕上げの「クリーニング」部分を持つ）。

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

1. 機能ブランチを作成します。 git flow feature start module_1
2. コードは機能ブランチで更新されます
3. 変更がコミットされると、GitHubにプッシュされます（または、必要に応じて最後に1回）
4. 機能が完了すると、プルリクエストがGitHubで開かれdevelop、機能ブランチが比較されますmodule_1
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でプルリクエストを作成します。

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

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

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

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

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

別の提案があります。

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