前回の記事では、GitHubのブランチとプルリクエストの基本的な仕組みについて解説しました。

今回はその続きとして、プルリクエストを使ったレビューの進め方や、マージ方法の違い・よくあるトラブルとその回避方法を、より実務寄りの視点で整理していきます。

GitHubでチーム開発をしていると、

• レビューコメントってどう書くのが正解？
• 「Squash and merge」と「Merge commit」って何が違うの？
• コンフリクトが出たけど、どう対処すれば良いかわからない…

といった疑問や戸惑いがよく出てきます。

この記事では、僕が実際の現場で使っている運用イメージをベースに、小〜中規模チームでも無理なく回せるプルリク運用をイメージできるように解説していきます。

プルリクエストレビューの基本フロー

まずは、プルリクエスト（PR）のレビューがどのような流れで進むのか、全体像を簡単に整理しておきます。

1. 作業ブランチでコードを編集し、コミット・pushする
2. GitHub上でプルリクエストを作成する
3. レビューしてほしいメンバーを指定し、レビュー依頼を行う
4. コメント・修正を反映し、問題なければ承認（approve）してもらう
5. mainブランチへマージして作業完了

前回の記事では、プルリクエストの作成方法までを中心に解説しました。ここからは、プルリクエストを作る側・レビューする側、それぞれの目線でポイントを見ていきます。

プルリクを出す側のポイント

レビューのしやすさは、プルリクの説明の書き方で大きく変わります。僕は次の4点を書くことをおすすめしています。

• 目的：なぜこの変更を行ったのか（例：ログイン画面のデザイン調整）
• 変更内容：ざっくり何を変えたのか（例：ヘッダーの余白調整、ボタンの色変更 など）
• 動作確認内容：どの画面で、どの手順で確認したか
• レビューしてほしいポイント：特に気になる箇所や迷っている点

プルリクの説明欄に、例えばこんな感じで書いておくと親切です。

ここまで書いてあると、レビュワーは意図を理解したうえでコードを読めるので、結果的にレビューが早く・スムーズになります。

ドラフト（Draft）PRの活用

まだ作業途中だけど、「方向性が合っているか早めに見てもらいたい」というときは、Draft Pull Requestとして作成するのもおすすめです。

Draftで作っておくと、「まだマージはしないけれど、途中経過としてレビューしてほしい」という意思表示になります。大きめの機能開発をするときは、早めにドラフトPRを出しておくと安心です。

DraftはPR作成時に「Create draft pull request」を選択して作成
または、PR作成後にReviwersのセクションにある「Still in progress?Convert to draft」のリンクをクリックすることでdraftに切り替えることができます。

draftの解除の仕方は「Ready for Review」ボタンをクリックするとdraftを解除することができます。

レビューコメントと承認の進め方

次に、実際のレビューの進め方と、コメントの書き方のコツを見ていきます。

どこをチェックすればいい？レビューの観点

レビューと聞くと、つい「コードがキレイかどうか」だけを見てしまいがちですが、実務では次のような観点でチェックすると抜け漏れが減ります。

• 仕様：要件どおりの動きをしているか、想定外のケースがないか
• 影響範囲：他の画面や機能に影響が出ていないか
• 可読性：他の人が読んでも意図が分かるコードになっているか
• 保守性：今後の機能追加・修正に耐えられるか、無理な実装になっていないか

すべてを完璧に見るのは大変なので、「自分はこのPRでは仕様と影響範囲を重点的に見る」など、ある程度役割分担するのもアリです。

レビューコメントの書き方

レビューコメントを書くときに意識したいのは、人ではなくコードに向けてコメントすることです。

例えば、こんな書き方の違いがあります。

• NG例：
  「この実装はちょっとよくないですね。」
• OK例：
  「この処理だと、◯◯のケースでバグになる可能性がありそうです。
  例えば 〇〇() を使うと、△△のケースもカバーできそうですがどうでしょう？」

例はちょっと大袈裟ですが、指摘だけで終わらせず、相手が受け取りやすいように理由と代案を一緒に伝えるなどの工夫があると◎🙆

approve / request changes / comment の使い分け

レビューが終わったら、GitHub上で次のいずれかのステータスを選択します。

• Approve：マージして問題ない状態
• Request changes：修正してほしい点があり、いったんマージは保留
• Comment：情報共有や軽い提案レベル（マージ可否には影響しない）

チームによって運用は異なりますが、僕のいるチームでは、「Request changesが0、Approveが1以上」になったらマージOK、というルールにしていたりします。

マージ方法の違いと選び方

プルリクエストが承認されたら、最後はmainブランチへのマージです。GitHubでは、主に次の3種類のマージ方法が選べます。

