Back to Details

committer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Committer

Committer

変更ファイルを分析して関連する変更をグループ化し、適切な粒度でコミットを作成する。
Analyzes modified files, groups related changes, and creates commits with appropriate granularity.

ワークフロー

Workflow

Step 1: 現在の状態を把握する

Step 1: Understand the current status

変更内容とプロジェクトのコミットスタイルを確認する：
bash
git branch --show-current
git config --get commit.gpgsign
git status
git diff --stat HEAD
git log --oneline -10
GPG 署名が有効な場合（
commit.gpgsign=true
）はフラグを立てておく。 この時点ではユーザーへの確認は行わない。Step 4 の承認後、Step 5 の実行前に確認する。
main / master ブランチの場合は必ずユーザーに確認する。 現在のブランチが 
main
または 
master
であれば、コミットの前に AskUserQuestion で確認する：
javascript
AskUserQuestion({
  questions: [{
    question: "現在 main ブランチにいます。このままコミットしますか？",
    header: "ブランチ確認",
    options: [
      { label: "main のままコミット",   description: "現在のブランチに直接コミットする" },
      { label: "作業ブランチを作成",     description: "新しいブランチを作成してからコミットする" }
    ],
    multiSelect: false
  }]
})
「作業ブランチを作成」を選んだ場合は、続けてブランチ名をテキストで質問し、指定された名前で 
git checkout -b <branch>
を実行してから処理を続ける。
既にステージ済みのファイルがある場合は、ユーザーに意図を確認してから進む：
  • そのままコミットする（Step 4 へ）
  • 未ステージ分も含めて分析する（Step 2 へ）
Check the changes and the project's commit style:
bash
git branch --show-current
git config --get commit.gpgsign
git status
git diff --stat HEAD
git log --oneline -10
If GPG signing is enabled (
commit.gpgsign=true
), set a flag for it. Do not confirm with the user at this point. Confirm after Step 4 approval and before Step 5 execution.
Always confirm with the user if on main / master branch. If the current branch is 
main
or 
master
, confirm with AskUserQuestion before committing:
javascript
AskUserQuestion({
  questions: [{
    question: "You are currently on the main branch. Do you want to commit directly here?",
    header: "Branch Confirmation",
    options: [
      { label: "Commit on main",   description: "Commit directly to the current branch" },
      { label: "Create a working branch",     description: "Create a new branch before committing" }
    ],
    multiSelect: false
  }]
})
If "Create a working branch" is selected, ask the user for a branch name via text input, execute 
git checkout -b <branch>
with the specified name, then continue processing.
If there are already staged files, confirm the user's intent before proceeding:
  • Commit as-is (proceed to Step 4)
  • Analyze including unstaged changes (proceed to Step 2)

Step 2: 変更内容を読んで意図を把握する

Step 2: Read changes to understand intent

Step 1 の stat で把握したファイルごとに差分を読んで変更意図を理解する。以下の観点で分析する：
  • 変更の種類: 機能追加 / バグ修正 / リファクタリング / テスト追加 / 設定変更 / ドキュメント更新
  • 変更の目的: なぜ変更したか（同じ目的に属するかどうかの判断軸）
  • ファイル間の関連性: 一緒に変えると意味をなす組み合わせを探す
bash
git diff HEAD -- <file>
未追跡の新規ファイルは 
git diff HEAD
に含まれないため、Read で内容を確認する。
Read the diff for each file identified in Step 1's stat to understand the intent of changes. Analyze from the following perspectives:
  • Change type: Feature addition / Bug fix / Refactoring / Test addition / Configuration change / Documentation update
  • Change purpose: Why the change was made (used to judge if changes belong to the same purpose)
  • File relevance: Look for combinations that make sense to change together
bash
git diff HEAD -- <file>
Untracked new files are not included in 
git diff HEAD
, so check their content using Read.

Step 3: 変更をグループ化してコミット計画を立てる

Step 3: Group changes and create a commit plan

