Day 7・チーム開発の作法 — 規約・Gitフロー・レビュー・テスト・秘匿情報
ブランチ戦略とPR — 変更を安全に取り込む流れ
GitHubフローを基本に、ブランチ・プルリクエスト・コミット粒度を理解する。
なぜブランチを分けるのか
複数人が同じコードを同時に触ると、互いの変更がぶつかります。そこで、作業ごとに本流(main)から枝(ブランチ)を切り、そこで作業してから本流に取り込む、という流れをとります。この分岐と合流のルールを (ブランチ戦略)と呼びます。
GitHubフロー — シンプルな基本形
- main から作業用ブランチを切る(例: feature/order-service)
- そのブランチで実装し、意味のある単位でコミットする
- プルリクエスト(PR)を出し、レビューを受ける
- 承認されたら main にマージし、ブランチを削除する
GitFlowという、developやreleaseなど複数の恒久ブランチを使うより複雑な戦略もありますが、Webアプリの継続的なリリースには、main中心のGitHubフローが扱いやすく主流です。
# main を最新にしてから枝を切る
git switch main
git pull origin main
git switch -c feature/order-service
# 実装してコミット
git add app/Services/OrderService.php
git commit -m "注文処理をOrderServiceに切り出す"
# リモートに上げてPRを作成
git push -u origin feature/order-serviceなぜPR(プルリクエスト)を挟むのか
PRは『この変更を取り込んでよいか』を他人に確認してもらう仕組みです。直接mainに書き込むと、誰のチェックも受けずに壊れたコードが本流に入ります。PRを挟むことで、マージ前にレビューと自動テストを必ず通す関所を作れます。変更の意図を文章で説明する場にもなり、後から履歴として残ります。
コミットの粒度
粒度が悪いコミット
「いろいろ修正」という1コミットに、機能追加・バグ修正・整形が全部混ざっている。後から特定の変更だけを取り消せず、レビューも追えない。
粒度が良いコミット
「注文サービスを追加」「在庫チェックのバグを修正」のように、1つの意味ある変更で1コミット。メッセージで何をしたか分かり、必要なら個別に取り消せる。
コミットメッセージは未来の自分への説明
コミットメッセージは『何を』だけでなく『なぜ』が書けると価値が上がります。半年後に履歴を追う人(多くは自分)が、変更の理由を理解できるかを基準にします。
面接ではこう言う
「基本はGitHubフローで、mainから作業ブランチを切って、PRでレビューと自動テストを通してからマージします。直接mainに書かないのは、レビューとテストの関所を必ず通すためです。コミットは1つの意味ある変更ごとに分け、なぜ変えたかがメッセージから分かるようにしています」
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
作業をmainブランチに直接コミットせず、ブランチとPRを使う主な理由は?
コミットの粒度はどう分けるべきか、理由とともに説明してください。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。