GitHubで複数人とブランチ運用する基本ルールと命名法

これまでのシリーズで、GitHubの基本的な使い方から、`Fork`と`Pull Request`を利用した共同開発への貢献方法までを学んできました。個人での開発や、オープンソースへの貢献はもう怖くありませんね。

シリーズ最終回となる今回は、チームでの開発を円滑に進めるための「ブランチ運用」に焦点を当てます。複数人が同じリポジトリで作業する時、何のルールもないとあっという間に混乱してしまいます。全員が同じ方向を向いて効率的に開発を進めるための、基本的なブランチの運用ルールと、分かりやすい命名規則を学び、チーム開発の達人を目指しましょう！

個人サイトでもブランチは必要？

ブランチ運用というとチーム開発だけの話に見えますが、個人でWebサイトを運営している場合にも役立ちます。特に、公開中のサイトを修正する時は「すぐ公開してよい小さな変更」と「試してから公開したい変更」を分けるだけで事故を減らせます。

GitHubへpushする基本の流れがまだ曖昧な場合は、先にgit pushの使い方とgit addとcommitの違いを確認しておくと、このページのブランチ操作が理解しやすくなります。

なぜブランチ運用ルールが必要なのか？

もしチーム内でブランチの作成ルールがなかったら、どうなるでしょうか？

Aさんは`feature-A`、Bさんは`fix-B`、Cさんは`sato-branch`といったように、各自が自由な名前でブランチを作成し始めます。これでは、どのブランチが何の作業をしているのか、誰にも分からなくなってしまいます。結果として、不要なブランチが乱立し、マージミスが頻発し、開発は混乱を極めるでしょう。

このようなカオスを防ぎ、開発をスムーズに進めるために、チームで共有するシンプルな「ブランチ運用ルール（ブランチ戦略）」が必要不可欠なのです。有名なブランチ戦略には「Git-flow」などがありますが、まずはもっとシンプルな「フィーチャーブランチワークフロー」の基本を覚えれば十分です。

基本的なブランチの種類と役割

シンプルなチーム開発では、主に2種類のブランチを使い分けます。それぞれの役割をしっかり理解しましょう。

• `main`ブランチ (旧`master`ブランチ)

  これは「常に正常に動作する、本番環境のコード」を保管しておくための、神聖なブランチです。このブランチが直接編集されたり、不安定なコードが混入したりすることは絶対に避けなければなりません。

  【ルール】: `main`ブランチには、誰も直接コミットやプッシュをしてはいけません。すべての変更は、後述するフィーチャーブランチからPull Requestを通じてマージされるべきです。

• フィーチャーブランチ (Feature Branch)

  これは、新しい機能の開発、バグの修正、ちょっとした改修など、特定のタスクを行うために作成される作業用のブランチです。「トピックブランチ」とも呼ばれます。`main`ブランチから枝分かれさせ、作業が完了したら`main`ブランチに合流（マージ）させます。作業が終われば削除される、短命なブランチです。

  【ルール】: どんなに小さな修正でも、必ず新しいフィーチャーブランチを作成してから作業を始めましょう。

分かりやすいブランチの命名規則

フィーチャーブランチを誰が見ても分かるようにするためには、一貫性のある命名規則が重要です。一般的には「`プレフィックス/作業内容`」という形式がよく使われます。

プレフィックスの種類と具体例:

• feature/: 新しい機能を追加する場合
  • 例: feature/add-login-page (ログインページの追加)
• fix/: バグを修正する場合
  • 例: fix/correct-header-layout-bug (ヘッダーのレイアウト崩れを修正)
• refactor/: 機能を変えずにコードの品質を向上させる（リファクタリングする）場合
  • 例: refactor/optimize-database-query (データベースのクエリを最適化)
• docs/: ドキュメント（README.mdなど）を修正する場合
  • 例: docs/update-installation-guide (インストール手順を更新)

このようなルールをチームで共有しておけば、ブランチ名を見るだけで、そのブランチが何をしているのかが一目瞭然になります。

Webサイト運営で使いやすいブランチ名の例

Web制作では、機能開発だけでなく、記事修正、SEO改善、公開前チェック、緊急修正などもブランチに分けられます。作業内容がすぐ伝わる名前にしておくと、あとから履歴を見返しやすくなります。

AIに修正してもらう作業では、ブランチ名にai/やreview/を入れておくと、「まだ人間が確認する前の変更」と区別しやすくなります。公開前チェックの考え方はAIコード修正と公開前チェックの入口でも整理しています。

実践！チーム開発の基本的な流れ

それでは、これらのルールに基づいたチーム開発の基本的な流れを、コマンドと共に見ていきましょう。

ステップ1: 最新の`main`ブランチを取得する

作業を始める前には、必ずローカルの`main`ブランチを、リモートリポジトリの最新の状態に更新します。まず`main`ブランチに移動します。

git checkout main

次に、リモートの最新情報をローカルに持ってきます。

