git-workflow

Git ワークフロー

チームでのコラボレーションに効果的なブランチ戦略とプルリクエストのワークフローを実装します。

このスキルを使用する場面

次の場合にこのスキルを使用します：

• チームの Git ワークフローを確立する
• ブランチ戦略を実装する
• プルリクエストのプロセスを設定する
• リリース管理を設定する
• コードレビューの実践を改善する

前提条件

• Git がインストールされていること
• リポジトリホスティング（GitHub、GitLab、Bitbucket）
• Git の基本的な知識

ブランチ戦略

トランクベース開発

最適な用途：継続的デプロイ、小規模チーム、成熟した CI/CD

main ─────●─────●─────●─────●─────●─────●─────●
          │     │     │     │     │     │
          └─●   └─●   └─●   └─●   └─●   └─●
         feature branches (short-lived)

# Create short-lived feature branch
git checkout main
git pull origin main
git checkout -b feature/add-login

# Work and commit frequently
git add .
git commit -m "feat: add login form"

# Keep branch updated
git fetch origin
git rebase origin/main

# Merge quickly (same day ideally)
git checkout main
git pull origin main
git merge feature/add-login
git push origin main
git branch -d feature/add-login

GitHub Flow

最適な用途：継続的デリバリー、Web アプリケーション

main ─────●─────●───────────●─────────────●─────●
          │           ↑           ↑       ↑
          └───●───●───┘           │       │
              feature/login       │       │
                                  │       │
          └───●───●───●───●───────┘       │
              feature/dashboard           │
                                          │
          └───●─────────────────────────┘
              hotfix/security-patch

# Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/user-dashboard

# Push and create PR
git push -u origin feature/user-dashboard

# After review, merge via PR (squash recommended)
# Delete branch after merge

GitFlow

最適な用途：定期的なリリース、バージョン管理された製品

main     ────────●────────────────●──────────────●
                 ↑                ↑              ↑
release  ────────┼────●───●──────┼──────────────┼
                 │    │   │      │              │
develop  ───●────●────┼───●──●───●───●───●───●──┼
            │         │      │       │   │      │
feature  ───┴─────────┘      │       │   │      │
                             │       │   │      │
hotfix   ────────────────────┴───────┼───┼──────┘
                                     │   │
feature  ────────────────────────────┴───┘

# Initialize GitFlow
git flow init

# Start feature
git flow feature start user-auth

# Finish feature (merges to develop)
git flow feature finish user-auth

# Start release
git flow release start 1.0.0

# Finish release (merges to main and develop)
git flow release finish 1.0.0

# Hotfix
git flow hotfix start security-fix
git flow hotfix finish security-fix

コミット規約

Conventional Commits

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

[optional body]

[optional footer(s)]

種類：

• feat：新機能
• fix：バグ修正
• docs：ドキュメント
• style：フォーマット
• refactor：コードの再構成
• test：テストの追加
• chore：メンテナンス

例：

git commit -m "feat(auth): add OAuth2 login support"
git commit -m "fix(api): handle null response from payment service"
git commit -m "docs: update API documentation for v2 endpoints"
git commit -m "refactor(db): optimize user query performance"

# Breaking change
git commit -m "feat(api)!: change response format for user endpoint

BREAKING CHANGE: The user endpoint now returns an object instead of array"

コミットメッセージのテンプレート

# Create template file ~/.gitmessage
# Subject line (50 chars max)

# Body (72 chars per line max)
# - What changed
# - Why it changed
# - Any side effects

# Footer
# Fixes #123
# Co-authored-by: Name <email>

# Configure Git to use template
git config --global commit.template ~/.gitmessage

プルリクエストのワークフロー

PR テンプレート

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix (non-breaking change)
- [ ] New feature (non-breaking change)
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing performed

## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review performed
- [ ] Documentation updated
- [ ] No new warnings introduced

## Related Issues
Closes #

## Screenshots (if applicable)

