Cohorz Dev

チーム開発で役立つブランチ戦略

公開日：December 14, 2024更新日：December 14, 2024
Git📄

これまでの章では、リモートリポジトリの基本操作や、ローカル環境でのリモートリポジトリの立て方などを学びました。この章では、いよいよチーム開発を効率的に進めるための、ブランチ戦略について解説していきます！

複数人で開発を行う場合、全員が同じブランチで作業をしていると、変更の競合（コンフリクト）が頻繁に発生したり、誰の変更が原因で問題が発生したのか特定するのが難しくなったりと、様々な問題が生じます。

しかし、適切なブランチ戦略を採用することで、これらの問題を回避し、スムーズに開発を進めることができます。

1. ブランチモデルって何？ ​

ブランチモデルとは、チーム開発におけるブランチの運用ルールを定めたものです。代表的なブランチモデルとしては、Git-flow や GitHub flow などがあります。これらのモデルを参考に、プロジェクトの規模や性質、チームの文化などに合わせて、最適なブランチ戦略を策定することが重要です。

1.1 Git-flow: 王道の開発フロー ​

Git-flow は、Vincent Driessen 氏によって提唱された、比較的厳格なブランチモデルです。以下のような複数のブランチを使い分けて、開発を進めます。

  • main ブランチ: リリース可能な状態のコードを常に維持する、最も重要なブランチ。
  • develop ブランチ: 開発の主軸となるブランチ。main から分岐され、機能開発やバグ修正など、すべての変更はこのブランチにマージされます。
  • feature ブランチ: 新しい機能を開発するためのブランチ。develop から分岐され、開発が完了したら develop にマージされます。ブランチ名は feature/ で始めます。（例：feature/new-login-form）
  • release ブランチ: リリースの準備を行うためのブランチ。develop から分岐され、リリースの準備（バージョン番号の更新、最終的なテストなど）を行います。準備が完了したら、main と develop にマージされます。ブランチ名は release/ で始めます。（例：release/1.0.0）
  • hotfix ブランチ: リリースされた製品に緊急のバグが見つかった場合に、修正を行うためのブランチ。main から分岐され、修正が完了したら main と develop にマージされます。ブランチ名は hotfix/ で始めます。（例：hotfix/critical-bug-fix）

Git-flow は、厳格なルールに基づいて運用されるため、大規模なプロジェクトや、リリースの頻度が低いプロジェクトに適しています。

1.2 GitHub flow: シンプルでモダンな選択肢 ​

GitHub flow は、GitHub 社が提唱する、よりシンプルで柔軟なブランチモデルです。Git-flow よりもルールが少なく、迅速な開発サイクルを実現できます。

  • main ブランチ: Git-flow と同じく、常にデプロイ可能な状態を維持します。
  • トピックブランチ: 新しい機能の開発やバグ修正など、すべての変更は main から分岐されたトピックブランチで行われます。ブランチ名は、変更内容がわかりやすい名前を自由に付けます。（例：add-new-feature, fix-login-bug）

GitHub flow では、トピックブランチでの作業が完了したら、main ブランチにプルリクエストを作成し、レビューを経てマージされます。

GitHub flow は、シンプルで柔軟性が高いため、小規模から中規模のプロジェクトや、Web サービスなど、継続的にデプロイを行うプロジェクトに適しています。

1.3 あなたに合ったモデルを見つけよう ​

Git-flow と GitHub flow は、どちらも優れたブランチモデルですが、それぞれにメリットとデメリットがあります。

Git-flow は、厳格なルールによって、安定した開発を実現できますが、運用が複雑になりがちです。一方、GitHub flow は、シンプルで迅速な開発が可能ですが、ある程度の自己管理能力が求められます。

どちらのモデルが優れているというわけではなく、プロジェクトの性質やチームの文化に合わせて、最適なモデルを選択することが重要です。また、これらのモデルをベースに、独自のルールを追加したり、簡略化したりして、自分たちに合ったブランチ戦略を構築することも有効です。

2. プルリクエストで安全にマージしよう ​

GitHub flow をはじめ、多くのブランチモデルでは、プルリクエスト を活用したマージ方法が推奨されています。プルリクエストとは、変更内容を main などのメインブランチにマージする前に、チームメンバーにレビューを依頼する仕組みです。

2.1 プルリクエストって何？ ​

プルリクエストは、あなたがトピックブランチで行った変更を、main ブランチなどのベースブランチにマージしてもらうよう、他のメンバーに依頼する仕組みです。単に「変更をマージしてください」と依頼するだけでなく、変更内容の説明や、関連する課題へのリンクなどを添えることで、レビューをスムーズに行うことができます。

2.2 プルリクエストの作成方法 ​

