菜单
Git 操作を行う際に常に遵守すべきブランチ運用・コミット・push のルール。GitHub Flow に従ったブランチモデル、ベースブランチの判定、コミット / push スキルへの委譲を徹底する。あらゆる git 操作（ブランチ作成、コミット、push、マージ、checkout 等）を行う前に参照する。 Use when this capability is needed.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/tomevault-io/skills-registry --skill git-workflow命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | git-workflow |
| description | Git 操作を行う際に常に遵守すべきブランチ運用・コミット・push のルール。GitHub Flow に従ったブランチモデル、ベースブランチの判定、コミット / push スキルへの委譲を徹底する。あらゆる git 操作（ブランチ作成、コミット、push、マージ、checkout 等）を行う前に参照する。 Use when this capability is needed. |
| metadata | {"author":"april418"} |
このスキルは Git 操作時に 常に意識すべき原則 をまとめたものである。 個別のワークフローではなく、git 関連の作業を行う際の行動規範として機能する。
git コマンドを実行する、または実行しようとするあらゆる場面で以下のルールを遵守すること。
扱ってよいブランチは以下のいずれかに限定される。
develop / master / mainfeature/<name> / hotfix/<name>それ以外の命名（fix/xxx, chore/xxx, topic/xxx 等）は使用しない。
ユーザーが明示的に別の命名を指示した場合のみ従う。
<name> 部分の命名規約feature/<name> / hotfix/<name> の <name> 部分は以下に従う。
- のみ。_ や空白、日本語は使わないkebab-case（user-authentication、payment-bug-fix 等）x, fix）も長すぎも避けるfeature/user-authentication、hotfix/payment-roundingfeature/work、feature/april418-1、hotfix/bug-<番号> を付けてよい（例: feature/login-form-321）<name> の決定主体デフォルト動作は以下の通り。推測のまま勝手に決めない。
<name> を AI が 1〜3 個提案 するAskUserQuestion で候補を提示し、ユーザーに選択 / 修正 / 自由入力させる提案できる材料がない場合（指示が極端に抽象的等）は、AskUserQuestion で「何の作業をするか」を先に確認する。
develop / master / main に直接コミット・push してはならない。
作業は必ず feature/* または hotfix/* ブランチ上で行う。
現在のブランチが統合ブランチのまま変更を加えようとしている場合、
コミット前に AskUserQuestion で新しい作業ブランチを切るか確認する。
新しい作業ブランチを切る手順は 3 ステップ で行う: (a) 選定 → (b) 取得・更新 → (c) 派生。 途中を省略しない。
git show-ref --verify --quiet refs/heads/develop が成功する、または
git ls-remote --exit-code --heads origin develop が成功する場合
→ develop から切るmaster または main を使用する
main と master の両方が存在する場合は main を優先AskUserQuestion で確認hotfix/* は必ず master / main から切る
develop があっても hotfix では develop を使わない判定は ローカルとリモートの両方 を確認する。 ローカルに develop がなくてもリモートに存在すればそれを優先する。
選定したベースは 派生直前にリモート最新へ追従させる。古い HEAD から切ると競合・rebase 苦労の原因になる。
# ローカルにベースが存在する場合: 一旦 checkout してから rebase pull
git switch <base>
git pull --rebase origin <base>
# ローカルにベースが存在しない（リモートのみ）場合: fetch して直接派生に使う
git fetch origin <base>
まず ルール 7 で AskUserQuestion を出し、3 択のいずれかをユーザーに選ばせる。
選択肢ごとに (b) → (c) の続きが分岐する:
「コミットしてから進める」を選んだ場合 → git-commit スキルで現ブランチにコミット後、通常ケースに復帰
「stash して進める」を選んだ場合:
git stash push -u
git switch <base>
git pull --rebase origin <base>
git switch -c <new-branch> # (c) 派生
git stash pop
この場合は (b) 取得・更新を 完遂 する。
「そのまま持ち込む」を選んだ場合:
git switch -c <new-branch> # 現在の作業ツリーごと新ブランチへ
この場合は (b) 取得・更新を意図的にスキップ する（pull を走らせると未コミット変更が衝突するため）。
ベースは古い HEAD のままになるが、未コミット変更の保護を優先する判断である。新ブランチ上で後ほど git rebase <base> で追従可能（ルール 8）。
AskUserQuestion で「ローカル HEAD のまま切るか中断するか」を確認する。
「ローカル HEAD のまま切る」を選んだ場合は (b) をスキップして (c) へ。
更新済みのベースから新ブランチを切る。
# ローカルにベースがある場合
git switch -c <new-branch> <base>
# リモートのみの場合（fetch 済みを利用）
git switch -c <new-branch> origin/<base>
git-commit スキルに委譲するgit 操作のうちコミット作成を行う場面では、自前で git commit を実行しない。
必ず git-commit スキルを呼び出す。
対象となる操作:
例外:
git commit --amend --no-edit（メッセージを変更しない単純な amend）git-push スキルに委譲するリモートへの push を行う場面では、自前で git push を実行しない。
必ず git-push スキルを呼び出す。
対象となる操作:
-u 付き）例外:
git-push スキル自身の内部処理以下の操作はすべて AskUserQuestion で事前承認を得る。自発的に実行しない。
git push --force / --force-with-leasegit reset --hardgit clean -fdgit branch -D（マージされていないブランチの削除）git rebase（特に push 済みブランチに対するもの）git checkout -- <file> / git restore <file>（未コミット変更の破棄）drop / clearmain / master への force push をユーザーが要求した場合はリスクを警告する。
ブランチ切り替え・pull・ベース更新の前には必ず作業ツリーの状態を確認する。
git status --short
未コミット変更がある状態でブランチ切り替えや pull を行おうとする場合、
AskUserQuestion で以下を選択させる:
git-commit スキル）git switch -c 等、安全な場合のみ）現在のブランチが統合ブランチ（develop / master / main）の場合:
「現在のブランチでコミットしてから進める」は ルール 2 違反になるため選択肢から除外 する。
残る 2 択（stash / そのまま持ち込む）を提示し、推奨は「そのまま持ち込む」（最短経路、未コミット変更の保護）。
現在のブランチが既に作業ブランチ（feature/* / hotfix/*）の場合:
3 択すべて提示可能。
git merge は使用禁止、rebase で統合するgit merge は使用しない。ブランチの統合は rebase で行う。
git pull は常に --rebase を付けるgit rebase <base> を使うgit merge を使ってよいのはユーザーが明示的に指示した場合のみ# pull 時は必ず --rebase
git pull --rebase origin <branch>
# ベースブランチへの追従
git rebase <base>
rebase 中にコンフリクトが発生した場合は、
AskUserQuestion でユーザーに状況を報告し指示を仰ぐ。
勝手に --abort / --skip しない。
このスキルの対象外の操作は、ユーザーから明示的に要求された場合のみ行う。
gh pr create 等）gh pr merge 等）ユーザーがマージを要求した場合は 必ず merge commit 形式 を使う。
gh pr merge <number> --merge
--squash / --rebase は使用しない。理由:
git log --first-parent で辿れるユーザーが明示的に --squash / --rebase を指示した場合のみ従う。
main / master への force push 同様、リスクを警告した上で実行する。
ルール 8（ローカルでの git merge 禁止）と矛盾しないこと:
git rebase（ルール 8）gh pr merge --merge（このルール）両者は対象が異なる。
git 操作を行う前に、以下を自問する:
feature/* / hotfix/*）か？git-commit スキルを呼ぶ段取りになっているか？git-push スキルを呼ぶ段取りになっているか？git merge ではなく rebase を使っているか？--merge（merge commit）を使っているか？git pull に --rebase を付けているか？Source: april418/dotfiles-v2 — distributed by TomeVault.