導入
チーム開発では、main に直接 push するのではなく、プルリクエスト（Pull Request, PR） を通して変更をレビューしてもらってから取り込むのが一般的です。GitHub の中心的な機能で、GitLab では「マージリクエスト」と呼ばれます。
説明
典型的な流れは次のとおりです。
flowchart TD
A["main から feature ブランチを作る"] --> B["feature で作業してコミット"]
B --> C["feature を push する"]
C --> D["GitHub で Pull Request を作る"]
D --> E["レビュー・修正のやり取り"]
E --> F["承認されたら main にマージ"]
F --> G["feature ブランチを削除"]
PR が重要なのは、コードが main に入る前に次のことができるからです。
- レビュー：他の人が変更を読み、指摘やコメントを付けられる。
- 自動チェック：後述の CI（第5章）が自動でテストを回し、壊れていないか確かめる。
- 記録：なぜこの変更を入れたのか、議論の経緯がすべて残る。
main を常に「動く状態」に保ちながら、変更は必ず一度レビューの目を通す――この規律が、大人数でも壊れない開発を支えます。
まとめ
- 直接
mainを触らず、ブランチ＋PR で進める。 - PR はレビューと自動チェックの入り口。
- 承認されたらマージし、使い終えたブランチは削除する。