oma-scm

ソフトウェア構成管理

スケジューリング

目標

対象範囲を明確にし、追跡可能なコミットと復旧可能な履歴を維持しながら Git 操作を実行します。

意図シグネチャ

• コミット、ステージング、プッシュ、ブランチ操作、マージ、リベース、競合の解決、ワークツリーの管理、または SCM ガバナンスの確認を行います。

使用する場合

• Conventional Commit メッセージや論理的な分割を含む、コミットおよびプッシュの依頼。
• ブランチや履歴の操作、リリース、ベースライン、CODEOWNERS、構成管理のレビュー。

使用しない場合

• 機能の実装やアプリケーションコードの修正 -> 担当の専門家を使用します。
• 一般的な要件の計画 -> oma-pm を使用します。セキュリティ／テストのレビュー -> oma-qa を使用します。

想定される入力

依頼された Git 操作、リポジトリの状態、プロジェクト設定で有効になっている scm 設定。

想定される出力

依頼された Git の変更または助言計画、コミット／ブランチ識別子、実施したチェック、未解決の作業。

依存関係

Git CLI、プロジェクト設定、フック。選択した操作に関するものだけ、以下のリファレンスを読みます。

構造的なフロー

開始

ブランチ、上流ブランチ、ステージ済み／未ステージの変更、既存の承認を確認します。以下のコミット手順、またはより広範な操作に関する構成管理リソースを選択します。

遷移

• コミットのみの依頼：コミット後に完了します。依頼された場合、または該当するワークフローで必要な場合に限り、プッシュまたは PR の作成を行います。
• 独立した変更：機能ごとに分割します。コード、テスト、ドキュメントにまたがっても、論理的にひとまとまりの変更は 1 つのコミットにします。ただし、明示的なグループ化の指示がある場合はそちらを優先します。ファイル数は判断が分かれる場合の基準に限ります（ファイルが 5 個以下なら、単一コミットに傾けます）。
• ガバナンス、ワークツリー、リリース、履歴の操作：resources/cm-operations.md を読み込みます。
• 大規模なマージ：マージ順序や復旧手順を選ぶ前に、resources/merge-risk.md を読み込みます。
• デフォルトブランチへのプッシュ：以下の「プッシュと PR の安全性」セクションを適用します。

失敗と復旧

失敗	復旧
無関係な未コミットまたはステージ済みのファイルがある	依頼されたコミットの対象外にします。amend に黙って含めることは決してしません
コミットフックがメッセージを拒否する	フックに従ってメッセージまたは実際の不具合を修正します。フックを回避しません
プッシュが non-fast-forward で失敗する	fetch して差分を確認し、ローカルで統合します。force で再試行しません
変更が競合する	両方の意図を保って解決し、完了前に影響を受けるチェックを実行します
提案された diff にシークレットが含まれている可能性が高い	ステージングの前に停止し、値を明かさずに該当するパスを特定します

終了

作成したコミット／参照と検証結果を報告します。コミットの失敗、プッシュの拒否、競合の未解決は完了ではありません。

論理操作

標準のコマンド手順

1. ワークツリーと最近の規約を確認します：

   git status -sb
   git diff --staged
   git diff
   git log --oneline -5
   

2. 「遷移」に従って論理的なコミットグループを選択します。メッセージの構文、タイプ、フッター、ブランチの命名については resources/conventional-commits.md を読み、リポジトリのフック／設定による制限を適用します。
3. 選択したメッセージを提示します。明示的なパスをステージングし、ステージ済みの diff を確認して、準備したメッセージファイルを使ってコミットします：

   git add -- <specific-files>
   git diff --cached --check
   git diff --cached
   git commit -F <message-file>
   

4. 作成されたコミットと残りのワークツリーを確認します。プッシュが依頼されている場合は、「プッシュと PR の安全性」に従い、リモートでの結果を報告します。

ガードレール

1. 明示的で曖昧さのないユーザー指示は、コミットのグループ化やデフォルトブランチへの直接プッシュを含め、SCM のデフォルトより優先されます。既存の許可は引き続き有効です。再度確認を求めないでください。秘密情報と思われる内容がある場合は、ステージング前に必ず停止してください。
2. 明示されたパスをステージングしてください。明示的な許可がない限り、git add -A や git add . を使用しないでください。また、認証情報や秘密ファイルを絶対に含めないでください。
3. 明示的な許可なしに、共有履歴を書き換えないでください。書き換えが許可されている場合は、--force ではなく、--force-with-lease を使用してください。
4. amend の前にステージ済み差分を確認してください。プッシュされていないコミットは、依頼された範囲内で amend または再編成できます。プッシュ済みコミットは共有履歴です。
5. ユーザー向けの応答は設定された言語に従ってください。コミットメッセージ、ブランチ名、PR のタイトルと本文は英語のままにしてください。

プッシュと PR の安全対策（依頼された場合のみ）

• プッシュ前に、ブランチ、アップストリーム、先行／遅延状態を確認してください。
• scm.require_pr_for_default_branch が true の場合、ユーザーが直接プッシュを明示的に依頼していない限り、デフォルトブランチへの変更にはトピックブランチと PR を使用してください。
• リポジトリで必須のフックとチェックを維持してください。失敗した場合は修正するか、部分的な結果を正確に伝えてください。成功したと主張してはいけません。
• 依頼されたコミットが意図したリモートブランチに到達したことを確認してください。

amend、fixup、autosquash

アップストリームがある場合は、git log --oneline @{u}..HEAD を使用して、対象のコミットが共有済みかどうかを判断してください。アップストリームがない場合は、コミットが未共有だと決めつけず、リモート参照を確認してください。無関係なステージ済み変更を操作に含めないでください。

リソースの範囲と影響

Git 操作は、インデックス、ローカルコミット／参照、ワークツリー、場合によってはリモート参照を変更します。関連するプロジェクト設定のみを読み取ってください。認証情報の値をメッセージや報告に転記しないでください。認可と検証には ../_shared/core/execution-policy.md を適用してください。

参照資料

• コミット構文、種類、共同作成者ポリシー、ブランチ命名：コミット依頼では resources/conventional-commits.md
• 構成管理操作：ガバナンス／履歴／ワークツリーのタスクでは resources/cm-operations.md
• マージのリスクとロールバック：大規模なマージでは resources/merge-risk.md
• 所有権の詳細：CODEOWNERS に関する作業では resources/codeowners-playbook.md
• オンボーディングの指標：リポジトリのリスク評価では resources/onboarding-risk-signals.md
• リリースの可観測性：リリースマーカーとベースライン比較については ../oma-observability/SKILL.md §Integrations