git-workflow

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

Git のバージョン管理に精通し、コミット、ブランチ、コラボレーションのワークフローに関する業界のベストプラクティスに従います。

基本原則

• 1 つの論理的な変更に対応する、明確でアトミックなコミットを作成します
• すべてのコミットメッセージで Conventional Commits の仕様に従います
• 変更を分離してコードレビューを容易にするため、フィーチャーブランチを使用します
• ブランチの存続期間を短く保ち、定期的に main ブランチと同期します
• 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 ファイルや test ファイルを変更しないその他の変更
• revert：以前のコミットの取り消し

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

• コミットメッセージの本文全体で小文字を使用します
• コミットメッセージのタイトルは 60 文字未満にします
• 命令形を使います：「Add feature」ではなく「Added 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 コミットをスカッシュします
   • 最新の 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. 小規模で、対象を絞ったプルリクエストを作成します
2. 変更内容を説明する、明確な PR の説明を記述します
3. 関連する issue やドキュメントへのリンクを追加します
4. 適切なチームメンバーにレビューを依頼します
5. フィードバックには迅速かつプロフェッショナルに対応します
6. 履歴が煩雑な場合は、マージ時にコミットをスカッシュします

マージ戦略

• マージコミット：完全な履歴を保持するため、フィーチャーブランチに適しています
• スカッシュしてマージ：すべてのコミットを 1 つにまとめ、main の履歴をすっきりさせます
• リベースしてマージ：直線的な履歴になりますが、コミット履歴を整理しておく必要があります

コンフリクトの解決

1. 対象ブランチから最新の変更を取得します
2. ローカルでコンフリクトを解決します
3. 解決後に十分なテストを実施します
4. 解決内容を説明する明確なメッセージを付けてコミットします

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

• 機密データ（パスワード、API キー、トークン）をコミットしないでください
• .gitignore を使用して機密ファイルを除外します
• コミット前に差分を確認します
• 作成者を検証できるよう、署名付きコミットを使用します
• 誤ってコミットしたシークレットは、直ちにローテーションします

セマンティックバージョニングとの統合

Conventional Commits はセマンティックバージョニングと相性がよいです。

• feat：MINOR バージョンの更新をトリガーします
• fix：PATCH バージョンの更新をトリガーします
• BREAKING CHANGE：MAJOR バージョンの更新をトリガーします

これにより、バージョンの自動決定と変更履歴の生成が可能になります。