git-flow-branch-creator

説明

<instructions>
	<title>Git Flow Branch Creator</title>
	<description>このプロンプトは git status と git diff (または git diff --cached) を使用して現在の git 変更を分析し、Git Flow ブランチングモデルに従って適切なブランチタイプをインテリジェントに判定し、セマンティックなブランチ名を作成します。</description>
	<note>
		このプロンプトを実行するだけで、Copilot があなたの変更を分析し、適切な Git Flow ブランチを作成します。
	</note>
</instructions>

ワークフロー

以下の手順に従ってください:

1. git status を実行して現在のリポジトリの状態と変更されたファイルを確認します。
2. git diff (ステージされていない変更の場合) または git diff --cached (ステージされた変更の場合) を実行して変更の性質を分析します。
3. 下記の Git Flow ブランチ分析フレームワークを使用して変更を分析します。
4. 分析に基づいて適切なブランチタイプを決定します。
5. Git Flow の規則に従ってセマンティックなブランチ名を生成します。
6. ブランチを作成し、自動的に切り替えます。
7. 分析と次のステップの概要を提供します。

Git Flow ブランチ分析フレームワーク

<analysis-framework>
	<branch-types>
		<feature>
			<purpose>新機能、拡張機能、重大でない改善</purpose>
			<branch-from>develop</branch-from>
			<merge-to>develop</merge-to>
			<naming>feature/descriptive-name or feature/ticket-number-description</naming>
			<indicators>
				<indicator>新機能の追加</indicator>
				<indicator>UI/UX の改善</indicator>
				<indicator>新しい API エンドポイントまたはメソッド</indicator>
				<indicator>データベーススキーマの追加 (破壊的でない)</indicator>
				<indicator>新しい設定オプション</indicator>
				<indicator>パフォーマンス改善 (重大でない)</indicator>
			</indicators>
		</feature>

		<release>
			<purpose>リリース準備、バージョンアップ、最終テスト</purpose>
			<branch-from>develop</branch-from>
			<merge-to>develop AND master</merge-to>
			<naming>release-X.Y.Z</naming>
			<indicators>
				<indicator>バージョン番号の変更</indicator>
				<indicator>ビルド設定の更新</indicator>
				<indicator>ドキュメントの最終化</indicator>
				<indicator>リリース前のマイナーバグ修正</indicator>
				<indicator>リリースノートの更新</indicator>
				<indicator>依存関係バージョンのロック</indicator>
			</indicators>
		</release>

		<hotfix>
			<purpose>即座のデプロイが必要な本番環境の重大バグ修正</purpose>
			<branch-from>master</branch-from>
			<merge-to>develop AND master</merge-to>
			<naming>hotfix-X.Y.Z or hotfix/critical-issue-description</naming>
			<indicators>
				<indicator>セキュリティ脆弱性の修正</indicator>
				<indicator>本番環境の重大なバグ</indicator>
				<indicator>データ破損の修正</indicator>
				<indicator>サービス停止の解決</indicator>
				<indicator>緊急設定の変更</indicator>
			</indicators>
		</hotfix>
	</branch-types>
</analysis-framework>

ブランチ命名規則

<naming-conventions>
	<feature-branches>
		<format>feature/[ticket-number-]descriptive-name</format>
		<examples>
			<example>feature/user-authentication</example>
			<example>feature/PROJ-123-shopping-cart</example>
			<example>feature/api-rate-limiting</example>
			<example>feature/dashboard-redesign</example>
		</examples>
	</feature-branches>

	<release-branches>
		<format>release-X.Y.Z</format>
		<examples>
			<example>release-1.2.0</example>
			<example>release-2.1.0</example>
			<example>release-1.0.0</example>
		</examples>
	</release-branches>

	<hotfix-branches>
		<format>hotfix-X.Y.Z OR hotfix/critical-description</format>
		<examples>
			<example>hotfix-1.2.1</example>
			<example>hotfix/security-patch</example>
			<example>hotfix/payment-gateway-fix</example>
			<example>hotfix-2.1.1</example>
		</examples>
	</hotfix-branches>
</naming-conventions>

分析プロセス

<analysis-process>
	<step-1>
		<title>変更の性質分析</title>
		<description>変更されたファイルのタイプと変更の性質を検証します</description>
		<criteria>
			<files-modified>ファイル拡張子、ディレクトリ構造、目的を確認します</files-modified>
			<change-scope>変更が加算的、修正的、または準備的かを判定します</change-scope>
			<urgency-level>変更が重大な問題に対処するか、開発的であるかを評価します</urgency-level>
		</criteria>
	</step-1>

	<step-2>
		<title>Git Flow 分類</title>
		<description>変更を適切な Git Flow ブランチタイプにマッピングします</description>
		<decision-tree>
			<question>これは本番環境の問題に対する重大な修正ですか？</question>
			<if-yes>hotfix ブランチを検討します</if-yes>
			<if-no>
				<question>これはリリース準備の変更ですか (バージョンアップ、最終調整)？</question>
				<if-yes>release ブランチを検討します</if-yes>
				<if-no>デフォルトで feature ブランチを使用します</if-no>
			</if-no>
		</decision-tree>
	</step-2>

	<step-3>
		<title>ブランチ名生成</title>
		<description>セマンティックで説明的なブランチ名を作成します</description>
		<guidelines>
			<use-kebab-case>小文字でハイフンを使用します</use-kebab-case>
			<be-descriptive>名前は目的を明確に示すべきです</be-descriptive>
			<include-context>利用可能な場合、チケット番号やプロジェクトコンテキストを追加します</include-context>
			<keep-concise>過度に長い名前を避けます</keep-concise>
		</guidelines>
	</step-3>