ブランチ保護ルール

# GitHub branch protection
branch_protection:
  branch: main
  required_pull_request_reviews:
    required_approving_review_count: 1
    dismiss_stale_reviews: true
    require_code_owner_reviews: true
  required_status_checks:
    strict: true
    contexts:
      - "ci/tests"
      - "ci/lint"
  restrictions:
    users: []
    teams: ["maintainers"]
  enforce_admins: true
  required_linear_history: true
  allow_force_pushes: false
  allow_deletions: false

コードオーナー

# .github/CODEOWNERS

# Default owners
* @team-leads

# Frontend code
/src/frontend/ @frontend-team
*.tsx @frontend-team
*.css @frontend-team

# Backend code
/src/api/ @backend-team
/src/services/ @backend-team

# Infrastructure
/terraform/ @platform-team
/k8s/ @platform-team
Dockerfile @platform-team

# Documentation
/docs/ @tech-writers
*.md @tech-writers

Git フック

コミット前フック

#!/bin/sh
# .git/hooks/pre-commit

# Run linting
npm run lint
if [ $? -ne 0 ]; then
  echo "Linting failed. Fix errors before committing."
  exit 1
fi

# Run tests
npm run test:unit
if [ $? -ne 0 ]; then
  echo "Tests failed. Fix tests before committing."
  exit 1
fi

# Check for debug statements
if grep -r "console.log\|debugger\|binding.pry" --include="*.js" --include="*.ts" --include="*.rb" src/; then
  echo "Remove debug statements before committing."
  exit 1
fi

Husky の使用

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "lint-staged": {
    "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{css,scss}": ["prettier --write"]
  }
}

Commitlint の設定

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

リリースワークフロー

タグを使ったリリースの自動化

# Create annotated tag
git tag -a v1.0.0 -m "Release version 1.0.0"

# Push tag
git push origin v1.0.0

# Create release from tag (GitHub CLI)
gh release create v1.0.0 \
  --title "Release 1.0.0" \
  --notes "Release notes here" \
  --target main

変更履歴の生成

# Using conventional-changelog
npx conventional-changelog -p angular -i CHANGELOG.md -s

# Using git-cliff
git cliff -o CHANGELOG.md

一般的な Git 操作

リベースとマージの比較

# Rebase (clean history)
git checkout feature/my-feature
git rebase main
git push --force-with-lease

# Merge (preserve history)
git checkout main
git merge feature/my-feature

# Squash merge (single commit)
git merge --squash feature/my-feature
git commit -m "feat: add feature X"

Cherry Pick

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

# Cherry pick range
git cherry-pick abc123..def456

# Cherry pick without committing
git cherry-pick -n abc123

インタラクティブリベース

# Clean up last 3 commits
git rebase -i HEAD~3

# In editor:
# pick abc123 First commit
# squash def456 Second commit
# reword ghi789 Third commit

よくある問題

問題：マージコンフリクト

問題：ブランチのマージ時に競合が発生する 解決策：こまめにリベースし、チームとコミュニケーションを取り、小規模な PR を使用します

問題：ブランチの分岐

問題：ローカルブランチがリモートより大幅に遅れている 解決策：git pull --rebase または git fetch && git rebase origin/main

問題：誤ったブランチへのコミット

問題：フィーチャーブランチではなく main にコミットしてしまった 解決策：git reset HEAD~1 を実行し、正しいブランチに切り替えて再度コミットします

ベストプラクティス

• ブランチは短期間で運用します（1 週間未満）
• 意味のあるコミットメッセージを書きます
• PR テンプレートを一貫して使用します
• コードレビューを必須にします
• main/master ブランチを保護します
• CI でチェックを自動化します
• 履歴を整理するためにスカッシュマージを使用します
• マージ後にブランチを削除します

関連スキル

• セマンティックバージョニング - バージョン管理
• GitHub Actions - CI/CD の自動化
• フィーチャーフラグ - 機能管理