チーム開発の流れ——Pull Request
GitHubなどのホスティングサービスを使うと、Gitの履歴管理にレビューという工程が加わります。clone→ブランチ→push→Pull Request→レビュー→mergeという王道の流れと、コンフリクトの正体・解消手順、fetchとpullの関係まで、チームでの開発サイクルの全体像をつかみます。
ここまでで学んだGitのコマンドは、基本的に自分のパソコンの中で完結する話だった。だが実際のチーム開発では、複数人が同じリポジトリに向かって変更を提案し合う。この橋渡しをするのが GitHub のようなホスティングサービスと、その上に乗る Pull Request（プルリクエスト）という仕組みだ。
Pull Request は日本語にすると「取り込みの依頼」に近い。「自分がこのブランチで作った変更を、あなたのブランチに取り込んでください」という提案そのものを指す。略してPRと呼ばれることが多い。似た仕組みにMerge Requestという呼び方もあるが、指しているものはほぼ同じだ。
🔁 王道の開発フロー
チーム開発の典型的な流れは、次のような順序で進む。
まず git clone でリポジトリを手元に複製する。次に、mainを直接触らず git switch -c feature/xxx のように作業用のブランチを新しく作る。ここで初めて自分の変更を積み始める。
作業が一段落したら git push -u origin feature/xxx でリモートに送る。その後、GitHubの画面上で「Pull Requestを作成」し、変更内容と目的を書いて提出する。
レビュアーがコードを確認し、必要なら「ここを直してほしい」とコメントを付ける。提出者は指摘に応じて同じブランチに追加のコミットをpushし、Pull Requestの内容が自動的に更新される。問題なければ承認され、merge（取り込み）が実行されてmainに反映される。
レビューでは、コードの正しさだけでなく「読みやすいか」「他の実装と一貫しているか」「テストは足りているか」といった観点でも指摘が入ることが多い。指摘は攻撃ではなく、品質を一緒に上げるための対話だと捉えると気が楽になる。
⚔️ コンフリクトの正体
複数人が同じファイルの同じ場所を別々に変更していると、mergeの際に「どちらを採用すればいいか自動では判断できない」状態になる。これがコンフリクト（衝突）だ。
コンフリクトが起きると、該当ファイルの中に次のようなマーカーが挿入される。
<<<<<<< HEAD から ======= までが「今いる側（多くの場合mainや取り込み先）」の内容、======= から >>>>>>> ブランチ名 までが「取り込もうとしている側」の内容を示す。
解消の手順は、マーカーで挟まれた部分を見比べ、最終的にどう書くべきかを決めて、マーカー行（<<<<<<<・=======・>>>>>>>）ごと削除して正しい内容だけを残す。そのあとファイルを git add し、コミットすればコンフリクトの解消が完了する。
🔄 fetchとpullの関係
リモートの最新状態を手元に取り込むコマンドとして git pull を学んだが、これは実は2つの操作をまとめたショートカットだ。
git fetch は、リモートの最新情報を手元に「持ってくるだけ」で、自分の作業ブランチには反映しない。git pull は、この fetch のあとに自動で merge（場合によってはrebase）まで行う。
🧩 小さく出す・こまめに取り込む
Pull Requestは、1つに大きな変更を詰め込むほどレビューが大変になり、コンフリクトのリスクも増える。逆に、1つの目的にしぼった小さいPull Requestは、レビューする側も理解しやすく、承認までのスピードが上がる。
チーム開発は、コマンド操作そのものよりも、この「小さく出して、早くレビューをもらい、こまめに取り込む」というリズムづくりが本質だ。ここまでのGitの基本操作は、すべてこのリズムを支えるための道具になる。
最初は大きな機能を1つのPull Requestにまとめたくなるものだが、慣れてきたら「これは分けられないか」と一呼吸置いて考えるとよい。小さな提案の積み重ねのほうが、結果として開発全体のスピードは上がっていく。
🔒 mainブランチを直接守る仕組み
多くのチームでは、main ブランチに誰でも直接pushできないよう設定されている。これはブランチ保護（branch protection）と呼ばれる仕組みで、「必ずPull Requestとレビューを経由させる」ことをGitHub側の設定で強制するものだ。
この設定があると、うっかりmainに直接コミットしてpushしようとしても、ホスティングサービス側で拒否される。個人のミスをシステムの仕組みで未然に防ぐ、チーム開発ならではの安全策だ。
🤖 CIとレビューの関係
Pull Requestを作成すると、多くのプロジェクトで自動テストやコード検査（CI、継続的インテグレーション）が同時に走る。テストが通ったかどうかは、Pull Requestの画面上にチェックマークやバツ印として表示される。
レビュアーは、この自動チェックの結果も参考にしながら確認を進める。人間の目視と自動テストの両方が揃って初めて、安心してmergeに進めるという二重の安全網になっている。
📝 良いPull Requestの書き方
Pull Requestを作成する際、タイトルと説明文をどう書くかでレビューの速さが変わる。「何を」「なぜ」変更したのかが一目で分かる説明を添えると、レビュアーは背景を理解する時間を節約できる。
🌱 初めてのPull Requestに向けて
初めてPull Requestを出すときは緊張するものだが、レビューでの指摘は「直せば良くなる」ためのフィードバックであって、否定ではない。小さな変更から始めて、レビューのやり取り自体に慣れていくのがおすすめだ。