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

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

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

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

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

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 (インストール手順を更新)

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

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

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

ステップ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の作成方法は前回の記事を参照）

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

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

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

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

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

git checkout main

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

git branch -d feature/add-contact-form

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

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

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

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

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