@digiangler(おおとろ｜フリーランス開発者 × 内省ストーリーテラー)

GitHubFlow 実践ガイド - フルサイクル開発者のための現場手順書

Last updated at 2025-07-09Posted at 2025-07-01

GitHubFlow 実践ガイド - フルサイクル開発者のための現場手順書

こちらは私の実務で使用している備忘録です。
一部内容が最新でない場合もありますが、実際の経験を基にした記録としてご覧ください。

GitHubFlowの哲学と概要

基本哲学

シンプルさ: 複雑なブランチ戦略を避け、開発者が迷わない明確なルール
継続的デプロイ: いつでもデプロイ可能な状態を維持
透明性: すべての変更がPull Request経由で可視化
品質保証: 自動テストとコードレビューによる品質担保

フロー図

ブランチ戦略の詳細

1. main ブランチ

目的: 本番環境にデプロイされる安定版コード

特徴:

常にデプロイ可能な状態を維持
直接コミット禁止（Protected Branch）
CIでの自動テスト必須
タグによるバージョン管理

命名規則: main

2. develop ブランチ

目的: 開発の統合ブランチ

特徴:

新機能の統合先
定期的にmainにマージ
ステージング環境への自動デプロイ
機能テストの実行

命名規則: develop

3. feature ブランチ

目的: 新機能・改善の開発

特徴:

developから分岐
単一機能に集中
開発完了後に削除
WIPコミット可能

命名規則:

feature/機能名
feature/issue-番号
feature/ユーザーストーリー

例:

feature/user-authentication
feature/payment-integration
feature/responsive-design
feature/issue-123

4. hotfix ブランチ

目的: 本番環境の緊急バグ修正

特徴:

mainから分岐
最優先で処理
mainとdevelopの両方にマージ
パッチバージョンアップ

命名規則:

hotfix/バグ内容
hotfix/issue-番号

例:

hotfix/security-vulnerability
hotfix/payment-error
hotfix/issue-456

実践的ワークフロー

1. 新機能開発フロー（feature → develop）

Step 1: 開発環境の準備

# 最新のdevelopブランチに切り替え
git checkout develop

# リモートから最新を取得
git pull origin develop

# 新しいfeatureブランチを作成
git checkout -b feature/user-profile-page

# ブランチをリモートにプッシュ（初回）
git push -u origin feature/user-profile-page

Step 2: 開発作業

# 作業を進める
# ファイル編集...

# 変更をステージング
git add .

# コミット（Conventional Commits形式）
git commit -m "feat(profile): ユーザープロフィールページの基本レイアウト追加"

# 更に開発を続ける
# ファイル編集...

git add .
git commit -m "feat(profile): プロフィール編集フォームの実装"

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

Step 3: Pull Request作成

# GitHubでPR作成、または CLI使用
gh pr create --title "feat: ユーザープロフィールページの実装" --body "
## 概要
ユーザーがプロフィール情報を表示・編集できるページを実装

## 変更内容
- プロフィール表示コンポーネント
- プロフィール編集フォーム
- バリデーション機能
- レスポンシブデザイン対応

## テスト
- [ ] 単体テスト追加
- [ ] E2Eテスト確認
- [ ] デザインレビュー完了

## 関連Issue
Closes #123
"

Step 4: レビューとマージ

# レビュー修正がある場合
git add .
git commit -m "fix(profile): レビュー指摘事項の修正"
git push origin feature/user-profile-page

# マージ後のクリーンアップ
git checkout develop
git pull origin develop
git branch -d feature/user-profile-page
git push origin --delete feature/user-profile-page

2. リリースフロー（develop → main）

Step 1: リリース準備

# developが安定状態であることを確認
git checkout develop
git pull origin develop

# ステージング環境での最終テスト確認
# リリースノートの準備

Step 2: リリースPR作成

# mainブランチへのPR作成
gh pr create --base main --head develop \
  --title "release: v1.2.0" \
  --body "
## リリース内容
- ユーザープロフィール機能
- パフォーマンス改善
- セキュリティアップデート

