sync-upstream
上流のArduPilotリポジトリから最新のコミットを取得し、ローカルブランチをリベースすることで、ArduPilotのフォークを上流と同期します。
description の原文を見る
Sync an ArduPilot fork with the upstream ArduPilot repository by fetching upstream commits and rebasing the local branch.
SKILL.md 本文
/sync-upstream、ArduPilotフォークをアップストリームと同期
フォークされたArduPilotリポジトリを正規のアップストリームソースと同期しています。この操作はリベースによって履歴を書き換えます。各ステップを注意深く実行してください。各コマンドを実行する前に表示してください。
ステップ1:これがArduPilot関連のリポジトリであることを確認
以下の指標を確認してください:
- 現在のディレクトリパスに
arduino/upstreamまたはardupilotが含まれている - リポジトリのルートに
params/ディレクトリが存在する - リポジトリのルートに
Tools/またはArduCopter/ディレクトリが存在する - 既存のリモートURLが
ArduPilot/ardupilotを参照している
実行:
git remote -v
pwd
ls
これらの指標がない場合、ユーザーに問い合わせてください:「これはArduPilotリポジトリではないようです。ここでsync-upstreamを実行してもよろしいですか?(yes/no)」
- noの場合:停止します。
- yesの場合:注意深く続行してください。
ステップ2:コミットされていない変更を確認
実行:
git status --porcelain
コミットされていない変更がある場合、停止します:「コミットされていない変更があります。アップストリームと同期する前にコミットまたはstashしてください。」
以下を提案します:
git stash push -m "WIP before upstream sync"
その後、stash後に /sync-upstream を再度実行してください。
ステップ3:アップストリームリモートを確認または追加
実行:
git remote -v
upstream という名前のリモートを探します。
upstream が見つからない場合:
- ユーザーに問い合わせてください:「アップストリームリモートが見つかりません。アップストリームのURLは何ですか?」
- ArduPilot Copterの場合、以下を提案してください:
https://github.com/ArduPilot/ardupilot.git - ユーザーが確認するか、URLを提供するまで待ってください。
- リモートを追加してください:
git remote add upstream {upstream_url}
upstream が見つかる場合、ユーザーにそのURLを表示し、続行する前にそれが正しいことを確認するよう求めてください。
ステップ4:アップストリームをフェッチ
実行:
git fetch upstream
エラーを報告してください。フェッチが失敗した場合(例:ネットワークエラー)、停止してインターネット接続を確認し、もう一度試すようユーザーに依頼してください。
ステップ5:先行/遅行ステータスを報告
このブランチがupstream/masterより何コミット先行し、何コミット遅行しているかを判定します:
git rev-list --left-right --count upstream/master...HEAD
出力は {behind}\t{ahead} です。ユーザーに報告してください:
同期ステータス:
upstream/masterより遅行: {behind}コミット
upstream/masterより先行: {ahead}コミット(ローカル変更)
遅行カウントが0の場合、ユーザーに告げてください:「すでにアップストリームと同期しています。同期は不要です。」と停止してください。
ステップ6:リベース前に確認
これは大きな影響を与える操作です。リベースはコミット履歴を書き換えます。
ユーザーに問い合わせてください:
続行すると、{ahead}個のローカルコミットが{behind}個の新しいアップストリームコミットの上にリベースされます。
これはローカルのコミット履歴を書き換えます。
本当に続行してもよろしいですか?(yes/no)
- noの場合:停止してください。「同期をキャンセルしました。ブランチは変更されていません。」
- yesの場合:続行してください。
ステップ7:アップストリームマスターへリベース
実行:
git rebase upstream/master
リベースが成功した場合: ステップ8に進みます。
リベースがコンフリクトを検出した場合:
- 直ちに停止します。コンフリクトを自動解決しようとしないでください。
- 実行:
git diff --name-only --diff-filter=U - 競合する各ファイルを明確にリストアップしてください。
- ユーザーに指示してください:
- エディタで各競合ファイルを開いてください。
- コンフリクトマーカー(
<<<<<<<、=======、>>>>>>>)を解決してください。 - 各ファイルを解決した後:
git add {filename} - すべてのファイルが解決されたら:
git rebase --continue - 中止して前の状態に戻したい場合:
git rebase --abort
- 停止して待機します。さらなるコマンドは実行しないでください。
ステップ8:更新されたブランチをプッシュ
--force-with-lease を使用します(--force より安全で、他の人がその間にプッシュしていた場合は拒否されます):
git push --force-with-lease origin main
最後のフェッチ以降にリモートが変更されたためにプッシュが失敗した場合、エラーを報告して、ユーザーに進め方を問い合わせてください。
ステップ9:完了を報告
実行:
git log -1 --oneline
概要を表示します:
アップストリーム同期が完了しました。
新しいHEAD: {git log -1 --oneline出力}
適用されたコミット: {ahead}個のローカルコミットがリベースされました
アップストリームコミット: {behind}個の新しいコミットが統合されました
リモート: origin main が更新されました
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- iam6ft7in
- ライセンス
- MIT
- 最終更新
- 2026/5/11
Source: https://github.com/iam6ft7in/cfg_dev_environment / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。