GitのDevelop Branch — 概要、目的、動作原理

GitのDevelop Branchとは

Develop Branch（開発ブランチ）はGit Flowにおける長期稼働ブランチであり、全開発者からのコード統合の中心ハブとして機能します。開発完了とコードレビューの後、featureブランチがここにマージされます。

developのコードは常にリリース作成準備が整った状態にありますが、まだ本番環境にデプロイされていません。つまり、developのすべての機能はレビュー、テスト、統合チェックを通過していますが、まだリリースサイクルを待っています。

各コードバージョンがリリースであるmainとは異なり、developには継続的な変更の流れが含まれます。featureブランチがマージされるにつれてdevelopにコミットが表示され、これは1日に複数回発生する可能性があります。

Vincent Driessen、2010によると、developは成功するブランチモデルの重要な要素であり、ドラフト作業をリリース準備済みバージョンから分離します。

developとmainブランチの違い

developとmainの違いを理解することは、適切なGit Flowワークフローにとって重要です。これらのブランチは異なる機能を果たし、安定性の要件も異なります。

developとmainに分割することで、チームは本番バージョンの安定性を危険にさらすことなく、新しいコードを継続的に統合できます。開発者は公式リリース前でも、PR承認後すぐにdevelopで自分のコードを確認できます。

Git Flowにおけるdevelopの役割

Git Flowモデルでは、developはfeatureブランチ（変更のソース）とreleaseブランチ（リリース準備）の間で中心的な位置を占めています。この階層を理解することが効果的なブランチングの基盤です。

• Feature → Develop — 各完了した機能は、コードレビュー付きのPull Requestを介してdevelopにマージされます。
• Develop → Release — リリースに十分な変更が蓄積されると、developからreleaseブランチが作成されます。
• Release → Main + Develop — 最終準備後、releaseブランチはmain（リリース）とdevelop（バグ修正）にマージされます。
• Hotfix → Main + Develop — 重要な修正はmainから作成され、両方のブランチにマージされます。

この構造により、developには常にすべての新機能を含む最新コードが含まれ、mainには検証済みの本番コードのみが含まれます。これは、App StoreやGoogle Playでのレビューサイクルが長いモバイルプロジェクトにとって特に重要です。

他のGit Flowブランチとのdevelopの関係

Developはfeature、release、hotfixブランチ間の中心的なリンクとして機能します。マージの方向性を理解することは、競合やコミットの損失を防ぐために不可欠です。

developのコード品質要件

developのコード品質は高くなければなりませんが、絶対的ではありません。すべてのエラーが緊急hotfixを意味するmainとは異なり、developではリリース前に修正される軽微な不完全さが許容されます。

developにマージする前のコードの最小要件：

• コンパイル — コードはエラーなくコンパイルされる必要があります。developでビルドが壊れると、チーム全体の作業がブロックされます。
• ユニットテスト — 既存のすべてのテストが合格する必要があります。新しいコードは少なくとも70%テストでカバーされる必要があります。
• コードスタイル — コードはチームで受け入れられているフォーマットと命名規則に準拠する必要があります。
• 非推奨APIなし — 新しいコードでの非推奨メソッドの使用は許可されません。

CI/CDパイプラインの自動チェックは、developへのプッシュごとに実行する必要があります。ビルドが壊れた場合、責任のある開発者は1時間以内に問題を修正するか、コミットを元に戻す必要があります。

developのCI/CDチェック

developにGitHub Actionsを設定すると、すべてのPRがマージ前に自動チェックを通過することが保証されます。一般的なパイプラインには、ビルド、テスト、リンティングが含まれます。

# GitHub Actions — マージ後のdevelop確認
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

developへのマージルール

developへのマージは、統合ブランチの安定性を維持するために厳格なルールに従う必要があります。これらのルールに違反すると、競合、ビルド破損、チームの時間の無駄が発生します。

• Pull Requestのみ — developへの直接プッシュは禁止されています。すべての変更はコードレビューを受けます。
• 最低1つの承認 — PRはタスクに関与していない少なくとも1人の開発者によって承認される必要があります。
• Squash merge — クリーンな履歴のために、developにマージする際にすべてのfeatureブランチコミットを1つにまとめることを推奨します。
• PRを最新に保つ — マージ前に、PRは最新のdevelopコミットに対して更新（rebaseまたはmerge）される必要があります。

PRを最新に保つルールは特に重要です。featureブランチが1週間前に作成され、developが50コミット進んでいる場合、直接マージすると競合が発生する可能性があり、developではなくPRのコンテキストで解決する方が適切です。

誤ったマージからdevelopを保護する

ブランチ保護ルールは、GitHub、GitLab、Bitbucketレベルの設定で、developへの不正な変更を防ぎます。偶発的なプッシュでも統合ブランチが壊れないことを保証します。

developに推奨される保護ルール：

• Pull requestを必須にする — developへの直接プッシュを禁止。すべての変更はPR経由のみ。
• 承認を必須にする — PRマージ前に最低1〜2の承認。
• ステータスチェックを必須にする — CI/CDパイプラインが合格していない場合はマージをブロック。
• 最新状態を必須にする — マージ前にPRブランチをdevelopに対して更新する必要があります。
• プッシュアクセスを制限する — developへのプッシュ権限をシニア開発者のみに制限。

developの保護設定には10分かかりますが、統合ブランチの破損に関連する数週間のダウンタイムを防ぎます。マルチプラットフォームチームを持つモバイルプロジェクトでは、これは特に重要です。

developの操作コマンド例

典型的な開発者の一日を考えてみましょう。朝にdevelopを更新し、新しいfeatureブランチを作成し、タスク完了後に変更をdevelopにマージし直します。

# 朝のdevelop同期
git checkout develop
git pull origin develop

# developから新しいfeatureブランチを作成
git checkout -b feature/add-push-notifications

# 機能の開発中...
git add . && git commit -m "Add FCM integration"

# 開発中のdevelop更新
git fetch origin develop
git rebase origin/develop

# PR承認後 — ローカルdevelopを更新
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

developでのgit pullコマンドは、一度に2つの操作を実行します。git fetch（サーバーから新しいコミットを取得）とgit merge（ローカルブランチとマージ）です。developにとって、これが標準的な同期方法です。

破損したマージ後のdevelopの復旧

ビルドを壊すコードがdevelopに入った場合、迅速に対応する必要があります。developのダウンタイムの1時間ごとに、開発チーム全体の作業がブロックされます。

ビルドを壊すコードがdevelopに入った場合は、git revertを使用して問題のある変更を元に戻す新しいコミットを作成します。git resetをdevelopで使用しないでください。他のチームメンバーが既に持っている履歴を書き換えてしまいます。

# 問題のあるコミットを見つける
git log --oneline develop

# revertによるコミットの取り消し（安全）
git revert a1b2c3d

# リモートdevelopに修正をプッシュ
git push origin develop

# 特定のコミットの変更を表示
git show a1b2c3d --stat