## テスト状況
- [ ] 単体テスト: 全てパス
- [ ] 統合テスト: 全てパス
- [ ] E2Eテスト: 全てパス
- [ ] ステージング確認: 完了

## デプロイ手順
1. mainブランチにマージ
2. 自動デプロイ実行
3. 本番環境での動作確認
4. バージョンタグ付与
"

Step 3: リリース実行

# マージ後、mainブランチでタグ付け
git checkout main
git pull origin main

# バージョンタグ作成
git tag -a v1.2.0 -m "Release version 1.2.0

- feat: ユーザープロフィール機能追加
- perf: ページ読み込み速度改善
- security: セキュリティ脆弱性修正
"

# タグをリモートにプッシュ
git push origin v1.2.0

3. 緊急修正フロー（hotfix → main → develop）

Step 1: 緊急修正ブランチ作成

# mainブランチから緊急修正ブランチを作成
git checkout main
git pull origin main
git checkout -b hotfix/payment-processing-error

# 修正作業
# ファイル編集...

git add .
git commit -m "fix(payment): 決済処理エラーの修正

特定の条件下で決済が失敗する問題を修正
- 税計算ロジックの修正
- エラーハンドリングの改善
"

git push -u origin hotfix/payment-processing-error

Step 2: 緊急PR作成・マージ

# mainへの緊急PR作成
gh pr create --base main --title "hotfix: 決済処理エラーの緊急修正" \
  --body "
## 緊急修正内容
決済処理で発生していたエラーを修正

## 影響範囲
- 決済機能のみ
- 既存データへの影響なし

## テスト
- [ ] 修正箇所の単体テスト
- [ ] 決済フローの手動テスト
- [ ] ステージング環境での確認
"

# レビュー・承認後、マージ
# mainブランチでタグ付け
git checkout main
git pull origin main
git tag -a v1.2.1 -m "Hotfix version 1.2.1 - 決済処理エラー修正"
git push origin v1.2.1

Step 3: developへの反映

# developブランチに修正を反映
git checkout develop
git pull origin develop
git merge main
git push origin develop

# hotfixブランチの削除
git branch -d hotfix/payment-processing-error
git push origin --delete hotfix/payment-processing-error

よく使用するGitコマンド一覧

基本操作

# ブランチ操作
git branch                          # ローカルブランチ一覧
git branch -r                       # リモートブランチ一覧
git branch -a                       # 全ブランチ一覧
git branch -d <branch-name>         # ローカルブランチ削除
git push origin --delete <branch>   # リモートブランチ削除

# ブランチ切り替え・作成
git checkout <branch-name>          # ブランチ切り替え
git checkout -b <new-branch>        # 新ブランチ作成・切り替え
git switch <branch-name>            # ブランチ切り替え（新コマンド）
git switch -c <new-branch>          # 新ブランチ作成・切り替え（新コマンド）

# リモート操作
git remote -v                       # リモート一覧
git fetch origin                    # リモートの最新情報取得
git pull origin <branch>            # リモートブランチの取得・マージ
git push origin <branch>            # リモートへプッシュ
git push -u origin <branch>         # 初回プッシュ（アップストリーム設定）

コミット関連

# コミット操作
git add .                           # 全変更をステージング
git add <file>                      # 特定ファイルをステージング
git commit -m "message"             # コミット
git commit -am "message"            # ステージング＋コミット
git commit --amend                  # 直前のコミットを修正

# コミット履歴確認
git log                             # コミット履歴
git log --oneline                   # 簡潔な履歴
git log --graph --oneline           # グラフ表示
git show <commit-hash>              # 特定コミットの詳細

マージ・リベース

# マージ操作
git merge <branch>                  # ブランチをマージ
git merge --no-ff <branch>          # マージコミットを必ず作成
git merge --squash <branch>         # squashマージ

# リベース操作
git rebase <branch>                 # ブランチをリベース
git rebase -i HEAD~3                # インタラクティブリベース（直近3コミット）
git rebase --continue               # リベース継続
git rebase --abort                  # リベース中止

