第13回: レビュー指摘への対応と追加コミット — 「直す」だけでなく「やり取りを整える」ことも実務力

章: 第4章: チーム開発の実務フロー

プルリクエストは出して終わりではない

実務では、プルリクエストを出したあとにレビューコメントが返ってくるのが普通です。

ここで重要なのは、指摘を受けたときに感情的にならず、変更をより良くするための対話 として扱うことです。

レビューの目的は、書いた人を責めることではなく、コードの品質とチームの理解を上げることにあります。

よくあるレビュー指摘

• 命名がわかりにくい
• 責務が混ざっている
• テストが足りない
• エッジケースが考慮されていない
• 既存実装との整合性が弱い

こうした指摘は、実装者が悪いというより、1人では見落としやすい観点を補うためのものです。

指摘を受けたあとの基本フロー

1. コメント内容を正確に読む

2. 意図が不明なら確認する

3. 修正する

4. 追加コミットする

5. 何を直したか返信する

ここで大事なのは、黙って直して終わらないことです。レビューした側は「どこがどう変わったか」を把握したいので、返信もセットで考えます。

追加コミットは普通に発生する

レビュー後に次のようなコミットを積むことは珍しくありません。

git add .
git commit -m "fix: レビュー指摘に応じて入力チェックを整理"
git push origin feature/login-validation

同じブランチへ push すれば、既存のプルリクエストに変更が自動で追加されます。

つまり、プルリクエストは1回出して固定ではなく、レビューを通じて育てるものです。

実務で気をつけたいこと

• 指摘の意図を読まずに形だけ直さない
• 修正した内容を返信で共有する
• 反論が必要なら感情ではなく理由で返す
• 追加修正を別の無関係な変更に広げすぎない

レビュー対応が丁寧だと、コードだけでなくコミュニケーションの信頼も積み上がります。

レビューで強い人の特徴

実務では、実装力だけでなく、この対応力がかなり見られます。

チェックポイント: レビュー対応は「修正作業」ではなく「品質を上げる共同作業」だと捉えると振る舞いが安定します。

まとめ & 次のステップ

• プルリクエストはレビュー後に追加修正されるのが普通
• コメントは品質向上のための対話として受け止める
• 修正後は追加コミットして同じブランチへ push すればよい
• 何を直したかを返信することも実務では重要
• 実装力と同じくらいレビュー対応力も評価される

次回はフォーク運用の基本を扱います。 自分に書き込み権限がないリポジトリでは、Gitの流れがどう変わるのかを整理します。