Commit practices with Conventional Commits and atomic changes. Use when standardizing team history.
一貫したコミットメッセージ、原子的コミット、学習可能な履歴を作るための実践パターンです。
既定解釈として、ユーザーが単に「コミットして」と言った場合は、単発の git commit ではなく 原子的コミットを作る依頼 として扱います。
以下の状況で活用してください：
github-pr-workflow - PR作成とマージ運用github-issue-intake - Issue作成とトリアージgithub - 広い GitHub 入口から「コミットして」をこの skill に流すための補助入口コミット前に、必ず feature branch にいることを確認します。mainへの直接コミットは禁止です。
# 現在のブランチを確認
git branch --show-current
# main にいる場合は feature branch を作成
git switch -c feature/your-change
新しい作業を開始するとき、またはエージェントがコミットワークフローを始めるときに使います。
Values: 基礎と型 / 継続は力
type(scope): subject 形式に従い、人と自動化ツールの両方が解析できるメッセージを書きます。
git commit -m "feat(auth)!: OAuth2を導入
BREAKING CHANGE: /auth/login を /oauth/authorize に変更"
複数人で統一した形式が必要な場合や、CHANGELOGの自動生成をしたいときに使います。
変更意図に合ったtypeを選び、モジュール分割が明確なときはscopeを付けます。
| Type | 用途 | 例 |
|------|-----|----|
| feat | 新機能 | feat: 通知を追加 |
| fix | バグ修正 | fix: 文字化け修正 |
| docs | 文書更新 | docs: 手順追加 |
| test | テスト | test: E2E追加 |
| refactor | 内部整理 | refactor: 命名整理 |
# scope指定でドメインを明示
git commit -m "feat(api): 決済APIを追加"
モジュールやドメインが明確に分離されているリポジトリで使います。
git log で検索可能で自己説明的なメッセージにします。
# ✅ CORRECT - 具体的な対象と操作
git commit -m "feat: 注文履歴画面に検索フィルタを追加
Why: サポート対応で検索要求が多かったため"
# ❌ WRONG - 曖昧
git commit -m "fix: バグ修正"
日本語がチームの主要言語である場合や、履歴を監査で使うときに使います。
1つのコミットに1つの変更意図だけを含め、個別にレビュー・リバートできるようにします。このリポジトリでは、同じ session・同じ issue・同じ実装 wave で行った変更でも、意図が別ならコミットを分けます。
依頼が単に「コミットして」だけなら、この step を既定解釈にします。まず diff を見て関心事を分離し、1つの大きなコミットではなく最小の atomic commit 群に分けます。
# ❌ WRONG - 複数責務を同居
git commit -m "feat: 認証追加とUI改善とテスト追加"
# ✅ CORRECT - 変更意図ごとに分割
git commit -m "feat: 認証機能を追加"
git commit -m "refactor: UIレイアウトを改善"
git commit -m "test: 認証フローのテストを追加"
# ❌ WRONG - 「同じ作業波だったからまとめる」
- eval基盤追加
- skill本文修正
- docs更新
=> 1コミットにまとめる
# ✅ CORRECT - 変更意図単位で分ける
1. feat: prompt corpus 抽出スクリプトを追加
2. docs: 評価結果を追記
3. fix: atomic commit 判断基準を明文化
レビューで段階的に確認したい場合や、安全にリバートしたいときに使います。
コミット本文に「なぜ」を残し、将来の読者がdiffではなく判断理由を理解できるようにします。
git commit -m "fix: APIタイムアウトを10s→30sに変更
- 大量データ処理で10sでは不足していたため
- 監視で504エラーが増加していたため
Why: SLA達成率が低下していたため"
後から理由が問われそうな変更や、判断根拠を残したい場合に使います。
diffを確認し、テストを実行してからコミットし、履歴をクリーンに保ちます。
git diff
git status
npm test
git commit -m "feat: ..."
# .commitlintrc.yml
rules:
type-enum: [2, "always", ["feat","fix","docs","test","refactor","chore"]]
PRを開く前のプッシュ時や、新規メンバーのオンボーディングで使います。
履歴の書き換えは共有前のみ行います。push後は新しいコミットで対応します。
# push前: amendまたはinteractive rebase
git commit --amend -m "fix: 正しいメッセージ"
git rebase -i HEAD~3
# push後: 新コミットで修正
git commit -m "fix: 補足修正"
PR前に履歴を整理したい場合や、共有ブランチの安定を守りたいときに使います。
曖昧なメッセージ
Fix: 名詞と動詞で具体化する。
複数の変更を混在
Fix: session単位ではなく変更意図単位で原子的コミットに分割する。
文脈がない
Fix: Why行を追加する。
git diff を確認| 状況 | 対応 | 理由 | |------|------|------| | 30分以内 | そのままコミット | テンポ維持 | | 複数責務 | 変更意図単位で分割 | レビュー安全 | | 同じsessionだが複数意図 | それでも分割 | session境界はコミット境界ではない | | 「コミットして」と言われた | まず atomic split を検討 | 大きすぎる1コミットを避ける | | 共有ブランチ | rebase回避 | 履歴保護 |
Q: スコープは必須ですか？
A: モジュールが明確なら付けると便利です。
Q: WIPコミットは許容？
A: ローカルならOKですがPR前に整理します。
Q: 間違ったメッセージをpushしたら？
A: rebaseせず新しい修正コミットを追加します。
npx skills add RyoMurakami1983/git-commit-practices下载完整 Skill 目录，包含 SKILL.md 及所有相关文件
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer