協業 — Pull Request とコードレビュー
チームでは誰も main に直接しません。 → → → レビュー → 。あらゆるソフトウェアチームがこの流れで動きます。
学習目標
- ブランチ → PR → レビュー → マージの流れを回せる
- レビューしやすい Pull Request を書ける
- 他人のプロジェクトに貢献する の流れを知る
チームでは main ブランチに直接コミットしません。ブランチを作って作業し、に上げてから Pull Request（PR）を開き、「この変更を取り込んでほしい」と依頼します。レビュアーが見て意見を残し、通れば取り込まれます。 も GitLab も同じ流れで、これから入るほとんどの会社もこう働いています。
PR はを検査される場ではなく、意図を共有する場です。タイトルに何をしたか、本文になぜ必要かとどう確認したかを書けば、レビューはずっと速くなります。そして PR は小さいほど良いです。300行ほどを超えるとレビュアーは丁寧に見るのが難しくなり、そのまま承認してしまいがちです。
レビュー意見を受けたら、そのブランチにコミットを足して再度 push すれば PR は自動で更新されます。他人の公開に貢献するときは、そのリポジトリを自分のアカウントに fork し、自分の fork でブランチを作って元のリポジトリへ PR を送ります。gh コマンド（GitHub ）を使えば、から出ずに PR を作り、一覧を見て、取得できます。
やさしく理解する
Pull Request は、宿題を教室の壁に貼り出す前に見てもらうために提出するようなものです。チームの仲間が変更を読んで意見を残し、承認を受けてから初めて main にマージされます。
このステップで覚えるコマンド
目で読むだけでなく、実際にターミナルで打ってみてください。手が覚えて初めて実務で出てきます。
git switch -c fix/session-expiry- 作業用のブランチを開きます。何の作業か分かる名前にします。
git push -u origin fix/session-expiry- ブランチをリモートに上げ、PR を開けるようにします。
gh pr create --fill- ターミナルから PR を作ります。タイトルと本文をコミット内容で埋めます。
gh pr checkout <number>- 他人の PR を自分の PC に取得し、実際に動かしてから承認します。
よくある失敗と直し方
互いに関係のない変更をたくさん詰め込んだ巨大な Pull Request を1つ開いてしまう失敗です。レビュアーがしっかり読めず、ミスがすり抜けます。Pull Request 1つには目的を1つだけにし、変更が大きくなったら小さなブランチに分けます。
自分で記録する欄です。ここで採点はしません。
この段階を理解したものとして記録しますか？
まだ取り消せないので、本当に理解できたときだけ記録してください。
理解したものとして記録しました
自分で記録する欄です。ここで採点はしません。