02_git

GitHub Flow ワークフロー

このドキュメントでは、開発サイクルとしてのブランチ管理の方法と、コミットとプルリクエストの作成に関するベストプラクティスを説明します。 開発サイクルとして GitHub Flow を採用します。main ブランチにマージ済みの feature ブランチはローカルとリモートの両方とも削除します。

GitHub Flow の基本ステップ

GitHub Flow は以下の 6 つの基本ステップで構成されるシンプルなワークフローです：

1. ブランチの作成: mainブランチから新しい機能ブランチを作成
2. 変更の追加: 機能の実装やバグ修正を行い、適切にコミット
3. プルリクエストの作成: 変更をレビューするためのプルリクエストを作成
4. レビューと議論: コードレビューを行い、必要に応じて変更を加える
5. デプロイとテスト: 変更をテスト環境にデプロイして検証
6. マージ: レビューとテストが完了したらmainブランチにマージ

1. ブランチの作成

新しい機能やバグ修正を開始する際は、常に最新のmainブランチから新しいブランチを作成します：

# 最新のmainブランチを取得
git checkout main
git pull origin main

# 新しい機能ブランチを作成
git checkout -b feature/new-feature-name

ブランチ名の命名規則：

• 機能追加: feature/機能名
• バグ修正: fix/バグ内容
• リファクタリング: refactor/内容
• ドキュメント: docs/内容

なお、Git のブランチ名は英語で文法的に適切に 3 ～ 5 語程度の長さで命名します。

2. 変更の追加とコミットの作成

機能ブランチで作業を行い、小さな単位で変更をコミットします。コミットを作成する際は、以下の手順に従います：

1. 変更の確認

# 未追跡ファイルと変更の確認
git status

# 変更内容の詳細確認
git --no-pager diff

# コミットメッセージのスタイル確認
git --no-pager log

2. 変更の分析

• 変更または追加されたファイルの特定
• 変更の性質（新機能、バグ修正、リファクタリングなど）の把握
• プロジェクトへの影響評価
• 機密情報の有無確認

3. コミットメッセージの作成

• 「なぜ」に焦点を当てる
• 明確で簡潔な言葉を使用
• 変更の目的を正確に反映
• 一般的な表現を避ける
• コミットメッセージは常に英語で記述する

4. コミットの実行

# 関連ファイルのみをステージング
git add <files>

# コミットメッセージの作成（HEREDOCを使用）
git commit -m "$(cat <<'EOF'
feat: ユーザー認証にResult型を導入

- エラー処理をより型安全に
- エラーケースの明示的な処理を強制
- テストの改善

🤖 ${K4}で生成
Co-Authored-By: Cline (Claude) noreply@anthropic.com
EOF
)"

3. プルリクエストの作成

変更が完了したら、リモートリポジトリにプッシュしてプルリクエストを作成します：

# リモートリポジトリにプッシュ
git push -u origin feature/new-feature-name

プルリクエストを作成する際は、以下の手順に従います：

1. ブランチの状態確認

# 未コミットの変更確認
git status

# 変更内容の確認
git --no-pager diff

# mainからの差分確認
git --no-pager diff main...HEAD

# コミット履歴の確認
git --no-pager log

2. 変更の分析

• main から分岐後のすべてのコミットの確認
• 変更の性質と目的の把握
• プロジェクトへの影響評価
• 機密情報の有無確認

3. プルリクエストの作成

• Pull Request のタイトルと説明は英語で記述する
• Issue、コメント、タグなど GitHub に残る記録はすべて英語で記述する

# プルリクエストの作成（HEREDOCを使用）
gh pr create --title "feat: Result型によるエラー処理の改善" --body "$(cat <<'EOF'
## 概要

エラー処理をより型安全にするため、Result型を導入しました。

## 変更内容

- neverthrowを使用したResult型の導入
- エラーケースの明示的な型定義
- テストケースの追加

## レビューのポイント

- Result型の使用方法が適切か
- エラーケースの網羅性
- テストの十分性
EOF
)"

4. レビューと議論

プルリクエストが作成されたら、チームメンバーによるコードレビューを行います：

• レビューコメントに対応して必要な変更を加える
• 追加の変更は同じブランチにコミットしてプッシュする
• 議論が解決したらレビュアーの承認を得る

5. デプロイとテスト

多くの場合、プルリクエストの変更はテスト環境に自動的にデプロイされます：

• デプロイされた環境で機能が正しく動作することを確認
• 必要に応じて追加のテストを実行
• 問題が見つかった場合は修正してプッシュ

6. マージと後処理

レビューとテストが完了したら、プルリクエストをmainブランチにマージします：

# GitHubのUIでマージするか、コマンドラインの場合：
git checkout main
git merge --no-ff feature/new-feature-name
git push origin main

# マージ済みのブランチを削除
git branch -d feature/new-feature-name
git push origin --delete feature/new-feature-name

重要な注意事項

1. コミット関連

   • 可能な場合は git commit -am を使用
   • 関係ないファイルは含めない
   • 空のコミットは作成しない
   • git 設定は変更しない

2. プルリクエスト関連

   • 必要に応じて新しいブランチを作成
   • 変更を適切にコミット
   • リモートへのプッシュは -u フラグを使用
   • すべての変更を分析

3. 避けるべき操作

   • 対話的な git コマンド（-i フラグ）の使用
   • リモートリポジトリへの直接プッシュ
   • git 設定の変更

コミットメッセージの例

# 新機能の追加
feat: Result型によるエラー処理の導入

# 既存機能の改善
update: キャッシュ機能のパフォーマンス改善

# バグ修正
fix: 認証トークンの期限切れ処理を修正

# リファクタリング
refactor: Adapterパターンを使用して外部依存を抽象化

# テスト追加
test: Result型のエラーケースのテストを追加

# ドキュメント更新
docs: エラー処理のベストプラクティスを追加

# 見た目の変更（コード動作に影響しない）
style: ボタンを押しやすくするためにラベルテキストの左右余白を増加

プルリクエストの例

## 概要

TypeScript のエラー処理をより型安全にするため、Result 型を導入しました。

## 変更内容

- neverthrow ライブラリの導入
- API クライアントでの Result 型の使用
- エラーケースの型定義
- テストケースの追加

## 技術的な詳細

- 既存の例外処理を Result 型に置き換え
- エラー型の共通化
- モック実装の改善

## レビューのポイント

- Result 型の使用方法が適切か
- エラーケースの網羅性
- テストの十分性