以下の原則でグループ化する：
まとめてよい変更
  • 同じ機能・目的に属するソースファイルとテスト
  • 同じバグ修正の一連のファイル
  • 同じリファクタリング対象
別コミットにすべき変更
  • 目的が異なる（機能追加 vs バグ修正 vs リファクタリングなど）
  • 独立している（一方が他方に依存しない）
  • 影響範囲が違う（アプリコード / 設定 / ドキュメント / CI など）
1つの変更ファイルに複数の意図が混在する場合は、
git add -p
で部分ステージを検討する。
Group changes according to the following principles:
Changes that can be grouped together
  • Source files and tests belonging to the same feature/purpose
  • A series of files for the same bug fix
  • Same refactoring target
Changes that should be in separate commits
  • Different purposes (feature addition vs bug fix vs refactoring, etc.)
  • Independent changes (one does not depend on the other)
  • Different impact scopes (application code / configuration / documentation / CI, etc.)
If a single modified file contains multiple intents, consider partial staging with 
git add -p
.

Step 4: 計画をユーザーに提示して確認を取る

Step 4: Present the plan to the user for confirmation

実行前に必ず確認する。以下の形式で提案する：
提案するコミット（N件）：

コミット 1: feat(auth): JWTトークンによる認証を実装
  対象ファイル:
    - src/auth/jwt.ts（新規）
    - src/auth/middleware.ts（変更）
    - tests/auth/jwt.test.ts（新規）

コミット 2: chore: ESLint設定を更新
  対象ファイル:
    - .eslintrc.json（変更）

この内容で進めますか？
修正を求められたらグループ分けを調整して再提案する。
Always confirm before execution. Propose in the following format:
Proposed commits (N items):

Commit 1: feat(auth): Implement authentication with JWT tokens
  Target files:
    - src/auth/jwt.ts (new)
    - src/auth/middleware.ts (modified)
    - tests/auth/jwt.test.ts (new)

Commit 2: chore: Update ESLint configuration
  Target files:
    - .eslintrc.json (modified)

Do you want to proceed with this content?
If revisions are requested, adjust the grouping and re-propose.

Step 5: グループごとにコミットを実行する

Step 5: Execute commits for each group

承認を得たら、コミット実行前に GPG フラグが立っている場合は AskUserQuestion で確認する：
javascript
AskUserQuestion({
  questions: [{
    question: "GPG 署名が有効になっています。Claude Code はパスフレーズを入力できないため、このセッションでは --no-gpg-sign でコミットします。よいですか？",
    header: "GPG 署名",
    options: [
      { label: "--no-gpg-sign でコミット", description: "このセッションのみ GPG 署名をスキップする" },
      { label: "キャンセル",              description: "処理を中断する（ターミナルから手動でコミットしてください）" }
    ],
    multiSelect: false
  }]
})
「キャンセル」を選んだ場合、Step 4 で確認済みのコミット計画をコマンド形式で出力して処理を終了する：
GPG 署名が必要なため処理を中断しました。
ターミナルから以下のコマンドを実行してください：
Once approved, if the GPG flag is set, confirm with AskUserQuestion before executing commits:
javascript
AskUserQuestion({
  questions: [{
    question: "GPG signing is enabled. Since Claude Code cannot enter passphrases, commits will be made with --no-gpg-sign in this session. Is this okay?",
    header: "GPG Signing",
    options: [
      { label: "Commit with --no-gpg-sign", description: "Skip GPG signing only for this session" },
      { label: "Cancel",              description: "Abort processing (please commit manually from the terminal)" }
    ],
    multiSelect: false
  }]
})
If "Cancel" is selected, output the commit plan confirmed in Step 4 in command format and terminate processing:
Processing aborted because GPG signing is required.
Please execute the following commands from the terminal:

コミット 1

Commit 1

git add src/auth/jwt.ts src/auth/middleware.ts tests/auth/jwt.test.ts git commit -m "feat(auth): JWTトークンによる認証を実装
既存のセッション認証を置き換える形で JWT を導入した。"
git add src/auth/jwt.ts src/auth/middleware.ts tests/auth/jwt.test.ts git commit -m "feat(auth): Implement authentication with JWT tokens
Replaced existing session authentication with JWT implementation."

