mcpField
C
commit-hygiene

commit-hygiene

github.com/alinaqi開発711334 回インストール2 週間前に更新
リポジトリ

commit-hygiene について

commit-hygieneは、Gitの変更を目的別にまとめ、レビューしやすいPRを保つための開発者向けスキルです。変更量の基準、コミットのタイミング、大きな変更の分割方法を示します。

主な機能

  1. 01ファイル数と行数による変更規模の評価
  2. 02コミットに適したタイミングの提示
  3. 03大きな変更をアトミックなコミットに分割
  4. 04PRサイズとコミットメッセージの指針
  5. 05部分ステージングとコミット前確認の支援
  6. 06Claude向け定期コミット通知ルール

活用シーン

  1. 01開発中にチェックポイントコミットを判断
  2. 02複数レイヤーや機能の変更を分割
  3. 03PR作成前に変更規模を確認
  4. 04git add -pでコミット対象を選択

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alinaqi/maggy --skill commit-hygiene

インストール後、Claude Code で/commit-hygieneを入力して読み込まれたか確認します。

詳細

コミットの衛生管理スキル

目的: コミットをアトミックに保ち、PR をレビューしやすくし、git の履歴をきれいに保ちます。変更が大きくなりすぎる前に、コミットするタイミングを知らせます。


基本方針

┌─────────────────────────────────────────────────────────────────┐
│  ATOMIC COMMITS                                                  │
│  ─────────────────────────────────────────────────────────────  │
│  One logical change per commit.                                  │
│  Each commit should be self-contained and deployable.            │
│  If you need "and" to describe it, split it.                     │
├─────────────────────────────────────────────────────────────────┤
│  SMALL PRS WIN                                                   │
│  ─────────────────────────────────────────────────────────────  │
│  < 400 lines changed = reviewed in < 1 hour                      │
│  > 1000 lines = likely rubber-stamped or abandoned               │
│  Smaller PRs = faster reviews, fewer bugs, easier reverts        │
├─────────────────────────────────────────────────────────────────┤
│  COMMIT EARLY, COMMIT OFTEN                                      │
│  ─────────────────────────────────────────────────────────────  │
│  Working code? Commit it.                                        │
│  Test passing? Commit it.                                        │
│  Don't wait for "done" - commit at every stable point.           │
└─────────────────────────────────────────────────────────────────┘

コミットサイズのしきい値

警告のしきい値(コミットのタイミングです!)
指標イエローゾーンレッドゾーンアクション
変更したファイル数5~10 ファイル> 10 ファイル今すぐコミット
追加した行数150~300 行> 300 行今すぐコミット
削除した行数100~200 行> 200 行今すぐコミット
変更の合計250~400 行> 400 行今すぐコミット
前回のコミットからの経過時間30~60 分> 60 分コミットを検討
理想的なコミットサイズ
┌─────────────────────────────────────────────────────────────────┐
│  IDEAL COMMIT                                                    │
│  ─────────────────────────────────────────────────────────────  │
│  Files: 1-5                                                      │
│  Lines: 50-200 total changes                                     │
│  Scope: Single logical unit of work                              │
│  Message: Describes ONE thing                                    │
└─────────────────────────────────────────────────────────────────┘

現在の状態を確認する(頻繁に実行)

クイックステータス確認
# See what's changed (staged + unstaged)
git status --short

# Count files and lines changed
git diff --stat
git diff --cached --stat  # Staged only

# Get totals
git diff --shortstat
# Example output: 8 files changed, 245 insertions(+), 32 deletions(-)
詳細な変更分析
# Full diff summary with file names
git diff --stat HEAD

# Just the numbers
git diff --numstat HEAD | awk '{add+=$1; del+=$2} END {print "+"add" -"del" total:"add+del}'

# Files changed count
git status --porcelain | wc -l
コミット前チェック用スクリプト
#!/bin/bash
# scripts/check-commit-size.sh

