git-workflow-designer

Git ワークフロー設計スキル

概要

このスキルは、あらゆる規模のチームに効果的な Git ブランチ戦略を設計、実装するのに役立ちます。Git Flow、GitHub Flow、トランクベース開発、リリース管理、ブランチ保護ポリシーを扱います。

ワークフロー選択の考え方

主な要素

1. チーム規模：個人 vs. 小規模チーム vs. 大規模組織
2. リリース頻度：継続的リリース vs. 定期リリース
3. 環境の複雑さ：単一 vs. 複数のデプロイ先
4. リスク許容度：スピード重視 vs. 安定性優先

ワークフローの比較

ワークフロー	最適な用途	リリース頻度	複雑さ
トランクベース	小規模チーム、CI/CD	継続的	低
GitHub Flow	ほとんどの Web アプリ	必要に応じて	低
Git Flow	バージョン管理されたソフトウェア	定期的	高
GitLab Flow	環境ベース	混在	中

GitHub Flow（ほとんどのケースで推奨）

概要

継続的デプロイに適した、シンプルで効果的なワークフローです。

main ─────●─────●─────●─────●─────●─────●
            \       /   \       /
feature/x    ●─────●     ●─────●

プロセス

1. main からブランチを作成

   git checkout main
   git pull origin main
   git checkout -b feature/user-authentication
   

2. 定期的にコミット

   git add .
   git commit -m "feat: add login form component"
   

3. プッシュして PR を作成

   git push -u origin feature/user-authentication
   gh pr create --title "Add user authentication" --body "..."
   

4. レビューしてマージ

   • CI でテストを実行
   • ピアレビュー
   • main にスカッシュマージ

5. デプロイ

   • main へのマージ時に自動デプロイ

ブランチ命名規則

feature/  - New features
fix/      - Bug fixes
docs/     - Documentation
refactor/ - Code refactoring
test/     - Test additions
chore/    - Maintenance tasks

設定

# .github/branch-protection.yml (pseudo-config)
main:
  required_status_checks:
    strict: true
    contexts:
      - "ci/tests"
      - "ci/lint"
      - "ci/build"
  required_pull_request_reviews:
    required_approving_review_count: 1
    dismiss_stale_reviews: true
  enforce_admins: false
  restrictions: null

Git Flow（バージョン管理されたリリース向け）

概要

定期的なリリースサイクルに適した、構造化されたワークフローです。

main     ─────●─────────────────●─────────────●
               \               /               \
release         ●─────●─────●─                  ●───
                 \     \   /                   /
develop   ●─────●─●─────●─●─────●─────●─────●─●
            \   /   \       /     \       /
feature      ●─●     ●─────●       ●─────●

ブランチ