コミット 2

Commit 2

git add .eslintrc.json git commit -m "chore: ESLint設定を更新"

「--no-gpg-sign でコミット」を選んだ場合、グループ順にコミットを作成する。

**body が必要な場合**（変更の背景・理由・詳細を補足したいとき）：

```bash
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<変更の背景・理由・詳細>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
EOF
)"
body が不要な場合（subject だけで意図が伝わるとき）：
bash
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
EOF
)"
[--no-gpg-sign]
は GPG フラグが立っておりユーザーが承認した場合のみ付与する。
全グループ完了後、
git log --oneline -N
（N はコミット数）で作成を確認してから一覧を報告する：
bash
git log --oneline -3
✓ 2件のコミットを作成しました

  abc1234 feat(auth): JWTトークンによる認証を実装
  def5678 chore: ESLint設定を更新
git add .eslintrc.json git commit -m "chore: Update ESLint configuration"

If "Commit with --no-gpg-sign" is selected, create commits in group order.

**When a body is needed** (when you want to supplement the background, reason, or details of the change):

```bash
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<Background, reason, and details of the change>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
EOF
)"
When a body is not needed (when intent is clear with just the subject):
bash
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
EOF
)"
[--no-gpg-sign]
is only added if the GPG flag is set and the user has approved it.
After completing all groups, verify creation with 
git log --oneline -N
(N is the number of commits) and report the list:
bash
git log --oneline -3
✓ Created 2 commits

  abc1234 feat(auth): Implement authentication with JWT tokens
  def5678 chore: Update ESLint configuration

コミットメッセージの書き方

How to write commit messages

以下の形式を使う：
<type>(<scope>): <subject>

<body>
  • subject: コミットの概要を1行で簡潔に記述する
  • body: 変更の背景・理由・詳細が必要な場合のみ記載する。不要なら省略してよい
type用途
feat新機能
fixバグ修正
refactorリファクタリング（動作変更なし）
testテストの追加・修正
docsドキュメント変更
choreビルド・CI・設定などの雑務
styleフォーマット変更（動作変更なし）
日本語プロジェクトでは日本語メッセージも適切。
Use the following format:
<type>(<scope>): <subject>

<body>
  • subject: Briefly describe the commit in one line
  • body: Only include if background, reason, or details of the change are needed. Can be omitted if unnecessary
typeUsage
featNew feature
fixBug fix
refactorRefactoring (no functional changes)
testTest addition/modification
docsDocumentation changes
choreMiscellaneous tasks like build, CI, configuration
styleFormatting changes (no functional changes)
Japanese messages are also appropriate for Japanese-language projects.

注意事項

Notes

  • push はしない: コミット作成のみ行う。push はユーザーが判断する
  • バイナリファイル: 差分が読めないため、ファイル名と用途から意図を推測してユーザーに確認する
  • 大量変更（50ファイル以上）: まず変更の全体像を説明してからグループ化の方針を相談する
  • 機密ファイル: 
    .env
    や認証情報を含むファイルはコミットに含める前に警告する
  • pre-commit hook が失敗した場合: hook のエラー内容を確認して修正し、再度コミットを試みる。
    --no-verify
    はユーザーが明示的に要求した場合のみ提案する
  • コミット対象がない場合: ステージ対象ファイルがない旨をユーザーに伝え、
    git status
    の結果を示す
  • Do not push: Only create commits. The user decides when to push
  • Binary files: Since diffs cannot be read, infer intent from filename and purpose and confirm with the user
  • Large number of changes (50+ files): First explain the overall picture of changes, then discuss grouping strategy with the user
  • Confidential files: Warn the user before including files like 
    .env
    or authentication information in commits
  • If pre-commit hook fails: Check the hook error details, fix them, and retry the commit. Only propose 
    --no-verify
    if explicitly requested by the user
  • No commit targets: Inform the user that there are no files to stage and show the result of 
    git status
    ",