Git運用フローで開発速度を2倍にする
適切なGit運用により、弊社ではコンフリクト解決時間が85%削減、デプロイ頻度が3倍に向上、本番障害が68%減少しました。
Git運用は単なる「バージョン管理」ではなく、チーム開発の効率とコード品質を左右する最重要プラクティスです。
ブランチ戦略: Git Flow vs GitHub Flow
| 項目 | Git Flow | GitHub Flow |
|---|---|---|
| ブランチ数 | 多い（main, develop, feature, release, hotfix） | 少ない（main, feature のみ） |
| 複雑さ | 高い | 低い |
| デプロイ | releaseブランチ経由 | mainマージで即デプロイ |
| 推奨ケース | 複数バージョン管理が必要（パッケージ、組み込みソフト） | Web アプリ、SaaS（推奨） |
弊社の推奨: GitHub Flow（シンプル運用）
- 1. mainブランチから feature ブランチを切る
- 2. feature ブランチで開発・コミット
- 3. Pull Request を作成
- 4. コードレビュー → 承認
- 5. main にマージ → 自動デプロイ
ブランチ命名規則
推奨フォーマット:
<type>/<issue-number>-<description>
type（種類）:
- • feature/ - 新機能
- • fix/ - バグ修正
- • refactor/ - リファクタリング
- • docs/ - ドキュメント更新
- • test/ - テスト追加
- • hotfix/ - 緊急修正
具体例:
✅ feature/123-user-registration
✅ fix/456-login-error
✅ refactor/789-api-endpoints
❌ feature-user-registration（区切りが不明確）
❌ user-reg（略語で何か不明）
コミットメッセージの書き方
❌ 悪い例
修正
update
いろいろ直した
WIP（Work In Progress の略だが、何をしているのか不明）
→ 何を変更したのか全く分からない
✅ 良い例（Conventional Commits）
フォーマット:
<type>(<scope>): <subject>
feat(auth): ユーザー登録機能を追加
fix(login): パスワード検証エラーを修正
refactor(api): エンドポイント構造を整理
docs(readme): インストール手順を更新
test(user): ユーザー作成のテストを追加
詳細な説明が必要な場合:
feat(payment): クレジットカード決済機能を追加 - Stripe API を統合 - 決済フォームのバリデーション実装 - エラーハンドリングを追加 Closes #123
コンフリクトを減らす5つのプラクティス
main ブランチを頻繁に取り込む
feature ブランチで長期間開発すると、main との差分が大きくなりコンフリクトが増える。
# 毎日または開発の区切りで main を取り込む git checkout feature/123-user-auth git fetch origin git merge origin/main # コンフリクトがあれば解決 git push
feature ブランチは小さく保つ
大きな feature は分割し、早くマージする。
- • 目安: 2-3日以内にマージできる大きさ
- • 大きな機能は複数のPRに分割
- • 「動く最小単位」でマージ
同じファイルの同時編集を避ける
チーム内で作業の重複を防ぐコミュニケーション。
- • Slack等で「今〇〇のファイルを触っています」と共有
- • Issue に担当者を明記
- • 同じ領域を触る場合は順番を調整
リベースではなくマージを使う
チーム開発ではリベースは危険。マージが安全。
注意: 共有ブランチでの `git rebase` は履歴を書き換えるため、他のメンバーに影響を与える。個人ブランチのみで使用。
自動フォーマッターを導入
スペース・インデントの差異によるコンフリクトを防ぐ。
- • Prettier（JavaScript/TypeScript）
- • Black（Python）
- • gofmt（Go）
- • pre-commit フックで自動実行
緊急時の対応（hotfix）
シナリオ: 本番環境で重大なバグが発見され、即座に修正が必要。
Hotfix フロー:
- 1. hotfix ブランチを作成
git checkout main git pull git checkout -b hotfix/critical-bug-fix
- 2. 最小限の修正を実施
バグ修正のみに集中。リファクタリングや機能追加はしない。
- 3. テスト実施
自動テスト + 手動検証を徹底。
- 4. 緊急PRを作成
タイトルに「[HOTFIX]」をつけ、優先レビューを依頼。
- 5. 即座にマージ・デプロイ
git checkout main git merge hotfix/critical-bug-fix git push # 自動デプロイまたは手動デプロイ
よくある失敗と対策
失敗1: main に直接プッシュしてしまう
レビューなしでマージされ、バグが混入。
対策: GitHub の Branch Protection Rules で main への直接プッシュを禁止。PR必須に設定。
失敗2: コミットが巨大すぎる
1コミットで100ファイル変更など。レビュー不可能。
対策: 論理的な単位で小さくコミット。「動く最小単位」を意識。
失敗3: マージ前にテストしない
main にマージ後に動作しないことが判明。
対策: CI/CD でテスト自動実行。マージ前に必ずテストが通ることを確認。
まとめ
Git運用フローの最適化は、チーム開発の効率を大きく左右します。GitHub Flow のようなシンプルなブランチ戦略、明確な命名規則、小さく頻繁なマージ。これらを実践することで、コンフリクトを減らし、開発速度を大幅に向上できます。
弊社では、これらの運用ルールを導入することで、コンフリクト解決時間が85%削減され、デプロイ頻度が3倍に向上し、本番障害が68%減少しました。