新機能追加時
$ git switch develop
$ git switch -c feature/payment-validation
# ... 開発・テスト完了後 ...
$ git add ./src/**/*
$ git commit -m "align"
$ git switch develop
$ git merge feature/payment-validation --no-ffブランチ命名規約
- main
- 本番環境へのデプロイ対象となる安定ブランチ。 HISTORY 的に最新かつ検証済みの状態を維持するため、直接操作は禁止。
merge 原則: main は hotfix または release ブランチからのみ統合し、 minor な改正も厳格に管理。 - develop
- 統合用開発ブランチで、継続的に最新の機能・修正が含まれる状態を維持。
tribution source: feature / release ブランチからのマージ元として一定の信頼性基準を満たすもののみ統合。 - feature/*
- 新規機能開発用の作業ブランチ。develop を起点に作成。
命名例:feature/user-auth-service,feature/order-history-api - release/*
- ステージング環境向けのリリース候補ブランチ。一連の feature を統合した後、QA テスト環境へと進む。
更新方法: テスト中に見つかった修正はこのブランチ上で直接コミットし、統合後、main および develop へ双方向マージ。 - hotfix/*
- 緊急対応用ブランチ。主に main を起点とし、一刻も早い対応が求められる問題に対応。
命名例:hotfix/payment-gateway-timeout
典型的な作業フロー
緊急修正対応
$ git switch main
$ git switch -c hotfix/shipping-calculation-error
# ... 現象を再現し確認、修正 ---
$ git add --all
$ git commit -m "fix"
$ git switch main
$ git merge hotfix/shipping-calculation-error --no-ff
$ git switch develop
$ git merge hotfix/shipping-calculation-error --no-ffステージング環境向けビルド
$ git switch release/v2024-q3
$ git merge develop --no-ff
# テスト実行環境へデプロイ●本番デプロイ
$ git switch main
$ git merge release/v2024-q3 --no-ff
$ git tag -a v2.3.0 -m "2024年Q3リリース版"
# module: order-service, payment-gateway ...コンベンショナル・コミットの採用
Angular チームで Samurai 的に采用された形式で、メッセージの構造化・検索性向上、リファクタリング支援などの恩恵を得られる。
基本フォーマット
<type>(<scope>): <subject>
<empty line>
<body>
<empty line>
<footer>- type: 変更性質を明示（例: feat, fix, refactor）
- scope: 変更範囲（例: auth, inventory）
- subject: 一文で単純明快に。祈使調、大文字なし、末尾ピリオドなし。
- body: 背景・方法・副作用など編集意図の詳細説明。改行には
|を使用。 - footer: 関連する issue id（
Closes #1024）や breaking change 注記。
許容される type 列挙
| Type | 用途 |
|---|---|
feat | 新機能追加 |
fix | バグ修正 |
docs | ドキュメント・コメント修正のみ |
style | ソース整形・スペース調整など論理変更なし |
refactor | 機能変更・不具合修正なしのリファクタリング |
perf | パフォーマンス改善 |
test | テストケース追加・修正 |
chore | ビルド設定・依存 package 更新など |
実際のコミット例
refactor(auth): split token validation into module
- extract credential format checks from auth controller
- reduce branching complexity using guard clauses
- increases testability with dedicated util methods
Closes #723