</analysis-process>

エッジケースと検証

<edge-cases>
	<mixed-changes>
		<scenario>変更に機能とバグ修正の両方が含まれている</scenario>
		<resolution>最も重要な変更タイプを優先するか、複数のブランチに分割することを提案します</resolution>
	</mixed-changes>

	<no-changes>
		<scenario>git status/diff で変更が検出されない</scenario>
		<resolution>ユーザーに通知し、git status の確認または最初に変更を行うことを提案します</resolution>
	</no-changes>

	<existing-branch>
		<scenario>既に feature/hotfix/release ブランチ上にいる</scenario>
		<resolution>新しいブランチが必要か、または現在のブランチが適切かを分析します</resolution>
	</existing-branch>

	<conflicting-names>
		<scenario>提案されたブランチ名が既に存在する</scenario>
		<resolution>増分サフィックスを追加するか、別の名前を提案します</resolution>
	</conflicting-names>
</edge-cases>

例

<examples>
	<example-1>
		<scenario>新しいユーザー登録 API エンドポイントを追加</scenario>
		<analysis>新機能、加算的な変更、重大ではない</analysis>
		<branch-type>feature</branch-type>
		<branch-name>feature/user-registration-api</branch-name>
		<command>git checkout -b feature/user-registration-api develop</command>
	</example-1>

	<example-2>
		<scenario>認証の重大なセキュリティ脆弱性を修正</scenario>
		<analysis>セキュリティ修正、本番環境の重大な問題、即座のデプロイが必要</analysis>
		<branch-type>hotfix</branch-type>
		<branch-name>hotfix/auth-security-patch</branch-name>
		<command>git checkout -b hotfix/auth-security-patch master</command>
	</example-2>

	<example-3>
		<scenario>バージョンを 2.1.0 に更新し、リリースノートを最終化</scenario>
		<analysis>リリース準備、バージョンアップ、ドキュメント</analysis>
		<branch-type>release</branch-type>
		<branch-name>release-2.1.0</branch-name>
		<command>git checkout -b release-2.1.0 develop</command>
	</example-3>

	<example-4>
		<scenario>データベースクエリパフォーマンスを改善し、キャッシング機能を更新</scenario>
		<analysis>パフォーマンス改善、重大でない拡張機能</analysis>
		<branch-type>feature</branch-type>
		<branch-name>feature/database-performance-optimization</branch-name>
		<command>git checkout -b feature/database-performance-optimization develop</command>
	</example-4>
</examples>

検証チェックリスト

<validation>
	<pre-analysis>
		<check>リポジトリが競合するコミットされていない変更がない状態である</check>
		<check>現在のブランチが適切な開始ポイントである (feature/release は develop、hotfix は master)</check>
		<check>リモートリポジトリが最新の状態である</check>
	</pre-analysis>

	<analysis-quality>
		<check>変更の分析がすべての変更されたファイルをカバーしている</check>
		<check>ブランチタイプの選択が Git Flow の原則に従っている</check>
		<check>ブランチ名がセマンティックで規則に従っている</check>
		<check>エッジケースが考慮され、処理されている</check>
	</analysis-quality>

	<execution-safety>
		<check>ターゲットブランチ (develop/master) が存在し、アクセス可能である</check>
		<check>提案されたブランチ名が既存ブランチと競合しない</check>
		<check>ユーザーがブランチを作成する適切な権限を持っている</check>
	</execution-safety>
</validation>

最終実行

<execution-protocol>
	<analysis-summary>
		<git-status>git status コマンドの出力</git-status>
		<git-diff>git diff 出力の関連部分</git-diff>
		<change-analysis>変更が何を表すかの詳細な分析</change-analysis>
		<branch-decision>特定のブランチタイプが選択された理由の説明</branch-decision>
	</analysis-summary>

	<branch-creation>
		<command>git checkout -b [branch-name] [source-branch]</command>
		<confirmation>ブランチ作成と現在のブランチの状態を確認</confirmation>
		<next-steps>次のアクション (変更のコミット、ブランチのプッシュなど) のガイダンスを提供</next-steps>
	</branch-creation>

	<fallback-options>
		<alternative-names>主な提案が適切でない場合、2～3 個の代替ブランチ名を提案</alternative-names>
		<manual-override>分析が正確でないと思われる場合、ユーザーが別のブランチタイプを指定できるようにします</manual-override>
	</fallback-options>
</execution-protocol>

Git Flow リファレンス

<gitflow-reference>
	<main-branches>
		<master>本番環境対応コード、すべてのコミットはリリース</master>
		<develop>機能統合ブランチ、最新開発変更</develop>
	</main-branches>

	<supporting-branches>
		<feature>develop からブランチ、develop にマージバック</feature>
		<release>develop からブランチ、develop と master 両方にマージ</release>
		<hotfix>master からブランチ、develop と master 両方にマージ</hotfix>
	</supporting-branches>

	<merge-strategy>
		<flag>ブランチ履歴を保持するために常に --no-ff フラグを使用します</flag>
		<tagging>master ブランチのリリースにタグを付けます</tagging>
		<cleanup>マージ成功後にブランチを削除します</cleanup>
	</merge-strategy>
</gitflow-reference>