Git基礎 #6 GitHubと初めてのPull Request
第1回から第5回まで、ローカルリポジトリでコミットを積み、ブランチを分けてマージし、リモートリポジトリと同期し、ミスを取り消す方法まで揃えました。残るは最後のピースです。ひとりで使うGitとチームで使うGitの最大の違い、Pull Requestです。ブランチの変更をレビューを経て合流させるこの手順は、現代の開発コラボレーションの標準です。
全6回で構成します。
- #1 Gitとは — スナップショットモデルと3つの領域
- #2 add・commit・status — ステージングエリアの意味
- #3 ブランチとマージ — fast-forwardと3-way
- #4 リモートリポジトリ — clone・fetch・pull・pushとoriginの正体
- #5 取り消し — restore・reset・revertの使い分け
- #6 GitHubと初めてのPull Request ← この記事
この記事では、GitHubにリポジトリを作ってローカルリポジトリを接続し、初めてのPull Requestを開いてマージし、後片付けするところまで、全体の流れを順にたどります。
Pull Requestとは何か #
Pull Requestは名前のとおりリクエストです。「私のブランチの変更をこのブランチに取り込んで(pull)ください」という依頼で、略してPRと呼びます。ただし実務でのPRの価値は、マージ依頼そのものよりその上で起きることにあります。同僚が変更されたコードを行単位でレビューし、コメントで対話し、修正を反映してから合流させるレビューの場がPRです。
ひとつ区別しておくべき点があります。Pull RequestはGit自体の機能ではありません。git pull-requestというコマンドは存在しません。PRはGitHubというホスティングサービスがGitの上に載せた機能です。だからGitLabでは同じものをMerge Requestと呼びます。名前は違っても構造は同じです。ブランチ、コミット、プッシュはGitの領域で、レビューとマージボタンはホスティングサービスの領域です。
GitHubにリポジトリを作る #
第4回では、すでに存在するリモートリポジトリをcloneする流れを扱いました。今回は逆方向です。ローカルにすでにあるリポジトリをGitHubに新しく上げます。
GitHubにログインし、New repositoryボタンで新しいリポジトリを作ります。リポジトリ名だけ決めて、READMEと.gitignoreの追加オプションはすべて空のままにします。ローカルにすでにコミット履歴があるため、リモートは空の状態でないと衝突なしに上げられません。
リポジトリを作るとGitHubがアドレスを教えてくれます。このアドレスをoriginという名前で登録してプッシュします。
git remote add origin https://github.com/<アカウント>/<リポジトリ>.git
git push -u origin main-uオプションは第4回で扱ったとおり、ローカルのmainとリモートのmainを追跡関係で結ぶ設定です。一度設定しておけば、以降はgit pushだけで済みます。
初めてのPull Request — ブランチからマージまで #
それでは実際の作業の流れを最初から最後までたどります。シナリオはシンプルです。あいさつ機能をブランチで作り、PRで合流させます。
まずブランチを作って作業し、コミットします。
git switch -c feature/greeting
# greeting.py を作成
git add greeting.py
git commit -m "feat: あいさつ関数を追加"このブランチをリモートに上げます。初めて上げるブランチなので、ここでも-uを付けます。
git push -u origin feature/greetingプッシュ直後にGitHubのリポジトリページを開くと、上げたばかりのブランチに対してCompare & pull requestボタンが表示されます。このボタンを押すとPR作成画面に移動します。
作成画面の上部には方向が表示されます。baseが変更を受け入れるブランチで、compareが変更を送るブランチです。今はbaseがmain、compareがfeature/greetingです。この方向を確認する習慣をつけておくと、後で複数のブランチを行き来するときのミスを減らせます。
タイトルと説明を書きます。コツは2つです。タイトルには何をしたかを、説明にはなぜしたかを書きます。レビュアーはコードのdiffから何が変わったかは見えますが、なぜ変えたかは説明なしには分かりません。背景と意図を1〜2段落書くだけで、レビューの質が変わります。
レビューコメントと追加コミット #
PRを開くと同僚がコードをレビューします。修正依頼のコメントを受け取ったら、どう反映すればよいでしょうか。答えはシンプルです。同じブランチで修正してコミットし、もう一度プッシュするだけです。
# feature/greeting ブランチでコードを修正
git add greeting.py
git commit -m "fix: レビュー反映 - 空の名前入力を処理"
git pushPRはブランチを指しているため、そのブランチに新しいコミットをプッシュすると、開いているPRに自動で反映されます。PRを閉じて開き直す必要はありません。レビューコメント、修正コミット、再レビューがこの方式で繰り返され、承認が出たらマージの段階に進みます。
マージボタンの3種類 #
GitHubのマージボタンには3つの方式があります。
| 方式 | 動作 | 履歴 |
|---|---|---|
| Merge commit | マージコミットを作って2つの履歴を合流 | ブランチの痕跡がそのまま残る |
| Squash and merge | ブランチの全コミットをひとつにまとめて追加 | mainにコミットひとつだけ残る |
| Rebase and merge | ブランチのコミットをmainの上に順に再配置 | マージコミットなしの一直線 |
Merge commitは第3回で扱った3-wayマージと同じ動作です。Squash and mergeは「タイポ修正」「レビュー反映」のような細かいコミットが多いときに、mainの履歴をきれいに保つのに役立ちます。Rebase and mergeは一直線の履歴を好むチームが使います。
基礎段階での基準はシンプルです。チームの慣例に従うことです。すでに運用中のリポジトリなら、これまでのPRがどの方式でマージされてきたかを確認して同じ方式を使えば済みます。個人プロジェクトならどの方式でも問題ありませんが、コミットが散らかりやすい初期にはSquash and mergeが負担の少ない選択です。
マージ後の後片付け #
マージが終わったブランチは役割を終えたので、片付けます。GitHubがマージ直後に表示するDelete branchボタンでリモートブランチを削除し、ローカルも整理します。
git switch main
git pull
git branch -d feature/greetingmainに戻ってマージ結果をpullで受け取ると、ローカルのmainにもマージされたばかりの変更が反映されます。その後git branch -dでローカルブランチを削除します。第3回で扱ったとおり、マージが終わったブランチの削除はコミットを失わない安全な作業です。
ここまでがワンサイクルです。ブランチ作成からコミット、プッシュ、PR、レビュー、マージ、後片付けまで一周し、実務の一日はこのサイクルの繰り返しです。
シリーズ全体のまとめ #
6回分の要点を1行ずつ整理します。
- #1 Gitは変更履歴をスナップショットとして記録し、作業ディレクトリ、ステージングエリア、リポジトリという3つの領域で動作します。
- #2 addはスナップショットの候補を選ぶ作業で、commitは選んだものを記録として確定する作業です。
- #3 ブランチはコミットを指す軽量なポインタで、マージにはfast-forwardと3-wayの2方式があります。
- #4 originはリモートリポジトリのアドレスの別名で、pullはfetchとmergeの組み合わせです。
- #5 取り消しはコミット前のrestore、プッシュ前のamendとreset、プッシュ後のrevertで区別します。
- #6 Pull Requestはブランチの変更をレビューを経て合流させるコラボレーションの標準手順です。
まとめ #
このシリーズの目標は、Gitを初めて学ぶときに必要な最小限の地図を描くことでした。ここまでついてきたなら、ひとりでもチームでも、Gitで作業を記録して共有する基本は身についたはずです。
次のステップは実務の場面です。チーム規模に合ったブランチ戦略、rebaseとmergeの選択基準、interactive rebaseによるコミット整理、コンフリクトを構造的に理解して解決する方法といったテーマを扱う実務ワークフローシリーズを準備しています。以上でGit基礎シリーズを締めくくります。