specsfy-specialist-gitflow

Gitflow

使用する場面

• ユーザーが Gitflow モデル（main／master、develop、feature/*、release/*、hotfix/* ブランチ）を明示的に求めた場合、または git flow の設定（git config --get-regexp '^gitflow\.'）がすでに存在する場合、あるいはプロジェクトの指示でその選択が宣言されている場合に使用します。
• Gitflow をブランチ戦略としてすでに宣言しているプロジェクト内で、feature/、release/、hotfix/ ブランチの命名、順序付け、または終了を行う場合にも使用します。
• Gitflow を求めていないプロジェクトに Gitflow を提案するためには使用しません。ブランチモデルの選択はプロジェクトを進行する人が明示的に決めるものであり、develop という名前のブランチが存在することや、オープン中のブランチ数から推測してはいけません。
• すでに進行中の競合（$specsfy-specialist-merge-conflict-resolution）の解決や、環境間のパイプラインまたはアーティファクト昇格（$specsfy-specialist-delivery-engineering）の設計には使用しません。ここで扱うのはブランチのトポロジーとポリシーであり、テキスト上の競合解決やデリバリーではありません。

フロー

1. 慣例を適用する前に、ユーザーが Gitflow を明示的に求めたことを確認するか、その選択をすでに宣言している設定や指示を示します。リポジトリの構成から Gitflow を推測してはいけません。
2. ブランチの実際の状態（git branch -a、git config --get-regexp '^gitflow\.'）を確認し、main／master と develop がすでに存在するか、補助ブランチの命名が採用済みの標準と異なっていないかを把握します。
3. 恒久ブランチの名前（本番用の main、統合用の develop）と、短命ブランチのプレフィックス（該当する場合は feature/、release/、hotfix/、support/）をユーザーと決めます。
4. その決定をプロジェクトの確定ルールとして記録します（$specsfy-aux-rules が .specsfy/RULES.md に記録します）。プレフィックス、各種ブランチのマージ先、マージポリシーを含め、慣例を口頭だけで済ませてはいけません。
5. 各種ブランチの作成、統合、終了について案内します。feature/* は develop から作成して develop に戻し、release/* は develop から作成して main と develop にマージし、hotfix/* は main から作成して main と develop にマージします。いずれも merge --no-ff を使用します。
6. release/* または hotfix/* を main にマージする際のバージョンタグ付けを調整し、プロジェクトですでに採用されているバージョン管理戦略（semver など）に合わせます。
7. サイクルを終了とみなす前に、release/* または hotfix/* で適用した修正がすべて develop に戻されていることを確認します。ここでの差異は次のリリースでのリグレッションとして再び現れます。

標準

• feature/*、release/*、hotfix/* の統合にはすべて git merge --no-ff を使用します。fast-forward マージでは、そのブランチが存在した記録が消えてしまい、Gitflow のリリース監査はその記録に依存しています。
• 一貫したプレフィックスと同じ区切り文字をプロジェクト全体で使用します（feature/<slug>、release/<versao>、hotfix/<versao-ou-slug>）。同じリポジトリ内で feature-x と feature/y のような慣例を混在させてはいけません。
• release/* と hotfix/* は、対応する develop または main のコミットから正確に作成し、まだ統合されていないコミットを選択的に cherry-pick してはいけません。
• release/* にはバグ修正、テキスト、ドキュメント、リリース準備（変更履歴、バージョン）のみを適用します。新機能は、すでに開かれているリリースブランチには追加せず、次の feature/* に戻します。
• すべての hotfix/* は、同じ作業で main（タグ付き）と develop（または、開いている場合は release/*）にマージして終了します。main にしか届かない hotfix は、次のリリースに反映されません。
• 短命ブランチ（feature/*、release/*、hotfix/*）は、両方のマージ先でマージが確認された後に削除します。終了したブランチを削除しないと、すでに統合されたコードに対する作業のやり直しを招きます。

アンチパターン

• feature/、release/、hotfix/ を経由せずに main／develop へ直接プッシュしたり、fast-forward マージしたりすると、よりシンプルなモデルではなく Gitflow を採用する根拠となる追跡可能性が損なわれます。
• すでに開始した release/* に「この機会に」と新機能を追加すると、リリースカット後にテスト対象の範囲が広がり、必要なくリリースが遅れます。
• hotfix を main にだけマージし、develop を別の状態のままにすると、develop から切った次の release/* で、本番環境ですでに修正済みのバグが再発します。
• 1日に何度も継続的デプロイを行うプロジェクトで Gitflow を採用すると、長期間存続する release／hotfix ブランチのオーバーヘッドが継続的デリバリーと相容れません。このような状況では、慣習で Gitflow を適用する前に、GitHub Flow と trunk-based のどちらが適しているかを担当者と検討してください。
• 「develop という名前のブランチがある」ことと「プロジェクトが Gitflow を使っている」ことを混同すると、マージポリシー、プレフィックス、リリースサイクルが完全に整っていない場合、単にその名前のブランチがあるだけで、Gitflow モデルを採用しているとは言えません。

検証

• git log --graph --oneline --all（または git log --first-parent main）で、各 feature/、release/、hotfix/ の --no-ff マージが、判別可能なマージコミットとして表示され、見分けのつかない線形コミットになっていないことを確認します。
• 寿命の短いブランチを削除する前に git branch -a --merged develop と git branch -a --merged main を確認し、想定される両方の宛先に実際にマージされていることを確かめます。
• 完了した各 release/* または hotfix/* について、バージョンタグが main に存在すること（git tag --contains <commit-do-merge>）と、同じ修正が develop に存在すること（git log develop --oneline | grep <commit> または同等の方法）を確認します。
• .specsfy/RULES.md（または同等のプロジェクト指示）に命名規則とマージポリシーが記載されていることを確認し、違反があった場合は $specsfy-aux-rules で見直します。
• develop ブランチがあるという理由だけで「プロジェクトは Gitflow に従っている」と宣言しないでください。根拠として、一貫したプレフィックス、追跡可能な --no-ff マージ、および両方の宛先で完了した release／hotfix サイクルが必要です。

関連するスキル

• 進行中の feature/、release/、hotfix/ の統合で競合が発生した場合は、$specsfy-specialist-merge-conflict-resolution を使用します。このスキルはブランチのトポロジーとポリシーを決定し、もう一方のスキルはすでに発生しているテキスト上または意味上の競合を解決します。
• main へのマージやリリースタグをきっかけに、パイプライン、成果物のビルド、環境間の昇格を実行する必要がある場合は、$specsfy-specialist-delivery-engineering を使用します。このスキルは適切なブランチとタグを用意し、もう一方のスキルはパイプラインの反応を決定します。

ブランチの全体像、Gitflow に相当する Git 純正のコマンド、およびモデルの公式情報源については、references/standards.md をお読みください。