Gitワークフローガイド: チームのためのブランチ戦略

· 12分で読めます

📑 目次

Gitは、世界中の開発チームの95%以上が使用している、バージョン管理の絶対的な王者です。しかし、Gitコマンドを知っているだけでは不十分です。本当の課題は、チームに適したブランチ戦略を選択し、一貫して従うことです。

優れたGitワークフローは、マージコンフリクトを防ぎ、並行開発を可能にし、コード品質を維持し、リリースを予測可能にします。ワークフローがなければ、混乱、ビルドの破損、そしてフラストレーションを抱えた開発者を生み出すことになります。

Gitワークフローが重要な理由

こんな状況を想像してみてください。金曜日の午後、チームは重要なバグ修正を本番環境にプッシュしたばかりです。しかし待ってください。誰かが同時にテストされていない機能をmainに直接マージしてしまいました。今、本番環境が壊れ、誰もどのコミットが問題を引き起こしたのかわからず、週末の予定が台無しになりました。

このシナリオは、定義されたGitワークフローを持たないチームで繰り返されます。以下のような問題が発生します:

明確に定義されたGitワークフローは、いつブランチを作成し、どのようにマージし、誰が変更を承認するかについての明確なルールを確立します。コードが開発から本番環境にどのように移動するかについて、チーム全体で共通の理解を作り出します。

プロのヒント: 最良のワークフローは、チームが実際に従うものです。シンプルに始めて、必要なときにのみ複雑さを追加しましょう。誰もが理解する基本的なワークフローは、誰も従わない洗練されたワークフローに勝ります。

フィーチャーブランチワークフロー

フィーチャーブランチワークフローは、最も広く採用されているGitワークフローであり、それには十分な理由があります。シンプルで柔軟性があり、あらゆる規模のチームに適しています。核となる原則は、すべての新機能やバグ修正がmainから作成された独自のブランチを持つことです。

開発者はフィーチャーブランチで独立して作業し、コードレビュー後にプルリクエストを作成してmainにマージします。これにより、mainは常に安定してデプロイ可能な状態に保たれます。

仕組み

新機能を追加する典型的なフローは次のとおりです:

# mainから始めて最新の変更を取得
git checkout main
git pull origin main

# 新しいフィーチャーブランチを作成
git checkout -b feature/user-authentication

# 変更を加えてコミット
git add .
git commit -m "feat: add login form validation"

# リモートにプッシュ
git push origin feature/user-authentication

# GitHub/GitLabでコードレビュー用のPRを作成
# 承認後、mainにマージ
# フィーチャーブランチを削除

ブランチ命名規則

一貫した命名により、各ブランチが何をするのかを理解しやすくなります。一般的なプレフィックスは次のとおりです:

フィーチャーブランチワークフローを使用するタイミング

このワークフローは以下の場合に優れています:

潜在的な落とし穴

以下の一般的な問題に注意してください:

クイックヒント: フィーチャーブランチは短期間(理想的には3日未満)に保ちましょう。機能に時間がかかる場合は、フィーチャーフラグの背後で段階的にマージできる小さな部分に分割します。

GitFlowワークフロー

GitFlowは、スケジュールされたリリースを持つプロジェクト向けに設計された、より構造化されたワークフローです。開発とリリース準備のさまざまな段階を管理するために、複数の長期間存在するブランチを使用します。

2010年にVincent Driessenによって作成されたGitFlowは、定期的なリリーススケジュール(月次、四半期など)でソフトウェアを出荷するチームに人気となりました。開発、リリース準備、本番コードの間に明確な分離を提供します。

ブランチ構造

GitFlowは5種類のブランチを使用します:

完全なGitFlowサイクル

GitFlowを通じてコードがどのように流れるかは次のとおりです:

# GitFlowの初期化(1回限りのセットアップ)
git flow init

# 新しい機能を開始
git flow feature start user-profile
# 機能の作業...
git flow feature finish user-profile
# 自動的にdevelopにマージ

# developの準備ができたらリリースを開始
git flow release start 1.2.0
# バグ修正とバージョンアップのみ
git flow release finish 1.2.0
# mainとdevelopにマージ、タグを作成

# 緊急ホットフィックス
git flow hotfix start security-patch
# 問題を修正...
git flow hotfix finish security-patch
# mainとdevelopにマージ

GitFlowが意味を持つ場合

GitFlowは以下の場合に適しています:

GitFlowが人気を失った理由

多くの現代のチームがGitFlowから離れた理由:

GitFlowの作成者であるVincent Driessen自身も、継続的にデプロイするほとんどのWebアプリケーションには、よりシンプルなワークフローを推奨しています。

トランクベース開発

トランクベース開発(TBD)は、Google、Facebook、Netflixなどの高性能エンジニアリングチームが使用するワークフローです。GitFlowの正反対です。長期間存在するブランチの代わりに、開発者はmain(「トランク」)に直接コミットするか、非常に短期間のフィーチャーブランチを使用します。

重要な原則は、大規模なマージの痛みを避けるために、頻繁に(1日に複数回)コードを統合することです。

トランクベース開発の仕組み

TBDには2つのバリエーションがあります:

mainへの直接コミット:

# 最新の変更を取得
git pull origin main

# 小さな変更を加える
git add .
git commit -m "feat: add email validation"

# mainに直接プッシュ
git push origin main

短期間のフィーチャーブランチ(ほとんどのチームに推奨):

# 小さな変更のためのブランチを作成
git checkout -b add-email-validation

# 変更を加えてコミット
git add .
git commit -m "feat: add email validation"

# プッシュしてPRを作成
git push origin add-email-validation

# 24時間以内にマージ、ブランチを削除

フィーチャーフラグの役割

トランクベース開発は、不完全な機能をユーザーから隠すために、フィーチャーフラグ(フィーチャートグルとも呼ばれる)に大きく依存しています。これにより、本番環境の準備ができる前にコードをmainにマージできます。

// フィーチャーフラグの例
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckoutFlow />;
}
return <OldCheckoutFlow />;

フィーチャーフラグを使用すると、次のことができます:

TBDを成功させるための要件

トランクベース開発には、強力なエンジニアリングプラクティスが必要です:

トランクベース開発の利点

正しく行われた場合、TBDは大きな利点を提供します:

プロのヒント: チームがCI/CDに慣れていない場合は、すぐにトランクベース開発に飛び込まないでください。まずテストインフラストラクチャとデプロイメント自動化を構築し、その後徐々にフィーチャーブランチの寿命を短縮します。

チームに適したワークフローの選択

万能の答えはありません。適切なワークフローは、チームの規模、リリース頻度、エンジニアリングの成熟度によって異なります。決定方法は次のとおりです:

ワークフロー 最適な用途 チーム規模 リリース頻度
フィーチャーブランチ Webアプリ、SaaS製品、ほとんどの現代的なチーム 任意の規模 継続的または週次
GitFlow デスクトップ/モバイルアプリ、バージョン管理されたリリース 中規模から大規模 月次または四半期
トランクベース 強力なCI/CDを持つ高速チーム 任意の規模(規律が必要) 1日に複数回

意思決定フレームワーク

次の質問を自問してください:

1. 本番環境にどのくらいの頻度でデプロイしますか?

2. CI/CDパイプラインはどの程度成熟していますか?