git-rebase

Git Rebase

両方の側が意図した動作と無関係な作業を保持しながら、要求されたリベースを実行します。リベースの依頼だけでは、コミットのスカッシュや削除、Git のグローバル設定の変更、書き換えたブランチの公開は許可されません。

1. ステータス、現在のブランチ、対象、および進行中のリベースを確認します。既知の対象と現在のフェッチ結果を再利用します。未コミットの作業を保持し、自動的な stash、reset、checkout、clean、無関係なパスのステージングは行いません。必要に応じて、分離したチェックアウトを使用します。
2. 新しいリベースを開始する前に HEAD を記録し、価値のある履歴を書き換える場合はバックアップ ref を保持します。bash <skill-dir>/scripts/pre-rebase-backup.sh は、追跡対象ファイルを変更せずに、クリーンなブランチのバックアップを作成します。既存のバックアップが検証済みであれば、重複して作成する必要はありません。
3. デフォルトでは、要求された対象に直接リベースします。ユーザーが履歴の変更を要求した場合に限り、インタラクティブ操作、スカッシュ、並べ替えを行います。コミット数はスカッシュの理由になりません。実際に方針の判断が必要な場合は、references/strategies.md を参照します。
4. コンフリクトが発生したら、リプレイ中のコミット、ベース、両方の側を調べます。リベース中の ours は対象とすでにリプレイされたコミット、theirs はリプレイ中のコミットです。変更された API を追跡し、どちらか一方を丸ごと採用するのではなく、意図されたセキュリティ、状態、互換性の契約を維持します。
5. 影響を受けたファイルを解決し、その差分を確認して、解決したパスのみをステージングしてから続行します。同じコンフリクトが繰り返される場合は、有効な確認結果を再利用します。本番コードにマージ履歴についてのコメントを追加したり、ファイルごとにフルスイートを実行したりしません。
6. リベースの完了後、できあがったパッチ系列と差分を確認し、影響を受ける動作のチェックと、プロジェクトで必須のリリースゲートを実行します。テストで回帰が判明した場合は、アサーションを弱めるのではなく、本番コードを修正します。
7. 公開がすでに許可されている場合に限り、公開します。リモートブランチを書き換えた場合は --force-with-lease を使用し、プロジェクトの最新の HEAD に関する CI ポリシーに従います。リースに失敗した場合は、新しいリモートコミットを確認します。無条件の強制プッシュに置き換えてはいけません。

意味上のコンフリクトには references/resolution-patterns.md を、原因が特定された運用上の失敗には references/troubleshooting.md を使用します。ヘルパーは、このスキルの実際の scripts/ パスにあります。analyze-conflicts.sh／validate-merge.sh は、リポジトリの前提条件を確認したうえで使用できる任意の補助ツールです。これらは、担当プロジェクトのテストやゲートの代わりにはなりません。作業を破棄する復旧には、リポジトリからの明示的な許可が必要です。バックアップ ref は証拠であり、reset の許可ではありません。