// Use when the user asks for `gcm`, or whenever commit splitting and commit message generation are needed. Split commits by purpose first, not by file or Conventional Commit type. Prefer line-level grouping when practical, and follow the Japanese conventional-commit rules used by the user.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | commit-workflow |
| description | Use when the user asks for `gcm`, or whenever commit splitting and commit message generation are needed. Split commits by purpose first, not by file or Conventional Commit type. Prefer line-level grouping when practical, and follow the Japanese conventional-commit rules used by the user. |
gcm のためのコミット分割とコミットメッセージ作成手順。
コミットは「ファイル単位」でも「type 単位」でもなく、「変更目的単位」で分割する。
同じファイル内の変更でも、目的が異なる場合は別コミットに分ける。 別ファイルの変更でも、同じ目的を実現するために必要な変更であれば同じコミットにまとめてよい。
Conventional Commits の type はコミット分類のために使う。 分割の最優先基準にはしない。
迷った場合は、まず「この変更は同じ目的を達成するために必要か」で判断する。
以下は同じコミットにまとめてよい。
以下は別コミットに分ける。
コミットは小さく保つが、type の違いだけを理由に機械的に分割しない。
1コミットは、次の条件を満たすこと。
次のようなコミットは避ける。
同じファイル内に複数目的の変更が混在する場合は、可能な限り行単位または hunk 単位でステージングする。
行単位で安全に分けられない場合は、次のどちらかを選ぶ。
分割困難な場合でも、無関係な変更を安易に同一コミットへ含めない。
type は、そのコミットの主目的で決める。
同一目的のために複数種類の変更が含まれる場合でも、type は主目的に合わせる。
例:
featfixfeat または fixdocs または buildtype が複数候補になる場合でも、変更目的が1つなら無理に分割しない。 ただし、subject が複数目的になる場合は分割する。
<type>[(scope)][!]: <subject>と や および で並べる subject は避けるgit add と git commit のみとする。git reset git restore git checkout git stash git rebase git push git pull git merge 等、その他のgit操作は実行しない