ディレクターが知っておくGitの範囲——ブランチ・プルリクエスト・レビューの流れ
ディレクターがGitのコマンドを覚える必要はあまりありません。ただ、ブランチ・プルリクエスト・レビューの3つが「何を決める場所か」を知っていると、進行と確認の精度が上がります。私が押さえている範囲を整理します。
ディレクターが知っておくGitの範囲は、ブランチ・プルリクエスト・レビューの3つが「それぞれ何を決める場所か」までで十分だと考えています。コマンドを打てなくても困りません。困るのは、「今どの変更がどこまで進んでいて、誰が何を承認すれば公開できるのか」が読めないことです。
私はディレクターとエンジニアを一人で往復してきたので、両方の立場で「ここが共有されていれば手戻りが減ったのに」という場面を何度も見てきました。この記事では、GitHubを使っている前提で、ディレクターが見る場所と聞くべきことに絞って書きます。
ブランチ：「作業の置き場所」を分けるもの
Gitの解説書Pro Gitでは、ブランチは特定のコミット（変更の記録）を指す、軽くて動かせるポインタだと説明されています。仕組みとしては軽いので、変更ごとにブランチを作るのが一般的な運用です。
ディレクター目線では、ブランチは**「公開中のもの」と「作業中のもの」を混ぜないための置き場所**と捉えると分かりやすいです。よくある構成は次のとおりです。
| ブランチ | 役割のイメージ |
|---|---|
| main（既定のブランチ） | 本番に出ている、または出してよい状態 |
作業用ブランチ（例：fix/contact-form） |
1つの修正・1つの機能だけを入れる場所 |
私が進行でよく聞くのは「この修正は、どのブランチに入っていますか」です。複数の修正が1本のブランチに混ざっていると、「Aだけ先に出したい」という判断ができなくなります。チケットとブランチを1対1にしておくと、公開の順番をディレクター側で組み替えやすくなります。
プルリクエスト：「この変更を入れてよいか」を相談する場所
GitHubの公式ドキュメントAbout pull requestsでは、プルリクエストはコードの変更をプロジェクトに取り込むための提案だと説明されています。変更の差分は「Files changed」タブで、説明やコメントの流れは「Conversation」タブで見られます。
ディレクターが見るべきなのは、コードよりも説明欄です。私はチームに、プルリクエストの説明に次の3点を書いてもらうようにしています。
- 何のための変更か（チケットへのリンク）
- 画面上で何が変わるか（スクリーンショットや確認用URL）
- 確認してほしいこと、まだ終わっていないこと
また、作業途中のものはドラフトのプルリクエストにしておけます。ドラフトは取り込み（マージ）ができない状態なので、「途中経過は見せたいが、まだ判断は求めない」という合図として使えます。進捗確認の場で「ドラフトが何本、レビュー待ちが何本」と数えるだけでも、状況がかなり見えてきます。
レビュー：「承認」と「修正依頼」を分けて返す
GitHubのAbout pull request reviewsでは、レビューの返し方として次の3つが説明されています。
- Comment：承認も修正依頼もせず、意見だけ残す
- Approve：取り込んでよい状態だと示す
- Request changes：取り込む前に対応してほしい点を示す
同じページでは、リポジトリの管理者が「取り込む前に承認を必須にする」設定ができることにも触れられています。私が案件の最初に決めておくのは、誰のApproveがあれば取り込んでよいかです。コードはエンジニア、文言や見た目はディレクターやデザイナー、と役割で分けておくと、「誰かが見たはず」で通ってしまう事故が減ります。
ディレクターがレビューに入るときは、コードの良し悪しではなく、確認用URLで「チケットに書いた目的どおりになっているか」を見るのが役割だと考えています。気になる点が公開を止めるほどでなければComment、止めるべきならRequest changes、と使い分けると、エンジニア側も優先度を判断しやすくなります。
流れを1枚にすると
全体をまとめると、次の順番になります。
- チケットを切る（目的と完了条件を書く）
- 作業用ブランチを作る
- ドラフトのプルリクエストで途中経過を共有する
- レビュー待ちにして、決めた担当者がApproveする
- mainに取り込み、公開する（戻し方はリリース前チェックリストで事前に決めておく）
この中でディレクターが主に関わるのは1・3・4です。2と5はエンジニアに任せつつ、「どのブランチに何が入っているか」だけは聞ける状態にしておく。それで進行の判断にはおおむね足ります。
明日から試せる一手
進行中の案件のリポジトリを開き、プルリクエスト一覧を「ドラフト」「レビュー待ち」「承認済み」に分けて数えてみてください。そのうえで、説明欄にチケットへのリンクと確認用URLがないものを1つ選び、エンジニアに「次からここに書いてもらえますか」と頼む。コマンドを覚えるより先に、この一言から始めると、Gitがディレクターにとっても読める道具になっていきます。