ブランチ	目的	マージ先
main	本番環境に対応したコード	-
develop	統合ブランチ	main
feature/*	新機能	develop
release/*	リリース準備	main、develop
hotfix/*	緊急修正	main、develop

機能開発

# Start feature
git checkout develop
git pull origin develop
git checkout -b feature/new-dashboard

# Work on feature
git commit -m "feat: add dashboard layout"
git commit -m "feat: add dashboard charts"

# Complete feature
git checkout develop
git merge --no-ff feature/new-dashboard
git branch -d feature/new-dashboard
git push origin develop

リリースプロセス

# Start release
git checkout develop
git checkout -b release/1.2.0

# Bump version
npm version 1.2.0 --no-git-tag-version
git commit -am "chore: bump version to 1.2.0"

# Fix release issues
git commit -m "fix: correct typo in release notes"

# Complete release
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin main --tags

git checkout develop
git merge --no-ff release/1.2.0
git push origin develop

git branch -d release/1.2.0

ホットフィックスプロセス

# Start hotfix
git checkout main
git checkout -b hotfix/1.2.1

# Fix the issue
git commit -m "fix: critical security vulnerability"

# Complete hotfix
git checkout main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix 1.2.1"
git push origin main --tags

git checkout develop
git merge --no-ff hotfix/1.2.1
git push origin develop

git branch -d hotfix/1.2.1

トランクベース開発

概要

全員が短期間のブランチを使って main にコミットします。

main ─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●─●
        \─/   \─/       \─/
        PR    PR        PR

原則

1. 短期間のブランチ（1 日未満）
2. 小規模で頻繁なコミット
3. 未完成の作業にはフィーチャーフラグを使用
4. 包括的な CI/CD

フィーチャーフラグの統合

// src/lib/features.ts
export const features = {
  newCheckout: process.env.FEATURE_NEW_CHECKOUT === 'true',
  darkMode: process.env.FEATURE_DARK_MODE === 'true',
};

// Usage
if (features.newCheckout) {
  return <NewCheckout />;
}
return <OldCheckout />;

ブランチルール

# Quick feature (< 4 hours)
git checkout main
git pull
git checkout -b quick/fix-typo
# ... work ...
git push -u origin quick/fix-typo
gh pr create --title "Fix typo" --body ""
# Merge immediately after CI passes

リリース管理

セマンティックバージョニング

MAJOR.MINOR.PATCH

1.0.0 - Initial release
1.1.0 - New feature (backwards compatible)
1.1.1 - Bug fix
2.0.0 - Breaking change

バージョンの自動更新

// package.json
{
  "scripts": {
    "release:patch": "npm version patch && git push --follow-tags",
    "release:minor": "npm version minor && git push --follow-tags",
    "release:major": "npm version major && git push --follow-tags"
  }
}

変更履歴の生成

# .github/workflows/release.yml
name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Generate changelog
        id: changelog
        uses: metcalfc/changelog-generator@v4
        with:
          myToken: ${{ secrets.GITHUB_TOKEN }}

      - name: Create Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          body: ${{ steps.changelog.outputs.changelog }}

Conventional Commits

# Format
<type>(<scope>): <description>

[optional body]

[optional footer(s)]

# Types
feat:     New feature
fix:      Bug fix
docs:     Documentation
style:    Formatting, no code change
refactor: Refactoring
test:     Tests
chore:    Maintenance

# Examples
feat(auth): add password reset flow
fix(api): handle null user gracefully
docs: update README with new API endpoints
chore(deps): update dependencies

Commitlint の設定

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feat',
        'fix',
        'docs',
        'style',
        'refactor',
        'test',
        'chore',
        'perf',
        'ci',
        'build',
        'revert',
      ],
    ],
    'subject-case': [2, 'always', 'lower-case'],
    'header-max-length': [2, 'always', 72],
  },
};

ブランチ保護

GitHub ブランチ保護ルール

# Recommended settings for main branch

Required status checks:
  - ci/test
  - ci/lint
  - ci/build
  - ci/typecheck

Required reviews: 1
Dismiss stale reviews: true
Require review from code owners: true

Require signed commits: false  # Optional
Require linear history: true   # Encourages squash/rebase

Include administrators: false  # Allow admins to bypass

Restrict who can push:
  - Maintainers only

CODEOWNERS

# .github/CODEOWNERS

# Default owners
* @team-lead

# Frontend
/src/components/ @frontend-team
/src/app/ @frontend-team

# Backend
/src/api/ @backend-team
/src/lib/db/ @backend-team

# Infrastructure
/.github/ @devops-team
/docker/ @devops-team

# Docs
/docs/ @tech-writer
*.md @tech-writer

マージ戦略

スカッシュしてマージ（推奨）

# Clean history, one commit per feature
git merge --squash feature/branch
git commit -m "feat: complete feature description"

メリット：

• main の履歴がすっきりする
• 機能を簡単に取り消せる
• コミットメッセージを編集できる

デメリット：

• 個々のコミット履歴が失われる

リベースしてマージ

# Linear history, preserves commits
git rebase main feature/branch
git checkout main
git merge feature/branch

メリット：

• 直線的な履歴になる
• 個々のコミットを保持できる
• bisect に適している

デメリット：

• コミットを整理する必要がある
• 強制プッシュが必要になる場合がある

マージコミット

# Preserves full history with merge points
git merge --no-ff feature/branch

メリット：

• 完全な履歴が保持される
• マージポイントが明確になる
• 強制プッシュが不要

デメリット：

• 履歴が煩雑になる
• 履歴をたどりにくくなる

よくあるシナリオ

機能ブランチを main と同期する

# Option 1: Rebase (clean history)
git checkout feature/my-feature
git fetch origin
git rebase origin/main
git push --force-with-lease

# Option 2: Merge (safe, but noisy)
git checkout feature/my-feature
git merge origin/main
git push

最後のコミットを取り消す（プッシュ前）

# Keep changes staged
git reset --soft HEAD~1

# Keep changes unstaged
git reset HEAD~1

# Discard changes
git reset --hard HEAD~1

コミットメッセージを修正する

# Last commit only
git commit --amend -m "new message"

# Older commits (interactive rebase)
git rebase -i HEAD~3
# Change 'pick' to 'reword' for target commit

特定のコミットをチェリーピックする

# Apply specific commit to current branch
git cherry-pick abc123

# Cherry-pick without committing
git cherry-pick --no-commit abc123

削除したブランチを復元する

# Find the commit
git reflog

# Recreate branch
git checkout -b recovered-branch abc123

ワークフロースクリプト

Git エイリアス

# ~/.gitconfig
[alias]
    # Status
    s = status -sb

    # Branching
    co = checkout
    cob = checkout -b
    br = branch -vv

    # Commits
    cm = commit -m
    ca = commit --amend --no-edit

    # Logging
    lg = log --oneline --graph --decorate -20
    lga = log --oneline --graph --decorate --all -20

    # Sync
    sync = !git fetch origin && git rebase origin/main

    # Cleanup
    cleanup = !git branch --merged | grep -v main | xargs git branch -d

    # Undo
    undo = reset --soft HEAD~1

機能ブランチスクリプト

#!/bin/bash
# scripts/feature.sh

set -e

BRANCH_TYPE=${1:-feature}
BRANCH_NAME=$2

if [ -z "$BRANCH_NAME" ]; then
    echo "Usage: ./scripts/feature.sh [type] <name>"
    echo "Types: feature, fix, docs, chore"
    exit 1
fi

FULL_BRANCH="$BRANCH_TYPE/$BRANCH_NAME"

echo "Creating branch: $FULL_BRANCH"

git checkout main
git pull origin main
git checkout -b "$FULL_BRANCH"

echo "Branch '$FULL_BRANCH' created and checked out"
echo "Run: git push -u origin $FULL_BRANCH"

ワークフローチェックリスト

ワークフローを選択する前に

• チームの規模と分散状況を把握する
• リリース頻度を定義する
• CI/CD の成熟度を評価する
• デプロイ環境を検討する

実装

• CONTRIBUTING.md にワークフローを記載する
• ブランチ保護ルールを設定する
• CODEOWNERS を設定する
• マージ戦略を設定する
• コミットメッセージの lint を追加する
• Git エイリアス／スクリプトを作成する

メンテナンス

• 定期的にブランチを整理する
• マージキューを監視する
• 保護ルールを見直して更新する
• 新しいチームメンバーをトレーニングする

このスキルを使用するタイミング

次のような場合にこのスキルを使用してください：

• 新しいプロジェクトを始め、ワークフローを選ぶとき
• 個人開発からチーム開発へ拡大するとき
• リリース管理を改善するとき
• ブランチ保護ルールを設定するとき
• コントリビューションガイドラインを作成するとき
• Git ワークフローの競合を解決するとき
• Conventional Commits を導入するとき