High quality commit
Skill bg-szy/TOP-SKILLS/skills/marketplace/high-quality-commit
全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能，提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboard
npx -y skills add bg-szy/TOP-SKILLS --skill high-quality-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
コード変更を適切なgitコミット戦略でgit commitします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
SKILL.md
4.3 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
High Quality Commit
このスキルは、コード変更を高品質なgitコミットとして記録するための包括的なガイダンスを提供します。
Instructions
ステップ1: ブランチとgitコミット履歴の確認
以下のコマンドで現在の状態を確認：
git status
git log --oneline --graph origin/main..HEAD
確認事項：
- 現在のブランチ名
- mainブランチから何gitコミット進んでいるか
- 各gitコミットの内容と粒度
ステップ2: gitコミット戦略の判断
以下の基準でgitコミット戦略を選択：
戦略A: Squash（基本戦略）
以下の条件を満たす場合、既存のgitコミットにsquashします：
- ブランチに既にgitコミットが存在する
- 変更内容が既存のgitコミットと同じテーマ・機能に関連している
- gitコミットを分ける合理的な理由がない
実行方法：
git add -A
git commit --amend
gitコミットメッセージを適切に更新してください。
戦略B: 新規gitコミット
以下の場合は新規gitコミットを作成：
- ブランチに初めてのgitコミット
- 既存のgitコミットとは異なる独立した変更
- gitコミットを分けることで履歴がより理解しやすくなる
実行方法：
git add -A
git commit
戦略C: Interactive Rebase（gitコミット再構成）
以下の場合はブランチ全体のgitコミットを再構成：
- 複数の小さなgitコミットを論理的なまとまりに整理したい
- gitコミットの順序を変更したい
- 不要なgitコミットを削除したい
- gitコミット履歴を意味のある単位に再編成したい
実行方法：
git rebase -i origin/main
エディタで以下の操作を実行：
pick: gitコミットをそのまま維持squashまたはs: 前のgitコミットと統合rewordまたはr: gitコミットメッセージを変更- 行の順序を変更してgitコミット順を変更
ステップ3: gitコミットメッセージのガイドライン
gitコミットメッセージは以下の形式で記述：
<type>: <subject>
<body>
<footer>
Type:
feat: 新機能fix: バグ修正refactor: リファクタリングtest: テスト追加・修正docs: ドキュメント変更chore: ビルドプロセスやツールの変更
Subject:
- 50文字以内
- 命令形で記述（例: "add"ではなく"Add"）
- 末尾にピリオドを付けない
Body（オプション）:
- 変更の理由と背景を説明
- 何を変更したかではなく、なぜ変更したかを記述
- 72文字で折り返す
Footer（オプション）:
- Issue番号への参照（例:
Closes #123） - Breaking changesの記述
ステップ4: git commit後の確認
git commit後、以下を確認：
git log -1 --stat
git status
- gitコミットが正しく作成されたか
- 意図したファイルがすべて含まれているか
- gitコミットメッセージが適切か
重要な注意事項
- mainブランチでは実行しない: mainブランチで直接git commitしないでください
- コメントは残さない: コード内の説明コメントは削除してください
- 原子的なgitコミット: 各gitコミットは独立して意味を持つようにしてください
- 一貫性: プロジェクトの既存のgitコミットスタイルに従ってください
戦略選択のフローチャート
ブランチにgitコミットがある？
├─ No → 新規gitコミット作成
└─ Yes → 変更は既存のgitコミットと同じテーマ？
├─ Yes → Squash（git commit --amend）
└─ No → gitコミットを分ける合理性がある？
├─ Yes → 新規gitコミット作成
└─ 履歴を整理したい → Interactive Rebase