ぽち先生と学ぶ IT基礎ノートGitHubでの共同開発
要点
- GitHubは、Gitのリポジトリをインターネット上で共有し、チームでの共同開発を助けるサービスです。
- 変更は「プルリクエスト」として提案し、他のメンバーの「コードレビュー」を経てから本流に取り込むのが基本の流れです。
- この仕組みにより、1人の思い込みで問題のあるコードがそのまま取り込まれるのを防げます。
ブランチ
リクエスト
（取り込み後）
リモートリポジトリの役割
Gitの履歴は各メンバーの手元（ローカル）にもありますが、それだけではチームとして1つの成果物にまとまりません。GitHubは、チーム共通の「リモートリポジトリ」を置く場所として使われ、各メンバーの変更を1箇所に集約する役割を持ちます。
🔑 身近な例クラウド上の共有フォルダのようなものです。各自が自分のPCで作業した内容を、最終的には同じ場所に集めて、チーム全員が同じ最新版を参照できるようにします。
プルリクエストとは
プルリクエスト（Pull Request、略してPR）とは、「この作業ブランチの変更を、mainに取り込んでください」とチームに提案する仕組みです。GitHub上で変更内容の差分をまとめて確認できます。
（完成）
を作成
まとめて提示
いきなりmainに変更を反映するのではなく、一度「提案」の形にすることで、他のメンバーが内容を確認する機会が生まれます。
コードレビューの流れ
プルリクエストが作成されると、他のメンバーがその内容を読み、コメントを付けたり、修正を依頼したりします。これを「コードレビュー」と呼びます。
🔑 身近な例企画書を1人で完成させて即提出するのではなく、「変更提案→みんなで確認→気になる点を指摘→反映」というプロセスを経てから正式版にする流れに似ています。第三者の目が入ることで、見落としに気づきやすくなります。
承認されてマージされるまで
レビューで指摘があれば、提案した本人が作業ブランチを修正し、再度確認してもらいます。これを繰り返し、レビュアーから「承認（Approve）」が得られたら、プルリクエストがmainにマージされます。
リクエスト
を繰り返す
（取り込み後）
この一連の流れがあることで、mainには「チームで確認済みの変更」だけが積み重なっていきます。
Issueで課題を管理する
GitHubには、バグ報告やタスクを記録しておく「Issue（イシュー）」という機能もあります。「何をやるべきか」を先にIssueとして整理し、それに対応するプルリクエストを作る、という進め方がよく使われます。
プルリクエストの説明に対応するIssue番号を書いておくと、「どの課題に対する対応か」がチーム内で分かりやすくなります。
🔑 身近な例チームのタスク一覧に「やること」を書き出しておき、担当者が着手したらその横に対応する成果物をひも付けていくイメージです。
まとめ
GitHubでの共同開発は、リモートリポジトリで変更を共有し、プルリクエストで提案し、コードレビューを経てからmainに取り込む、という流れが基本です。この仕組みによって、チーム全体の品質を保ちながら並行して開発を進められます。
関連トピック: