GitのFeature Branch：ブランチの作成と操作方法

GitのFeature Branchとは

Feature Branch（機能ブランチ）は、特定の機能を開発するためにdevelopから作成されるGitの一時的なブランチです。長期にわたって存在するmainブランチやdevelopブランチとは異なり、featureブランチは限られた時間 — 数時間から数週間 — だけ存在します。

feature branchの主な目的は、1つのタスクに関連する変更を他のコードから分離することです。開発者は自分のブランチで実験し、多数のコミットを行い、コードを壊すことさえも、チームの他のメンバーの作業に影響を与えずに行えます。

開発が完了すると、featureブランチは必須のコードレビューを伴うPull Requestを通じてdevelopにマージされます。マージ後、リポジトリをクリーンに保つためにブランチは通常削除されます。

Vincent Driessen（2010年）によると、featureブランチを使用したGit Flowモデルは、異なる種類のブランチ間の責任の明確な分割により、業界標準となりました。

Feature Branchのワークフロー

ワークフローは、開発者が新しい機能ごとに実行する一連のステップで構成されています。このプロセスはマージの競合を最小限に抑え、コード品質管理を保証します。

1. ブランチの作成 developの最新コミットから。開発者はdevelopに切り替え、それを更新し、新しいfeatureブランチを作成します。
2. 開発とコミット featureブランチ内で。開発者は変更を加え、明確な説明とともにコミットし、定期的にブランチをリモートリポジトリにプッシュします。
3. developとの同期 — 開発中にメインブランチが進むことがあります。開発者は自分のfeatureブランチにdevelopのrebaseまたはmergeを実行します。
4. Pull Requestの作成 — 機能が準備できたら、開発者はコードレビューのためにPRを開きます。チームがコードをレビューし、コメントを残します。
5. マージと削除 — PRの承認後、ブランチはdevelopにマージされ、ローカルとリモートの両方から削除されます。

developとの定期的な同期は非常に重要です。featureブランチがdevelopからの変更をマージせずに長く存在するほど、最終的なマージでの競合の可能性が高まります。

Featureブランチの同期頻度

Featureブランチの命名規則

ブランチの命名はチームの規律の重要な部分です。統一された命名基準により、どのタスクに取り組んでいるか、誰がそれを実行しているかを迅速に特定できます。

• feature/名前 — クラシックなGit Flowではfeature/プレフィックスが使用されます。例：feature/added-auth-module。
• feature/JIRA-123-説明 — トラッキングシステムのタスク番号へのリンク。例：feature/PROJ-42-add-login。
• feature/種類/名前 — タスクの種類を示す拡張形式。例：feature/feat/analytics-dashboard。

JIRA、Trello、または他のシステムからのタスクIDの使用はベストプラクティスです。コードとタスクを自動的に関連付け、git logによるブランチ検索を簡素化します。

Pull Requestのプロセス

Pull Request（またはGitLabのMerge Request）は、featureブランチをdevelopにマージするリクエストです。PRは単なる技術的操作ではなく、コード品質を向上させ、チーム内に知識を広めるチームコードレビュープロセスです。

良いPRには、タスクの簡潔な説明を含むタイトル、チケットへのリンク、変更の説明が含まれます。開発者は何が行われたか、どのファイルが変更されたか、プロジェクトの他の部分への潜在的なリスクがあるかを示す必要があります。

チームはPR内のコードをレビューし、コメントを残し、変更を要求し（change requests）、マージを承認します（approve）。承認後、mergeまたはsquash mergeが実行されます。

モバイル開発におけるPRレビューの平均時間は4〜24時間です。Dangerライブラリは、PR内でリンターとテストを直接実行することで、一部のチェックを自動化します。

良いPRを作成するための推奨事項

• サイズ — 300〜400行以下の変更。大きなPRはレビューが難しく、レビュー品質が低下します。
• 1つのPR — 1つのタスク — 1つのリクエストに関連のない変更を混在させないでください。
• スクリーンショット — UI変更の場合は、変更前後のスクリーンショットを添付してください。
• テスト — 新機能の場合は単体テストを作成し、PRに含めてください。

Featureブランチのマージ戦略

PR承認後、featureブランチはさまざまな方法でdevelopにマージできます。マージ戦略の選択は、コミット履歴と変更のロールバック可能性に影響します。

• Merge commit — マージコミットを作成し、featureブランチの全コミット履歴を保持します。履歴は完全ですが、ブランチグラフが複雑になります。
• Squash merge — featureブランチのすべてのコミットを1つにまとめ、developの上に追加します。履歴はきれいになりますが、中間コミットに関する情報は失われます。
• Rebase and merge — featureブランチのコミットをdevelopの最新コミットの上に書き換え、追加のコミットなしでマージします。履歴は直線的になります。

頻繁にリリースを行うモバイルプロジェクトでは、通常squash mergeが使用されます。developでクリーンな履歴を提供し、開発の詳細はPRの説明とトラッカータスクに残ります。

Feature Branchでよくある間違い

経験豊富な開発者でも、featureブランチで作業するときに間違いを犯します。典型的な問題を知ることで、時間とデータの損失を防ぐことができます。

• ブランチの寿命が長すぎる — featureブランチがdevelopとの同期なしに2〜3週間以上存在し、大規模なマージ競合を引き起こします。
• 不明瞭な説明のコミット — “fix”や“update”のようなメッセージでは、何がなぜ変更されたかがわかりません。
• タスクの混在 — 同じfeatureブランチで2つの無関係な機能が開発され、選択的なロールバックが不可能になります。
• 同期の欠如 — 開発者がgit fetchを実行せず、developを更新しないため、最終的なマージで競合が発生します。

これらの問題を回避する最善の方法は、プロジェクト開始時に作業ルールに合意し、CI/CDパイプラインで自動チェックを使用することです。

Feature Branchのコマンド例

実践的なシナリオを考えてみましょう。開発者がモバイルアプリで新しい認証機能を開始します。featureブランチを作成し、コードに取り組み、Pull Requestでタスクを完了します。

# developを更新し、featureブランチを作成
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# 機能の作業：コミット
git add src/ui/login/
git commit -m "Add login screen layout"

# featureブランチをサーバーにプッシュ
git push origin feature/add-login-screen

# developと同期（rebase）
git fetch origin develop
git rebase origin/develop

# PR承認後：ローカルのdevelopを更新し、ブランチを削除
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

git branch -dコマンドは、変更が完全にマージされた後にのみブランチを削除します。ブランチがマージされていない場合、Gitは強制削除のためにgit branch -Dを使用するよう提案します — このフラグは注意して使用してください。

Featureブランチでのチェック自動化

PRを作成する前に、各featureブランチでCI/CDパイプラインを実行する必要があります。これにより、コードが他の開発者のレビューに入る前に、早期に問題を発見できます。

# featureブランチをチェックするGitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

パイプラインは、コードがコンパイルされること、テストに合格すること、コードスタイルがチーム標準に準拠していることを確認します。すべてのチェックに合格した後にのみ、Pull Requestを作成できます。