状態確認・比較

# 状態確認
git status                          # 現在の状態
git diff                            # 変更差分
git diff --staged                   # ステージング済み差分
git diff <branch1>..<branch2>       # ブランチ間差分

# ファイル操作
git rm <file>                       # ファイル削除
git mv <old> <new>                  # ファイル名変更
git restore <file>                  # 変更を取り消し
git restore --staged <file>         # ステージングを取り消し

高度な操作

# stash操作（作業を一時保存）
git stash                           # 現在の変更を一時保存
git stash list                      # stash一覧
git stash pop                       # 最新のstashを適用・削除
git stash apply                     # 最新のstashを適用（削除しない）
git stash drop                      # 最新のstashを削除

# タグ操作
git tag                             # タグ一覧
git tag -a v1.0.0 -m "message"      # アノテートタグ作成
git push origin v1.0.0              # タグをリモートにプッシュ
git push origin --tags              # 全タグをプッシュ

# 過去のコミットに戻る
git reset --soft HEAD~1             # 直前のコミットを取り消し（変更は保持）
git reset --hard HEAD~1             # 直前のコミットを完全に取り消し
git revert <commit-hash>            # 特定コミットの変更を打ち消すコミット作成

GitHub CLI (gh) コマンド

# PR操作
gh pr create                        # PR作成（インタラクティブ）
gh pr list                          # PR一覧
gh pr view <number>                 # PR詳細表示
gh pr checkout <number>             # PRをローカルにチェックアウト
gh pr merge <number>                # PRマージ
gh pr close <number>                # PRクローズ

# Issue操作
gh issue create                     # Issue作成
gh issue list                       # Issue一覧
gh issue view <number>              # Issue詳細
gh issue close <number>             # Issueクローズ

# リポジトリ操作
gh repo view                        # リポジトリ詳細
gh repo clone <owner/repo>          # リポジトリクローン
gh repo fork                        # リポジトリフォーク

シナリオ別対応方法

1. コンフリクト解決

マージコンフリクトが発生した場合

# マージを試行してコンフリクトが発生
git merge develop
# Auto-merging src/components/UserProfile.tsx
# CONFLICT (content): Merge conflict in src/components/UserProfile.tsx

# コンフリクトファイルを編集
# <<<<<<< HEAD
# 現在のブランチの内容
# =======
# マージしようとしているブランチの内容
# >>>>>>> develop

# コンフリクト解決後
git add src/components/UserProfile.tsx
git commit -m "resolve: UserProfileコンポーネントのマージコンフリクト解決"

リベースコンフリクトの場合

# リベース中にコンフリクトが発生
git rebase develop
# CONFLICT (content): Merge conflict in src/utils/validation.ts

# コンフリクト解決後
git add src/utils/validation.ts
git rebase --continue

# リベース完了後
git push --force-with-lease origin feature/user-validation

2. 間違ったコミットの修正

直前のコミットメッセージを修正

git commit --amend -m "fix(auth): 正しいコミットメッセージ"

# すでにプッシュ済みの場合
git push --force-with-lease origin feature/auth-fix

間違ったファイルをコミットした場合

# 直前のコミットから特定ファイルを除外
git reset --soft HEAD~1
git restore --staged config/secrets.json
git commit -m "fix(auth): 認証ロジックの修正"

複数コミットを整理（squash）

# 直近3コミットを整理
git rebase -i HEAD~3

# エディタが開くので、squashしたいコミットを「s」に変更
# pick abc1234 first commit
# s def5678 second commit  
# s ghi9012 third commit

# コミットメッセージを編集
git push --force-with-lease origin feature/cleanup

3. ブランチの同期

developブランチの最新に追従

# featureブランチで作業中
git checkout develop
git pull origin develop
git checkout feature/my-feature
git rebase develop

# コンフリクトがあれば解決
# 解決後
git push --force-with-lease origin feature/my-feature