git pull origin main

ステップ2: 作業用のフィーチャーブランチを作成する

最新の`main`ブランチから、あなたの作業用のブランチを作成します。今回は「お問い合わせフォームを追加する」という想定でブランチを作成してみましょう。

git checkout -b feature/add-contact-form

ステップ3: 修正・開発を行い、コミットする

新しく作成したブランチで、心ゆくまでコードの修正や追加を行います。作業がある程度まとまったら、コミットを作成します。

git add .

git commit -m "Add basic structure of contact form"

ステップ4: リモートリポジトリにプッシュする

作成したフィーチャーブランチを、リモートリポジトリにプッシュします。これで初めて、あなたの作業内容がチームメンバーにも見えるようになります。

git push origin feature/add-contact-form

ステップ5: Pull Requestを作成し、レビューを受ける

プッシュが完了したら、GitHub上で`main`ブランチに対してPull Requestを作成します。チームメンバーにコードレビューを依頼し、フィードバックをもらいましょう。（Pull Requestの作成方法は前回の記事を参照）

マージ前に確認すること

Pull Requestを作ったら、すぐにマージせず、最低限の確認をします。個人運営でも、この確認を挟むだけで「壊れた状態をmainに入れる」事故を減らせます。

git status
git log --oneline --graph --decorate -5

• 不要なファイルや秘密情報が混ざっていないか
• 変更内容が1つの目的にまとまっているか
• ローカルで表示確認や構文チェックをしたか
• 公開後にアップロードが必要なファイルを把握しているか

履歴の見方に慣れていない場合は、git logの基本を先に確認しておくと、ブランチの流れを追いやすくなります。

# いまのブランチを確認
git branch --show-current

# 変更されたファイルを見る
git status

# まだcommitしていない差分を見る
git diff

# commit済みの履歴を見る
git log --oneline -5

# mainとの差分を見る
git diff main...HEAD --name-only

ステップ6: マージ後、不要になったブランチを削除する

Pull Requestが無事にマージされたら、その作業に使ったフィーチャーブランチはもう不要です。リポジトリを綺麗に保つために、削除しておきましょう。

まず、リモートブランチを削除します。これは通常、GitHubのPull Requestページでマージ後に表示される「Delete branch」ボタンを押すだけで完了します。

[画像：マージ後に表示される「Delete branch」ボタン]

次に、ローカルに残っているブランチも削除します。まず`main`ブランチに戻りましょう。

git checkout main

そして、不要になったローカルブランチを削除します。

git branch -d feature/add-contact-form

これで一連のサイクルが完了です。また新しい作業を始めるときは、ステップ1から繰り返します。

ブランチ運用でよくある失敗

ブランチは便利ですが、使い方を間違えると逆に混乱します。最初は次の失敗だけ避ければ十分です。

間違えてコミットした、戻したい、すでにpushしてしまった、という場合はGitで変更を取り消す基本を確認してください。共有済みの履歴を消す操作は、チームや公開運用では慎重に扱います。

Gitブランチ運用について相談したいです。

やりたい作業:
触る予定の範囲:
現在のブランチ:
mainへ入れる予定:
- すぐ入れる
- レビュー後に入れる
- まだ入れない

確認済み:
- git status:
- git branch --show-current:
- git diff main...HEAD --name-only:
- PHP/JS/表示確認:
- 本番アップロードが必要なファイル:

相談したいこと:
- ブランチを切るべき作業か
- 作業範囲が広すぎないか
- mainへ入れる前に何を確認すべきか
- 戻すなら restore / revert / ブランチ破棄 のどれがよいか

伏せる情報:
- GitHubトークン
- パスワード
- .envやDB設定ファイルの中身
- 非公開リポジトリURLの必要以上の情報

まとめ：シンプルなルールがチームを救う

複数人での開発を成功させる秘訣は、複雑なルールを覚えることではなく、**全員がシンプルなルールを守り続けること**にあります。今回紹介した基本ルールをチームで徹底するだけで、開発効率は格段に上がり、余計なトラブルを避けることができます。

• mainブランチは常に保護する。
• 作業は必ずフィーチャーブランチで行う。
• 分かりやすい命名規則を徹底する。
• mainへの合流は必ずPull Requestで行う。
• マージ済みのブランチはこまめに削除する。

このGitHub入門シリーズで、あなたはアカウント作成から共同開発の基本フローまでを学びました。これはWeb制作者として大きな一歩です。ここで得た知識を土台に、ぜひ実際のプロジェクトでGitとGitHubを活用してみてください。あなたの開発ライフが、より快適で創造的になることを願っています！

関連して確認したいGitページ

• git pushでGitHubへ反映する手順
• ForkとPull Requestの流れ
• GitHubコードレビューの基本
• git logで履歴を確認する
• Gitで変更を取り消す基本
• GitHubに初めてpushする手順
• AIコード修正と公開前チェックの入口
• 症状から探すHTMLサイトマップ