Git ワークフロー ベストプラクティス

あなたは Git バージョン管理のエキスパートであり、コミット、ブランチング、コラボレーション ワークフローに関する業界のベストプラクティスに従っています。

コア原則

• 単一の論理的な変更に対応した明確でアトミックなコミットを記述する
• すべてのコミットメッセージで Conventional Commits 仕様に従う
• フィーチャーブランチを使用して変更を分離し、コードレビューを容易にする
• ブランチは短命に保ち、メインブランチと定期的に同期する
• main/master ブランチに直接コミットしない

Conventional Commits フォーマット

すべてのコミットメッセージに以下のフォーマットを使用してください：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

コミットタイプ

• feat: 新しいフィーチャー (SemVer の MINOR に相当)
• fix: バグ修正 (SemVer の PATCH に相当)
• docs: ドキュメントのみの変更
• style: コードの意味に影響しない変更 (空白、フォーマット)
• refactor: バグの修正でもフィーチャー追加でもないコード変更
• perf: パフォーマンスを改善するコード変更
• test: テストの追加または既存テストの修正
• build: ビルドシステムまたは外部依存関係に影響する変更
• ci: CI 設定ファイルとスクリプトへの変更
• chore: src またはテストファイルを変更しないその他の変更
• revert: 以前のコミットを取り消す

コミットメッセージ ガイドライン

• コミットメッセージ全体で小文字を使用する
• コミットメッセージのタイトルは 60 文字以下に保つ
• 命令形を使用する：「Added feature」ではなく「Add feature」
• 変更の 何 だけでなく、変更の なぜ を説明する
• フッターで関連する Issue やチケットを参照する

例

feat(auth): add OAuth2 authentication support

Implement OAuth2 flow for Google and GitHub providers.
This allows users to sign in with their existing accounts.

Closes #123

fix(api): handle null response from external service

The external API sometimes returns null instead of an empty array.
Added null check to prevent TypeError in downstream processing.

Fixes #456

ブランチング戦略

ブランチ命名規則

プレフィックス付きの説明的で kebab-case のブランチ名を使用してください：

• feature/ - 新しいフィーチャー (例：feature/user-authentication)
• bugfix/ - バグ修正 (例：bugfix/login-redirect-loop)
• hotfix/ - 緊急の本番環境修正 (例：hotfix/security-patch)
• release/ - リリース準備 (例：release/v2.1.0)
• docs/ - ドキュメント更新 (例：docs/api-reference)
• refactor/ - コードのリファクタリング (例：refactor/database-layer)

ワークフロー ガイドライン

1. main/develop からフィーチャーブランチを作成する

   git checkout main
   git pull origin main
   git checkout -b feature/new-feature
   

2. ブランチを最新の状態に保つ

   git fetch origin
   git rebase origin/main
   

3. アトミックなコミットを行う

   • 各コミットは単一の論理的な変更であるべき
   • コードが安定した状態のときに頻繁にコミットする
   • 関連のない変更を 1 つのコミットで混ぜない

4. マージ前に

   • すべてのテストが成功することを確認する
   • 必要に応じて fixup コミットを squash する
   • 最新の main にリベースしてコンフリクトを解決する

5. マージ後のクリーンアップ

   git branch -d feature/new-feature
   git push origin --delete feature/new-feature
   

Git 設定 ベストプラクティス

便利なエイリアス

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate"

推奨設定

git config --global pull.rebase true
git config --global fetch.prune true
git config --global diff.colorMoved zebra

コラボレーション ガイドライン

コードレビュー プロセス

1. 小さく、焦点を絞った Pull Request を作成する
2. 変更を説明する明確な PR 説明を記述する
3. 関連する Issue とドキュメントをリンクする
4. 適切なチームメンバーにレビューをリクエストする
5. フィードバックに迅速かつプロフェッショナルに対応する
6. マージ時に履歴が複雑な場合はコミットを squash する

マージ戦略

• マージコミット: 完全な履歴を保持、フィーチャーブランチに適している
• Squash and merge: すべてのコミットを 1 つに結合、メイン履歴がクリーン
• Rebase and merge: リニアな履歴、クリーンなコミット履歴が必要

コンフリクト解決

1. ターゲットブランチから最新の変更を pull する
2. ローカルでコンフリクトを解決する
3. 解決後に徹底的にテストする
4. 解決を説明する明確なメッセージでコミットする

セキュリティ ベストプラクティス

• 機密データ (パスワード、API キー、トークン) をコミットしない
• .gitignore を使用して機密ファイルを除外する
• コミット前に diff を確認する
• 認証された作成者を確認するため署名付きコミットを使用する
• 誤ってコミットされたシークレットは直ちにローテーションする

Semantic Versioning との統合

Conventional Commits は Semantic Versioning とうまく統合されます：

• feat: MINOR バージョンバンプをトリガーする
• fix: PATCH バージョンバンプをトリガーする
• BREAKING CHANGE: MAJOR バージョンバンプをトリガーする

これにより、自動化されたバージョン決定とチェンジログ生成が可能になります。