フォークしたリポジトリの同期

# upstream remote追加（初回のみ）
git remote add upstream https://github.com/original-owner/repo.git

# 同期作業
git checkout develop
git fetch upstream
git merge upstream/develop
git push origin develop

4. 緊急時の対応

間違ってmainに直接プッシュした場合

# 直前のコミットを取り消し
git reset --hard HEAD~1
git push --force-with-lease origin main

# 取り消したコミットを別ブランチで再作成
git checkout -b hotfix/emergency-fix
git cherry-pick <commit-hash>
git push -u origin hotfix/emergency-fix

# PR作成してreview経由でマージ
gh pr create --base main

本番で重大なバグが発見された場合

# 1. 緊急hotfixブランチ作成
git checkout main
git pull origin main
git checkout -b hotfix/critical-security-fix

# 2. 最小限の修正
# ファイル編集...
git add .
git commit -m "fix(security): XSS脆弱性の緊急修正"

# 3. 即座にPR作成・レビュー・マージ
git push -u origin hotfix/critical-security-fix
gh pr create --base main --title "🚨 URGENT: XSS脆弱性修正"

# 4. developにも反映
git checkout develop
git merge main
git push origin develop

トラブルシューティング

よくある問題と解決方法

1. "Updates were rejected because the tip of your current branch is behind"

# リモートの変更を取り込んでから再プッシュ
git pull --rebase origin feature/my-feature
git push origin feature/my-feature

# または、force pushが安全な場合
git push --force-with-lease origin feature/my-feature

2. "fatal: refusing to merge unrelated histories"

# 履歴が関連していない場合（新しいリポジトリ等）
git pull origin main --allow-unrelated-histories

3. "error: failed to push some refs"

# 他の人が先にプッシュした場合
git fetch origin
git rebase origin/feature/my-feature
git push origin feature/my-feature

4. "detached HEAD state"

# HEADが特定のコミットを指している状態
git checkout main
# または新しいブランチを作成して保存
git checkout -b temp-branch

5. 巨大なファイルを間違ってコミットした場合

# Git履歴から完全に削除
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch path/to/large-file' \
  --prune-empty --tag-name-filter cat -- --all

# 強制プッシュ
git push --force-with-lease --all
git push --force-with-lease --tags

デバッグ用コマンド

# 設定確認
git config --list
git config --global --list

# リモート接続確認
ssh -T git@github.com

# ログレベル変更
GIT_TRACE=1 git pull origin main

# reflogで過去のHEAD位置確認
git reflog

# 特定のコミットが含まれるブランチ確認
git branch --contains <commit-hash>

ベストプラクティス

1. コミット粒度

良いコミット例

# 単一の責務に集中
git commit -m "feat(auth): ログイン機能の実装"
git commit -m "test(auth): ログイン機能のテスト追加"
git commit -m "docs(auth): ログイン機能のドキュメント追加"

# WIPコミットの活用
git commit -m "wip: ユーザー登録フォームの途中実装"

避けるべきコミット例

# 複数の変更を含む
git commit -m "認証機能とプロフィール機能とバグ修正"

# 意味のないメッセージ
git commit -m "fix"
git commit -m "update"
git commit -m "修正"

2. ブランチ管理

ブランチ命名規則

# 機能開発
feature/user-authentication
feature/payment-integration
feature/issue-123

# バグ修正
fix/login-validation-error
fix/responsive-layout-bug

# 緊急修正
hotfix/security-vulnerability
hotfix/payment-processing-error

# 実験的機能
experiment/new-ui-framework
experiment/performance-optimization

ブランチライフサイクル管理

# 定期的なブランチクリーンアップ
git branch --merged develop | grep -v develop | xargs -n 1 git branch -d
git remote prune origin

# 古いブランチの確認
git for-each-ref --format='%(refname:short) %(committerdate)' refs/heads | sort -k2

3. Pull Request作成

良いPRタイトル・説明例

## feat: ユーザー認証システムの実装

### 概要
JWT認証を使用したユーザー認証システムを実装しました。

