前回（Day 38）は、チーム開発の絶対的品質ゲートである「Pull Request（PR）の仕組みとGitHub Flowの実践」を学びました。
そして本日のDay 39では、PRの真価を引き出す【コードレビューの実践と3つのマージ方式の選び方】を徹底マスターします！
30年選手のベテランエンジニアからよくいただくお悩みがこちらです：
「SVN時代は、席まで歩いていって口頭で『あそこ直しといて』と伝えるか、ソースコードを印刷して赤ペンで直していた。なぜGitHubの画面上でわざわざ1行ずつコメントしなければならないんだ？ それに、いざPRをマージしようとすると緑のボタンに『Create a merge commit』『Squash and merge』『Rebase and merge』と3つも選択肢があるが、一体どれを選べば正解なんだ？！」
お気持ちはとてもよく分かります。しかし、GitHubのインラインレビューと適切なマージ方式を味方につければ、手戻りゼロの爆速レビューと、10年後もバグ原因を瞬時に特定できる超綺麗なコミット履歴が手に入ります！
本講義では、C#開発現場でのリアルなレビュー指摘例や「Suggest changes」の革新的な活用法、そして絶対に失敗しないマージ戦略を徹底的に解き明かします！
① なぜGitHubのインラインレビューが最強なのか？ SVN口頭・メールとの決定的な差
Subversion（SVN）やVSSの時代、コードレビューは「開発者の席に集まって画面を指差す」「メールやチャットでファイル名と行番号を送る」「印刷した紙に赤ペンを入れる」といった属人的な手法が主流でした。
従来型レビューが引き起こす「3つの大問題」
これらの従来手法には、チーム開発において致命的な弱点がありました：
- 問題1: 行番号のズレと文脈消失
「UserController.csの45行目の変数を直して」とメールで指示されても、別の修正が入った瞬間に45行目は52行目にズレます。どのコードに対する指摘なのかレビュイー（作成者）が探す時間だけで膨大なロスが発生します。 - 問題2: 議論と修正理由が散逸する
なぜその修正が必要だったのか、誰の指示でどう変更されたのかがメールボックスや口頭の記憶の中に消えてしまい、半年後の障害調査で「なぜこんなコードになっているのか」誰も分からなくなります。 - 问题3: 品質保証の責任証跡（Approve）がない
「口頭でいいよと言った」「いや言っていない」という水掛け論が発生し、最終的に誰が責任を持って本番リリースを承認したのかが記録に残りません。
GitHubの「3つのレビュー判定」
GitHubのPull Requestでは、変更差分（Files changed）の該当行を直接クリックしてインラインコメントを投稿できます。さらにレビュー完了時には以下の3つの明確なステータスで意思表示を行います：
- Comment（一般的なコメント）: 承認でも却下でもなく、質問や補足情報、軽いアドバイスを伝える場合。マージのブロックは行いません。
- Approve（承認 / 通称LGTM）: コード品質に問題がなく、mainブランチへのマージを正式に許可する判定。チーム開発の必須条件となります。
- Request changes（修正要求）: 重大なバグ、命名規則違反、設計ミスがあり、修正されるまでマージをブロック（禁止）する強力な判定。
② GitHubの革新機能「Suggest changes」とC#現場の実践例
GitHubのコードレビューで最も生産性を爆発させる機能が「Suggest changes（変更提案）」です。
従来の「〇〇を△△に変更してください」というテキストコメントではなく、レビュアーが「修正後のコード」をそのまま提示できます。
作成者は「Commit suggestion」を1クリックするだけ！
レビュアーがレビュー入力欄の「+/-」アイコン（Add a suggestion）を押して修正コードを書くと、PR画面上で差分プレビューが表示されます。
PR作成者（レビュイー）は、その提案に納得したら「Commit suggestion」ボタンを1クリックするだけで、GitHubが自動的に修正コミットを作成してPRブランチに追加してくれます！
ローカルでエディタを開いて、タイポを修正して、コミットしてpushする…という一連の手間がすべてゼロになります。
C#現場でよくあるレビュー指摘例
- private int m_retryCount; // C++や古参コードで見られるハンガリアン記法
+ private int _retryCount; // 現代のC#コーディング標準（先頭アンダースコア）
// 【CASE 2: LINQの無駄なメモリ割り当ての指摘】
- var activeUsers = users.Where(u => u.IsActive).ToList().Count(); // 無駄なList実体化
+ var activeUsers = users.Count(u => u.IsActive); // メモリ割り当てゼロ
③ 徹底比較！GitHubの3大マージ方式と現場のベストプラクティス
PRが全員からApproveされ、CIテストが通過したら、いよいよmainブランチへのマージです。
GitHubの「Merge pull request」ボタンの右側にある下向き矢印をクリックすると、3種類のマージ方式が選択できます。
3大マージ方式の仕組みとメリット・デメリット
① Create a merge commit（マージコミット作成）
ブランチ内のすべての個別コミットをそのまま保持し、2つの親を持つ「マージコミット」を作成して合流させます。
- メリット: 作業経緯の全コミットが100%完全保存される。ブランチの分岐と合流が視覚的に追える。
- デメリット: 作業中の「typo修正」「あ」「テスト」といった不要な泥臭いコミットまでmainに永久に残り、履歴グラフがクモの巣状に複雑化する。
② Squash and merge（スカッシュマージ）【★現場推奨・王道】
デファクト標準作業ブランチ内の複数のコミットを「たった1つのコミット」にギュッと圧縮（Squash）してmainブランチの先端にマージします。
- メリット: mainブランチの履歴が「1つのPR＝1つのコミット（例:
ユーザー認証機能の実装 (#123)）」として極めて美しく整理される。障害発生時の原因特定（git bisect）や切り戻し（git revert）がワンコマンドで安全に行える。 - デメリット: ブランチ内の個別の途中コミット日時は失われる（ただしPR画面上に元コミットのログは残るため実務上の問題はほぼゼロ）。
③ Rebase and merge（リベースマージ）
ブランチのコミットをmainブランチの最新先端に線形に並べ替えて追加します。マージコミットは作成されません。
- メリット: 分岐のない完全な1本道のコミット履歴（Linear History）が作られる。
- デメリット: マージコミットが存在しないため「どこからどこまでが1つのPRだったのか」の境界がコミットログから見えにくく、PR単位での一括revertが困難になる。
④ レビュー指摘を受けた後の正しい作法：コミット追加と再プッシュ
レビューで先輩や同僚から修正依頼（Request changes）をもらった際、初心者が最もやってしまいがちな「絶対NGの行動」があります。
それは、「指摘を直したあと、既存のPRをクローズして新しいPRを作り直してしまうこと」です！
なぜPRを作り直してはいけないのか？
新しいPRを作り直してしまうと、それまで交わされた議論の履歴、指摘の背景、コメントのやり取りがすべて別ページに分断され、レビュアーは「前の指摘がどう直されたのか」を照合するために2つのPRを行き来しなければならなくなります。
レビュー指摘を修正する「黄金の5ステップ」
- ① 指摘の確認: PRのタイムラインでコメントを確認し、不明点があればPRの返信欄で質問・対話する。
- ② ローカルで修正: Visual Studioで同じフィーチャーブランチを開き、C#コードを修正して単体テストを実行する。
- ③ コミット＆push: 修正内容をコミットし、同じリモートブランチへそのまま
git pushする。
※GitHubのPull Requestは、同一ブランチへの最新pushを自動検知して差分を瞬時に自動更新します！ - ④ 会話を解決（Resolve conversation）: コメント欄の「Resolve conversation」ボタンをクリックし、修正完了をレビュアーに明示する。
- ⑤ Approve＆Squashマージ: レビュアーが「Changes since last review（前回のレビュー以降の差分）」を確認し、ApproveしたらSquash and mergeで安全に合流！
📌 本日の講義まとめ & 明日からの実践指針
- インラインレビューの威力: 口頭・メールの「行ズレ」「散逸」から脱却し、該当行へのピンポイント指摘と永続ログを残す。
- Suggest changesの活用: 小さな修正提案はMarkdownでコードを提示し、作成者が「Commit suggestion」1クリックで反映する。
- 3大マージの使い分け: 通常の機能開発・バグ修正は履歴が美しく切り戻しが容易な「Squash and merge」が圧倒的推奨。
- 指摘修正のルール: 新しいPRは絶対に作らない！ 同じブランチに修正コミットを追加pushしてResolve conversationを行う。
- C#品質の向上: 命名規則（_prefix）やLINQのメモリ確保など、チームのコーディング規約をレビューを通じて定着させる。
🚀 次回予告【Day 40】
次回は、mainブランチへの事故を物理的に防ぐ【ブランチ保護ルール（Branch Protection）と必須ステータスチェック】をお届けします！
「1人以上のApproveがないとマージボタンを押せない設定」「CI自動テストが通らないとブロックする設定」「管理者でも迂回させない鉄壁のルール」など、GitHubを最強の品質砦に仕立て上げる設定テクニックを完全網羅します。お楽しみに！
コメント
コメントを投稿