① Merge commit

もっとも基本的なマージ方法です。作業ブランチのコミットをそのまま残しつつ、マージコミットという1つのコミットを追加してmainブランチに取り込みます。

履歴上は「マージされたこと」がはっきり分かる反面、コミットログがやや増えやすいデメリットもあります。

② Squash and merge

作業ブランチ側の複数コミットを、1つのコミットにまとめてからマージする方法です。

細かい「WIPコミット」や試行錯誤の履歴はPR内に残しつつ、mainブランチの履歴はスッキリさせたい、というときに便利です。

③ Rebase and merge

作業ブランチのコミットを、mainブランチの末尾に「付け替える」ようなイメージのマージです。履歴が一直線に並ぶため、コミットログを重視するチームでは好まれますが、使いこなすには少しGitの理解が必要になります。

小〜中規模チームではどれを選ぶ？

個人的には、最初のうちは「Squash and merge」を基本にするのをおすすめしています。

• mainブランチの履歴が「PR単位」で見やすくなる
• 細かいコミットはPR画面からたどれるので困らない
• コンフリクト対応などでコミットが増えても、最終的に1つにまとまる

もちろん、既に会社やチームでルールが決まっている場合はそれに従うのが第一ですが、これからGitHubを本格的に使い始めるという段階であれば、Squash and mergeベースで始めるのが扱いやすいかなと思います。

よくあるトラブルとその回避方法

最後に、GitHubでプルリク運用をしているとよく出てくるトラブルと、その回避方法をいくつか紹介します。

ケース① mainブランチとのコンフリクトが発生した

複数人が同時に開発していると、mainブランチの内容がどんどん変わり、プルリク作成時にコンフリクトが発生することがあります。

基本的な対処の流れは次の通りです。

1. ローカルで main ブランチを最新に更新する
2. 作業ブランチに main を取り込む（git merge main など）
3. コンフリクト箇所を手動で修正する
4. 改めてコミット・pushし、PR画面で「コンフリクト解消済み」になっていることを確認する

コンフリクトを減らすためには、長期間同じブランチで作業しない（PRを小さく・短くする）ことも重要です。

ケース② PRが大きくなりすぎてレビューが進まない

「1PRで画面3つ分の実装をまとめて出してしまう」など、プルリクが大きくなりすぎると、レビュワーは読むだけで一苦労です。結果としてレビューが後回しになり、開発も滞ってしまいます。

目安として、「1PR = 30分以内にレビューできる量」に収めると回しやすくなります。

• UI変更とロジック変更は分ける
• 環境設定の変更だけ先に分けてPRを出す
• 共通コンポーネントの切り出しだけを先に行う

といった工夫をすると、レビューの心理的ハードルがかなり下がります。

ケース③ 誰がいつマージするかで迷う

チームによって、「作った人がマージする」「レビュワーがマージする」などルールが分かれるポイントです。

僕のおすすめは、

• 原則：PR作成者がマージする
• ただし、本番リリースを伴うものはリリース担当がマージする

といった形で、通常時とリリース時で分ける運用です。

いずれにしても、「誰がマージボタンを押すのか」「本番反映のタイミングをどう合わせるのか」は、あらかじめチーム内で決めておきましょう。

ケース④ 誤ってマージしてしまった

誤ってマージしてしまった場合、Gitの操作で元に戻せるケースもありますが、操作を誤ると余計に状況が複雑になることもあります。

特に本番環境に影響するような変更を誤ってマージしてしまった場合は、無理に1人で戻そうとせず、チームメンバーに状況を共有した上で対処するのが安全です。

まとめ：小さなPRと丁寧な説明から始めよう

今回は、GitHubのプルリクエストにフォーカスして、

• プルリクレビューの基本フロー
• レビューコメントと承認の進め方
• マージ方法の違いと選び方
• よくあるトラブルと回避方法

をざっくりと整理してみました。

プルリク運用にはいろいろな流派がありますが、最初のうちは、

• PRはできるだけ小さく分ける
• 目的・変更内容・動作確認をPR本文に書く
• マージ方法は「Squash and merge」をベースにする

といったシンプルなルールから始めてみるのがおすすめです。

慣れてきたら、チームで定期的に振り返りをして、自分たちの開発スタイルに合ったプルリク運用へ少しずつアップデートしていきましょう。

この記事が、みなさんのチーム開発の参考になればうれしいです。

次回は「Squash and merge」についてもう少し掘り下げていきます。

ブログランキングに参加しています。クリックして応援していただけると嬉しいです。

人気ブログランキング

にほんブログ村