### 変更内容
- [ ] ログイン・ログアウト機能
- [ ] 会員登録機能  
- [ ] パスワードリセット機能
- [ ] 認証状態の管理（Zustand）

### 技術的詳細
- JWT tokenの有効期限: 24時間
- リフレッシュトークン: 7日間
- パスワードハッシュ化: bcrypt

### テスト
- [ ] 単体テスト: 全てパス (15/15)
- [ ] 統合テスト: 全てパス (8/8)
- [ ] E2Eテスト: 全てパス (12/12)

### デザイン
- [ ] デザインレビュー完了
- [ ] モバイル対応確認済み
- [ ] アクセシビリティチェック完了

### セキュリティ
- [ ] OWASP Top 10対策確認
- [ ] 入力値検証実装
- [ ] SQL injection対策

### パフォーマンス
- [ ] Lighthouse Score: 95+
- [ ] 初期表示時間: 1.5秒以下
- [ ] API応答時間: 200ms以下

### 関連リンク
- Closes #123
- Related to #124
- Figmaデザイン: [リンク]

4. コードレビュー

レビューチェックリスト

## 機能面
- [ ] 要件を満たしているか
- [ ] エッジケースが考慮されているか
- [ ] エラーハンドリングが適切か

## コード品質
- [ ] 可読性が高いか
- [ ] 適切なコメントがあるか
- [ ] 命名規則に従っているか
- [ ] DRY原則が守られているか

## セキュリティ
- [ ] 入力値検証があるか
- [ ] 認証・認可が適切か
- [ ] 機密情報が露出していないか

## パフォーマンス
- [ ] 不要なレンダリングがないか
- [ ] メモリリークの可能性はないか
- [ ] 効率的なアルゴリズムか

## テスト
- [ ] 十分なテストカバレッジがあるか
- [ ] テストが意味のあるケースを網羅しているか

5. Git設定の最適化

基本設定

# ユーザー情報設定
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# デフォルトブランチ名
git config --global init.defaultBranch main

# 改行コード設定
git config --global core.autocrlf input  # Linux/Mac
git config --global core.autocrlf true   # Windows

# エディタ設定
git config --global core.editor "code --wait"

# プッシュ設定
git config --global push.default simple
git config --global push.followTags true

# 便利なエイリアス
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.pl pull
git config --global alias.ps push
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.unstage "reset HEAD --"
git config --global alias.last "log -1 HEAD"

.gitignore テンプレート

# Dependencies
node_modules/
.pnp
.pnp.js

# Production
/build
/dist
.next/

# Environment variables
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# IDE
.vscode/
.idea/
*.swp
*.swo

# OS
.DS_Store
Thumbs.db

# Testing
coverage/
.nyc_output

# Cache
.cache/
.parcel-cache/

CI/CDとの連携

1. GitHub Actions設定例

メインワークフロー (.github/workflows/main.yml)

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        node-version: [18.x, 20.x]
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linting
      run: npm run lint
    
    - name: Run type checking
      run: npm run type-check
    
    - name: Run tests
      run: npm run test:coverage
    
    - name: Run E2E tests
      run: npm run test:e2e
    
    - name: Upload coverage reports
      uses: codecov/codecov-action@v3

  build:
    needs: test
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20.x'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build application
      run: npm run build
    
    - name: Upload build artifacts
      uses: actions/upload-artifact@v3
      with:
        name: build-files
        path: dist/

  deploy-staging:
    needs: [test, build]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'
    
    environment: staging
    
    steps:
    - name: Deploy to Staging
      run: |
        echo "Deploying to staging environment"
        # Vercel, Netlify, or other staging deployment commands

  deploy-production:
    needs: [test, build]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    environment: production
    
    steps:
    - name: Deploy to Production
      run: |
        echo "Deploying to production environment"
        # Production deployment commands
    
    - name: Create GitHub Release
      if: startsWith(github.ref, 'refs/tags/')
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ github.ref }}
        release_name: Release ${{ github.ref }}
        draft: false
        prerelease: false

