mcpField
U
update-from-upstream-main

update-from-upstream-main

github.com/remotion-dev開発68.6k458 回インストール今日更新
リポジトリ

update-from-upstream-main について

update-from-upstream-main は、ローカルの変更と公開済みブランチの履歴を保ちながら、正規の remotion-dev/remotion の main をマージするリポジトリスキルです。競合処理、検証、必要に応じたプッシュを扱います。

主な機能

  1. 01正規のリモートを特定
  2. 02ローカル変更を退避して復元
  3. 03リベースせずに main をマージ
  4. 04競合を慎重に解決
  5. 05変更を検証し必要に応じてプッシュ

活用シーン

  1. 01上流 main から機能ブランチを更新
  2. 02上流のマージ中にローカル編集を保持
  3. 03結果の報告前にマージ内容を検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/remotion-dev/remotion --skill update-from-upstream-main

インストール後、Claude Code で/update-from-upstream-mainを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

Upstream の Main から更新

ローカルの作業と公開済みブランチの履歴を保ちながら、正規の remotion-dev/remotion リポジトリから更新します。

ワークフロー

  1. 変更を加える前に、リポジトリを確認します。

    git status --short --branch
    git branch --show-current
    git remote -v
    

    マージやリベースなどの操作がすでに進行中の場合は、状態を報告して停止します。切り離されたチェックアウトもサポートされており、更新の妨げにはなりません。

    作業ツリーにステージ済み、未ステージ、または未追跡の変更がある場合は、自動的に stash して続行します。

    git stash push --include-untracked --message "update-from-upstream-main: preserve local changes"
    git rev-parse stash@{0}
    

    作成した stash のコミット ID を記録し、後で同じエントリーを復元できるようにします。未コミットの変更を停止する理由にしてはいけません。ユーザーから明示的に指示された場合を除き、無視対象のファイルは含めないでください。

  2. URL が remotion-dev/remotion を指す正規リモートを選択します。upstream が存在する場合は優先し、存在しない場合は origin を使用します。どちらのリモートも正規リポジトリを指していない場合は、リモートを追加または変更する前に停止して確認を求めます。

  3. 作業ツリーを変更せずに、最新の main ブランチをフェッチします。

    git fetch <canonical-remote> main
    
  4. チェックアウト中のブランチを更新します。

    • main の場合は、ファストフォワードを必須とします。

      git merge --ff-only <canonical-remote>/main
      
    • フィーチャーブランチまたは切り離されたチェックアウトの場合は、エディターを開かずに main をマージします。

      git merge --no-edit <canonical-remote>/main
      

    リベース、リセット、強制プッシュは行わないでください。マージにより公開済みブランチの履歴が保たれ、通常どおりプッシュできます。切り離されたチェックアウトの場合は、マージ後もコミットが切り離された状態であることを報告してください。

  5. マージで競合が発生した場合は、各ファイルを慎重に解決し、フィーチャーの意図と upstream の変更の両方を保ちます。マージ全体に対して ours または theirs を適用しないでください。ステージする前に、解決した各ファイルに競合マーカーが残っていないか確認します。

    rg -n '^(<{7}|={7}|>{7})' -- <resolved-files>
    

    一致した箇所を確認し、競合マーカーである箇所は削除します。その後、解決したファイルのみをステージし、次のコマンドでマージを完了します。

    git commit --no-edit
    
  6. 手順 1 で stash を作成した場合は、upstream の更新が完了した後に再適用します。

    git stash apply --index <recorded-stash-commit>
    

    成功を報告する前、またはフェッチやマージに失敗して停止する前に、Git 操作が進行中でないことを条件として stash を再適用してください。stash の適用で競合が発生した場合は、慎重に解決し、git stash apply を再実行しないでください。stash エントリーは復旧用のコピーとして残ります。未追跡ファイルとそのステージ状態を含む、stash された変更がすべて復元されたことを確認した後、git stash list --format='%gd %H' で記録したコミット ID に一致するエントリーを見つけ、そのエントリーのみを削除します。既存の stash を pop または削除してはいけません。

  7. 結果を検証します。必ず git diff --check と git diff --cached --check を実行してください。競合を解決した場合、または変更の組み合わせが動作に影響する可能性がある場合は、関連するパッケージのテストを実行してください。変更が広範囲に及ぶ場合は、次を実行します。

    bun run build
    bun run stylecheck
    
  8. 公開済みブランチまたはプルリクエストの更新をユーザーから指示された場合に限り、プッシュします。通常のプッシュを行い、拒否された場合は停止します。

    git push <canonical-remote> HEAD
    

    強制プッシュは絶対に行わないでください。

  9. 更新前後のコミット、チェックアウトが切り離されているかどうか、更新がファストフォワードかマージか、ローカルの変更を stash して正常に再適用したかどうか、解決した競合、実施した検証、ブランチをプッシュしたかどうかを報告します。

コメント