GitHub でプルリクエストを作成する手順は、以下の通りです。

  1. トピックブランチをプッシュします。 ローカルで作成したトピックブランチを、GitHub のリモートリポジトリにプッシュします。

    bash
    git push origin your-topic-branch

  2. GitHub のリポジトリページで、「Compare & pull request」ボタンをクリックします。 プッシュしたブランチのページにアクセスすると、「Compare & pull request」というボタンが表示されます。このボタンをクリックして、プルリクエストの作成画面を開きます。 [画像：GitHubの「Compare & pull request」ボタン]

  3. プルリクエストの内容を記入します。

    • タイトル: プルリクエストのタイトルを入力します。変更内容を簡潔に表すタイトルを付けましょう。
    • コメント: 変更内容の詳細や、レビューの際に注目してほしい点などを記入します。
    • レビュアー: プルリクエストをレビューしてほしいユーザーを選択します。
    • その他: 必要に応じて、関連する課題へのリンクや、ラベルなどを設定します。

  4. 「Create pull request」ボタンをクリックします。

2.3 コードレビューで品質を高めよう！ ​

プルリクエストを作成すると、指定したレビュアーに通知が送信されます。レビュアーは、プルリクエストの変更内容を確認し、問題がなければ承認します。必要に応じて、コメントで質問したり、修正を依頼したりすることもあります。

コードレビューは、バグの早期発見や、コードの品質向上、知識の共有など、様々なメリットをもたらします。チームメンバー全員で積極的にコードレビューを行い、より良いソフトウェアを開発しましょう！

3. ブランチを使いこなして、チーム開発を効率化！ ​

ここでは、チーム開発でよく使われる、代表的なブランチの活用方法を紹介します。

3.1 機能ブランチで並行開発をスムーズに ​

新しい機能を開発する際は、main ブランチから機能ブランチを作成し、そのブランチ上で作業を行いましょう。機能ブランチを使うことで、他の開発者の作業に影響を与えることなく、並行して開発を進めることができます。

例えば、ユーザー登録機能を開発する場合は、以下のような流れになります。

  1. main ブランチから feature/user-registration ブランチを作成します。

    bash
    git checkout main
git pull origin main
git checkout -b feature/user-registration

  2. feature/user-registration ブランチで、ユーザー登録機能の開発を行います。

  3. 開発が完了したら、feature/user-registration ブランチをリモートリポジトリにプッシュします。

    bash
    git push origin feature/user-registration

  4. GitHub で、feature/user-registration ブランチから main ブランチへのプルリクエストを作成します。

  5. チームメンバーによるコードレビューを経て、問題がなければ main ブランチにマージされます。

3.2 バグ修正ブランチで緊急対応も安心！ ​

リリースされた製品にバグが見つかった場合は、main ブランチからバグ修正ブランチを作成し、修正作業を行いましょう。バグ修正ブランチを使うことで、現在進行中の他の開発作業に影響を与えることなく、迅速にバグを修正できます。

例えば、ログイン画面のバグを修正する場合は、以下のような流れになります。

  1. main ブランチから fix/login-bug ブランチを作成します。

    bash
    git checkout main
git pull origin main
git checkout -b fix/login-bug

  2. fix/login-bug ブランチで、バグの修正作業を行います。

  3. 修正が完了したら、fix/login-bug ブランチをリモートリポジトリにプッシュします。

    bash
    git push origin fix/login-bug

  4. GitHub で、fix/login-bug ブランチから main ブランチへのプルリクエストを作成します。

  5. チームメンバーによるコードレビューを経て、問題がなければ main ブランチにマージされます。

3.3 リリースブランチで安定版を管理！ ​

ソフトウェアをリリースする際は、main ブランチからリリースブランチを作成し、リリースの準備を行いましょう。リリースブランチを使うことで、開発ブランチ（develop や main）に影響を与えることなく、安定したリリースを準備できます。

例えば、バージョン 1.0.0 をリリースする場合は、以下のような流れになります。

  1. main ブランチから release/1.0.0 ブランチを作成します。

    bash
    git checkout main
git pull origin main
git checkout -b release/1.0.0

  2. release/1.0.0 ブランチで、バージョン番号の更新や、最終的なテストなど、リリースの準備を行います。

  3. 準備が完了したら、release/1.0.0 ブランチをリモートリポジトリにプッシュします。

    bash
    git push origin release/1.0.0

  4. GitHub で、release/1.0.0 ブランチから main ブランチへのプルリクエストを作成します。

  5. チームメンバーによる最終確認を経て、問題がなければ main ブランチにマージされます。

  6. main ブランチにタグを打ち、リリースを記録します。

    bash
    git tag -a v1.0.0 -m "Version 1.0.0"
git push origin v1.0.0
Copyright © 2024 Cohorz Dev
Powered by VitePress