2. ブランチ保護ルール設定

GitHub リポジトリ設定

{
  "protection_rules": {
    "main": {
      "required_status_checks": {
        "strict": true,
        "contexts": ["test", "build"]
      },
      "enforce_admins": true,
      "required_pull_request_reviews": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews": true,
        "require_code_owner_reviews": true
      },
      "restrictions": null,
      "allow_force_pushes": false,
      "allow_deletions": false
    },
    "develop": {
      "required_status_checks": {
        "strict": true,
        "contexts": ["test", "build"]
      },
      "enforce_admins": false,
      "required_pull_request_reviews": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews": true
      }
    }
  }
}

3. 自動デプロイメント

Vercel設定例 (vercel.json)

{
  "git": {
    "deploymentEnabled": {
      "main": true,
      "develop": true
    }
  },
  "github": {
    "autoAlias": false
  },
  "alias": [
    {
      "src": "main",
      "dest": "myapp.vercel.app"
    },
    {
      "src": "develop", 
      "dest": "staging.myapp.vercel.app"
    }
  ]
}

チーム開発での考慮事項

1. チームルール設定

コミット規則統一

# commitlint設定
npm install --save-dev @commitlint/cli @commitlint/config-conventional

# .commitlintrc.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      ['feat', 'fix', 'docs', 'style', 'refactor', 'perf', 'test', 'chore']
    ],
    'subject-case': [2, 'never', ['pascal-case', 'upper-case']],
    'subject-max-length': [2, 'always', 50]
  }
};

# Husky設定
npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'

コードフォーマット統一

// .prettierrc
{
  "semi": false,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false
}

2. コードレビュー文化

レビュー基準

機能性: 要件を満たしているか
可読性: 他の開発者が理解できるか
保守性: 将来の変更に対応できるか
セキュリティ: 脆弱性がないか
パフォーマンス: 最適化されているか

レビューコメント例

# 良いフィードバック例

## 提案
この部分は `useMemo` を使用することでレンダリング性能を改善できそうです。

```typescript
// Before
const expensiveValue = calculateExpensiveValue(props.data);

// After  
const expensiveValue = useMemo(
  () => calculateExpensiveValue(props.data),
  [props.data]
);

質問

この setTimeout の遅延時間 500ms はどのような根拠で決められましたか？
ユーザビリティ観点から検討した値でしょうか？

重要

この実装だとSQLインジェクションの脆弱性があります。
必ずprepared statementを使用してください。


### 3. ドキュメント管理

#### READMEテンプレート
```markdown
# プロジェクト名

## 概要
プロジェクトの簡潔な説明

## 技術スタック
- Next.js 14
- TypeScript
- Tailwind CSS
- Prisma
- PostgreSQL

## 開発環境セットアップ

### 前提条件
- Node.js 18.0+
- Docker
- PostgreSQL

### インストール
```bash
# 依存関係インストール
npm install

# 環境変数設定
cp .env.example .env.local

# データベースセットアップ
docker-compose up -d postgres
npm run db:migrate

# 開発サーバー起動
npm run dev

ブランチ戦略

このプロジェクトは GitHubFlow を採用しています。

開発ワークフロー

Issues からタスクを選択
feature ブランチを作成
開発・テスト実装
Pull Request 作成
コードレビュー
develop ブランチにマージ

コーディング規約

テスト

# 単体テスト
npm run test

# E2Eテスト  
npm run test:e2e

# カバレッジ
npm run test:coverage

デプロイ

Staging: develop ブランチの変更で自動デプロイ
Production: main ブランチの変更で自動デプロイ

トラブルシューティング

よくある問題と解決方法は Troubleshooting Guide を参照


### 4. コミュニケーション

#### スラック連携例
```yaml
# .github/workflows/slack-notify.yml
name: Slack Notification

on:
  pull_request:
    types: [opened, closed, reopened]
  push:
    branches: [main]