# Thresholds
MAX_FILES=10
MAX_LINES=400
WARN_FILES=5
WARN_LINES=200

# Get stats
FILES=$(git status --porcelain | wc -l | tr -d ' ')
STATS=$(git diff --shortstat HEAD 2>/dev/null)
INSERTIONS=$(echo "$STATS" | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+' || echo 0)
DELETIONS=$(echo "$STATS" | grep -oE '[0-9]+ deletion' | grep -oE '[0-9]+' || echo 0)
TOTAL=$((INSERTIONS + DELETIONS))

echo "📊 Current changes: $FILES files, +$INSERTIONS -$DELETIONS ($TOTAL total lines)"

# Check thresholds
if [ "$FILES" -gt "$MAX_FILES" ] || [ "$TOTAL" -gt "$MAX_LINES" ]; then
    echo "🔴 RED ZONE: Commit immediately! Changes are too large."
    echo "   Consider splitting into multiple commits."
    exit 1
elif [ "$FILES" -gt "$WARN_FILES" ] || [ "$TOTAL" -gt "$WARN_LINES" ]; then
    echo "🟡 WARNING: Changes getting large. Commit soon."
    exit 0
else
    echo "🟢 OK: Changes are within healthy limits."
    exit 0
fi

コミットするタイミング

コミットのきっかけ(どれか 1 つでコミット)
きっかけ例
テストが成功テストが成功した → コミット
機能が完成関数の実装が完了した → コミット
リファクタリングが完了ファイル間で変数名を変更した → コミット
バグを修正問題を修正した → コミット
コンテキストを切り替える前別の作業に移るところ → コミット
コンパイルが成功コードのコンパイル/リントが問題なく完了した → コミット
しきい値に到達> 5 ファイルまたは > 200 行 → コミット
次の場合はすぐにコミット
  • ✅ テストが失敗から成功に変わった
  • ✅ 「大きな変更」を加えようとしている
  • ✅ 30 分以上コーディングしている
  • ✅ リスクの高いことを試そうとしている
  • ✅ 現在の状態が「動作している」
次の完了を待たない
  • ❌ 「完璧な」コード
  • ❌ すべての機能の完成
  • ❌ テストカバレッジの完全達成
  • ❌ 自分自身によるコードレビュー
  • ❌ ドキュメントの完成

アトミックコミットのパターン

良いアトミックコミット
✅ "Add email validation to signup form"
   - 3 files: validator.ts, signup.tsx, signup.test.ts
   - 120 lines changed
   - Single purpose: email validation

✅ "Fix null pointer in user lookup"
   - 2 files: userService.ts, userService.test.ts
   - 25 lines changed
   - Single purpose: fix one bug

✅ "Refactor: Extract PaymentProcessor class"
   - 4 files: payment.ts → paymentProcessor.ts + types
   - 180 lines changed
   - Single purpose: refactoring
悪いコミット(大きすぎるもの)
❌ "Add authentication, fix bugs, update styles"
   - 25 files changed
   - 800 lines changed
   - Multiple purposes mixed

❌ "WIP"
   - Unknown scope
   - No clear purpose
   - Hard to review/revert

❌ "Updates"
   - 15 files changed
   - Mix of features, fixes, refactors
   - Impossible to review properly

大きな変更を分割する

方法 1:レイヤーごと
Instead of one commit with:
  - API endpoint + database migration + frontend + tests

Split into:
  1. "Add users table migration"
  2. "Add User model and repository"
  3. "Add GET /users endpoint"
  4. "Add UserList component"
  5. "Add integration tests for user flow"
方法 2:機能の単位ごと
Instead of one commit with:
  - All CRUD operations for users

Split into:
  1. "Add create user functionality"
  2. "Add read user functionality"
  3. "Add update user functionality"
  4. "Add delete user functionality"
方法 3:先にリファクタリングする
Instead of:
  - Feature + refactoring mixed

Split into:
  1. "Refactor: Extract validation helpers" (no behavior change)
  2. "Add email validation using new helpers" (new feature)
方法 4:リスクレベルごと
Instead of:
  - Safe changes + risky changes together

Split into:
  1. "Update dependencies" (safe, isolated)
  2. "Migrate to new API version" (risky, separate)

PR サイズのガイドライン

最適な PR サイズ
指標最適許容範囲大きすぎる
ファイル数1~1010~20> 20
変更行数50~200200~400> 400
コミット数1~55~10> 10
レビュー時間< 30 分30~60 分> 60 分
PR サイズと不具合率
┌─────────────────────────────────────────────────────────────────┐
│  RESEARCH FINDINGS (Google, Microsoft studies)                  │
│  ─────────────────────────────────────────────────────────────  │
│  PRs < 200 lines: 15% defect rate                               │
│  PRs 200-400 lines: 23% defect rate                             │
│  PRs > 400 lines: 40%+ defect rate                              │
│                                                                 │
│  Review quality drops sharply after 200-400 lines.              │
│  Large PRs get "LGTM" rubber stamps, not real reviews.          │
└─────────────────────────────────────────────────────────────────┘
PR が大きすぎる場合
# Check PR size before creating
git diff main --stat
git diff main --shortstat

# If too large, consider:
# 1. Split into multiple PRs (stacked PRs)
# 2. Create feature flag and merge incrementally
# 3. Use draft PR for early feedback

コミットメッセージの形式

構成
<type>: <description> (50 chars max)

[optional body - wrap at 72 chars]

[optional footer]
タイプ
タイプ用途
feat新機能
fixバグ修正
refactor修正や追加を伴わないコード変更
testテストの追加/更新
docsドキュメントのみ
styleフォーマット変更、コード変更なし
choreビルド、設定、依存関係
例
feat: Add email validation to signup form

fix: Prevent null pointer in user lookup

refactor: Extract PaymentProcessor class

test: Add integration tests for checkout flow

chore: Update dependencies to latest versions

Git ワークフローとの統合

サイズ確認用のコミット前フック
#!/bin/bash
# .git/hooks/pre-commit

MAX_LINES=400
MAX_FILES=15

FILES=$(git diff --cached --name-only | wc -l | tr -d ' ')
STATS=$(git diff --cached --shortstat)
INSERTIONS=$(echo "$STATS" | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+' || echo 0)
DELETIONS=$(echo "$STATS" | grep -oE '[0-9]+ deletion' | grep -oE '[0-9]+' || echo 0)
TOTAL=$((INSERTIONS + DELETIONS))

if [ "$TOTAL" -gt "$MAX_LINES" ]; then
    echo "❌ Commit too large: $TOTAL lines (max: $MAX_LINES)"
    echo "   Consider splitting into smaller commits."
    echo "   Use 'git add -p' for partial staging."
    exit 1
fi

if [ "$FILES" -gt "$MAX_FILES" ]; then
    echo "❌ Too many files: $FILES (max: $MAX_FILES)"
    echo "   Consider splitting into smaller commits."
    exit 1
fi

echo "✅ Commit size OK: $FILES files, $TOTAL lines"
部分的なステージング(大きな変更を分割)
# Stage specific hunks interactively
git add -p

# Stage specific files
git add path/to/specific/file.ts

# Stage with preview
git add -N file.ts  # Intent to add
git diff            # See what would be added
git add file.ts     # Actually add
大きすぎる場合はステージングを解除
# Unstage everything
git reset HEAD

# Unstage specific files
git reset HEAD path/to/file.ts

# Stage just what you need for THIS commit
git add -p

Claude との連携

開発中の定期確認

Claude は重要な変更のたびに、この確認を実行してください:

# Quick status
git diff --shortstat HEAD

Claude がコミットを勧めるしきい値:

条件Claude のアクション
> 5 ファイルの変更提案:「現在の変更をコミットすることを検討してください」
> 200 行の変更提案:「変更が大きくなってきました。コミットをお勧めします」
> 10 ファイルまたは > 400 行警告:「⚠️ 変更を管理できなくなる前に、今すぐコミットしてください」
テストが成功したばかり提案:「良いチェックポイントです。この成功したテストをコミットしてください」
リファクタリングが完了提案:「リファクタリングが完了しました。機能を追加する前にコミットしてください」
Claude のコミットリマインダーメッセージ
📊 Status: 7 files changed, +180 -45 (225 total)
💡 Approaching commit threshold. Consider committing current work.

---

📊 Status: 12 files changed, +320 -80 (400 total)
⚠️ Changes are large! Commit now to keep PRs reviewable.
   Suggested commit: "feat: Add user authentication flow"

---

📊 Status: 3 files changed, +85 -10 (95 total)
✅ Tests passing. Good time to commit!
   Suggested commit: "fix: Validate email format on signup"

スタック PR(大規模な機能向け)

機能が本当に大規模な場合は、スタック PR を使用します:

┌─────────────────────────────────────────────────────────────────┐
│  STACKED PR PATTERN                                             │
│  ─────────────────────────────────────────────────────────────  │
│                                                                 │
│  main ─────────────────────────────────────────────────────────│
│    └── PR #1: Database schema (200 lines) ← Review first       │
│         └── PR #2: API endpoints (250 lines) ← Review second   │
│              └── PR #3: Frontend (300 lines) ← Review third    │
│                                                                 │
│  Each PR is reviewable independently.                           │
│  Merge in order: #1 → #2 → #3                                   │
└─────────────────────────────────────────────────────────────────┘
スタック PR の作成
# Create base branch
git checkout -b feature/auth-schema
# ... make changes ...
git commit -m "feat: Add users table schema"
git push -u origin feature/auth-schema
gh pr create --base main --title "feat: Add users table schema"

# Create next branch FROM the first
git checkout -b feature/auth-api
# ... make changes ...
git commit -m "feat: Add authentication API endpoints"
git push -u origin feature/auth-api
gh pr create --base feature/auth-schema --title "feat: Add auth API endpoints"

# And so on...

チェックリスト

すべてのコミットの前に
  • 変更内容は 1 つの論理的な目的に絞られている
  • テストに合格している(該当する場合)
  • リント/型チェックに合格している
  • 変更ファイル数が 10 未満
  • 合計変更行数が 400 未満
  • コミットメッセージが 1 つの内容を説明している
PR を作成する前に
  • 合計変更行数が 400 未満(理想は 200 未満)
  • すべてのコミットがアトミックである
  • 「WIP」や「fixup」のコミットがない
  • PR のタイトルが変更内容を説明している
  • 説明が変更内容だけでなく、変更理由も説明している
要注意の兆候(作業を止めて分割する)
  • ❌ コミットメッセージに「and」が必要
  • ❌ 1 つのコミットに 10 ファイルを超える変更がある
  • ❌ 1 つのコミットに 400 行を超える変更がある
  • ❌ 機能追加、修正、リファクタリングが混在している
  • ❌ 「あとで整理するつもり」

クイックリファレンス

しきい値
Files:  ≤ 5 = 🟢  |  6-10 = 🟡  |  > 10 = 🔴
Lines:  ≤ 200 = 🟢  |  201-400 = 🟡  |  > 400 = 🔴
Time:   ≤ 30min = 🟢  |  30-60min = 🟡  |  > 60min = 🔴
コマンド
# Quick status
git diff --shortstat HEAD

# Detailed file list
git diff --stat HEAD

# Partial staging
git add -p

# Check before PR
git diff main --shortstat
次の場合は今すぐコミットする
  • ✅ テストに合格したばかり
  • ✅ 変更行数が 200 を超えた
  • ✅ 変更ファイル数が 5 を超えた
  • ✅ これからタスクを切り替える
  • ✅ 現在の状態が「動作している」

コメント