jobs:
  slack-notify:
    runs-on: ubuntu-latest
    steps:
    - name: Slack Notification for PR
      if: github.event_name == 'pull_request'
      uses: 8398a7/action-slack@v3
      with:
        status: custom
        fields: repo,message,commit,author,action,eventName,ref,workflow
        custom_payload: |
          {
            text: "Pull Request ${{ github.event.action }}",
            attachments: [{
              color: '${{ job.status }}' === 'success' ? 'good' : 'danger',
              title: '${{ github.event.pull_request.title }}',
              title_link: '${{ github.event.pull_request.html_url }}',
              author_name: '${{ github.event.pull_request.user.login }}',
              fields: [{
                title: 'Repository',
                value: '${{ github.repository }}',
                short: true
              }, {
                title: 'Base Branch',
                value: '${{ github.event.pull_request.base.ref }}',
                short: true
              }]
            }]
          }
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

まとめ

このガイドは実際の開発現場でのGitHubFlow運用を想定して作成されました。重要なポイントは：

一貫性: チーム全体で同じルールを遵守
自動化: CI/CDによる品質担保とデプロイ自動化
透明性: すべての変更をPull Request経由で可視化
継続的改善: 定期的なルール見直しとプロセス改善

実際の運用では、チームの規模や技術スタック、デプロイ頻度などに応じてカスタマイズしてください。

更新履歴

2025-07-01: 初版作成
2025-07-01: CI/CD連携セクション追加
2025-07-01: トラブルシューティング拡充

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitHubFlow 実践ガイド - フルサイクル開発者のための現場手順書

GitHubFlow 実践ガイド - フルサイクル開発者のための現場手順書

目次

GitHubFlowの哲学と概要

基本哲学

フロー図

ブランチ戦略の詳細

1. main ブランチ

2. develop ブランチ

3. feature ブランチ

4. hotfix ブランチ

実践的ワークフロー

1. 新機能開発フロー（feature → develop）

Step 1: 開発環境の準備

Step 2: 開発作業

Step 3: Pull Request作成

Step 4: レビューとマージ

2. リリースフロー（develop → main）

Step 1: リリース準備

Step 2: リリースPR作成

Step 3: リリース実行

3. 緊急修正フロー（hotfix → main → develop）

Step 1: 緊急修正ブランチ作成

Step 2: 緊急PR作成・マージ

Step 3: developへの反映

よく使用するGitコマンド一覧

基本操作

コミット関連

マージ・リベース

状態確認・比較

高度な操作

GitHub CLI (gh) コマンド

シナリオ別対応方法

1. コンフリクト解決

マージコンフリクトが発生した場合

リベースコンフリクトの場合

2. 間違ったコミットの修正

直前のコミットメッセージを修正

間違ったファイルをコミットした場合

複数コミットを整理（squash）

3. ブランチの同期

developブランチの最新に追従

フォークしたリポジトリの同期

4. 緊急時の対応

間違ってmainに直接プッシュした場合

本番で重大なバグが発見された場合

トラブルシューティング

よくある問題と解決方法

1. "Updates were rejected because the tip of your current branch is behind"

2. "fatal: refusing to merge unrelated histories"

3. "error: failed to push some refs"

4. "detached HEAD state"

5. 巨大なファイルを間違ってコミットした場合

デバッグ用コマンド

ベストプラクティス

1. コミット粒度

良いコミット例

避けるべきコミット例

2. ブランチ管理

ブランチ命名規則

ブランチライフサイクル管理

3. Pull Request作成

良いPRタイトル・説明例

4. コードレビュー

レビューチェックリスト

5. Git設定の最適化

基本設定

.gitignore テンプレート

CI/CDとの連携

1. GitHub Actions設定例

メインワークフロー (.github/workflows/main.yml)

2. ブランチ保護ルール設定

GitHub リポジトリ設定

3. 自動デプロイメント

Vercel設定例 (vercel.json)

チーム開発での考慮事項

1. チームルール設定

コミット規則統一

コードフォーマット統一

2. コードレビュー文化