このレッスンで学ぶこと
- コミットメッセージの品質を上げるプロンプトの書き方
- 複数の変更を意味のある単位でコミット分割する方法
ghCLI連携によるPR作成ワークフロー- ブランチ整理・コンフリクト解消をClaude Codeに手伝わせる方法
- rebase・cherry-pickなど高度なGit操作を安全に実行するコツ
前提条件
- Gitの基本操作（add、commit、push、branch）を理解していること
ghCLI（GitHub CLI）がインストール・認証済みであること（PR作成の節で使用します）
コミットメッセージ生成の品質を上げる
Claude Codeは git diff の内容からコミットメッセージを生成できますが、何も指示しないと「Update files」のような中身のないメッセージになりがちです。良いコミットメッセージを得るには、コミット規約を事前に伝えておくことが近道です。
CLAUDE.mdに以下のようなルールを書いておくと、毎回説明する手間がなくなります。
# コミットメッセージ規約
- 日本語で記述する
- 1行目: 変更内容の要約（50文字以内、体言止めではなく動詞で終える）
- 2行目: 空行
- 3行目以降: 変更理由・背景（「何を」ではなく「なぜ」を書く）
- 関連するIssue番号があれば末尾に `refs #123` の形式で記載するこのルールがある状態で「コミットして」と頼むと、Claudeは差分の内容だけでなく「なぜその変更が必要だったか」をコミットメッセージに含めようとします。差分から意図が読み取れない場合は、会話の文脈（直前にどんな指示をしたか）から理由を補完してくれます。
「パフォーマンス改善のため」「レビュー指摘の対応」のように、差分だけでは読み取れない背景がある場合は、コミットを依頼するプロンプトに一言添えましょう。Claudeはそれをコミットメッセージの本文に反映してくれます。
今回の変更は「キャッシュのTTLが短すぎてDB負荷が高い」という
パフォーマンス課題への対応です。この背景を踏まえてコミットして複数の変更を意味のある単位でコミット分割する
作業を進めていると、1つのセッションで複数の関心事にまたがる変更が積み上がることがあります。これを1つの巨大なコミットにまとめてしまうと、後からの追跡や git revert が困難になります。Claude Codeに「論理的な単位への分割」を依頼すると、git diff を解析して提案してくれます。
現状の変更を俯瞰させる
git status と git diff を確認して、現在の変更内容を
意味のあるまとまりに分類してClaudeは「バリデーション関数の追加」「既存テストの修正」「タイポ修正」のように、変更を関心事ごとにグルーピングして提示します。
分割方針を確認する
提示された分類が妥当か確認します。意図と違う分類になっていたら、ここで修正を指示します。
タイポ修正は独立したコミットにせず、関連する機能修正に含めてください段階的にステージング・コミットさせる
その分割案に従って、git add -p や個別ファイル指定でステージングしながら
3つのコミットに分けてください。各コミットメッセージも提案してgit add -p（パッチ単位でのステージング）が必要な場面では、Claudeが対話的に該当ハンクを選びながらコミットを作成します。
コミットログを確認する
git log --oneline -5 で結果を確認して分割後のログを見て、各コミットが単体でも意味が通る内容になっているか最終確認します。
同じファイルの中に複数の関心事の変更が混在している場合、git add -p でのハンク分割が必要になります。Claudeに任せる場合も、分割後に git diff --staged で意図通りの内容がステージングされているか必ず確認しましょう。
PR作成のワークフロー
Claude Codeは gh CLIと連携してPRを直接作成できます。CLAUDE.mdにあるPRテンプレート規約を読み込ませておけば、テンプレートに沿ったPR説明文を自動生成してくれます。
このブランチの変更でPRを作成してください。
ベースブランチはdevelopです。この一言だけでも、Claudeは以下を自動的に行います。
git logでベースブランチとの差分コミットを確認git diffで変更内容全体を把握- CLAUDE.mdに定義されたPRテンプレートに沿って概要・変更内容・テスト計画を記述
gh pr createでPRを作成
プロジェクトに .github/PULL_REQUEST_TEMPLATE.md がある場合、gh pr create はそれを自動的に使用します。CLAUDE.mdとテンプレートファイルで内容が重複しないよう、どちらか一方に統一しておくのがおすすめです。
PRを作成した後も、Claude Codeとの連携は続きます。
作成したPRに、レビュアーが見落としそうなリスクや
考慮事項があれば追記してくださいレビューコメントが届いた後も、PRに対する指摘事項を貼り付けて修正を依頼できます。
このPRに以下のレビューコメントが付きました。対応してください。
> エラーハンドリングが追加されていますが、リトライ回数が
> ハードコードされています。設定可能にしてください。Claudeが生成したPR説明文は出発点として優秀ですが、そのままマージ依頼に使う前に、変更内容と説明文が一致しているか、機密情報が含まれていないかを必ず人間が確認しましょう。
ブランチ整理・コンフリクト解消のサポート
開発が長期化すると、不要になったローカルブランチが溜まったり、developの更新によってコンフリクトが発生したりします。これらもClaude Codeに状況整理を任せると効率的です。
git branch -a でローカルブランチ一覧を確認して、
マージ済みで削除してよさそうなブランチを教えてコンフリクトが発生した場合は、Claudeに両方の変更意図を説明させてから解消を依頼すると安全です。
develop ブランチをマージしたところ src/api/user.ts でコンフリクトが
発生しました。両方の変更内容を確認して、どちらの意図を優先すべきか
説明してください。まだ自動解消はしないでください。コンフリクト解消は意図の競合を含むため、Claudeに「両方の変更内容の説明」までさせてから、人間が解消方針を決めるステップを必ず挟みましょう。いきなり「コンフリクトを解消して」と頼むと、片方の変更が意図せず失われるリスクがあります。
rebase・cherry-pick等、高度なGit操作の安全な実行
rebaseやcherry-pickは強力な反面、操作を誤ると履歴を壊しかねません。Claude Codeに依頼する際は、必ず「何をしようとしているか」を事前に説明させ、実行前に確認するフローを徹底しましょう。
feature/payment ブランチを最新のmainの上にrebaseしたいです。
実行前に、どのコミットがどう移動するか説明してください。
まだ実行はしないでください。説明を確認し、問題なければ実行を指示します。
説明内容で問題ありません。rebaseを実行してください。
コンフリクトが発生したら、各コミットごとに止まって確認を求めてください。cherry-pickで特定のコミットだけを別ブランチに移したい場合も、同様に対象コミットを事前に確認させます。
git log --oneline でmainにある直近10件のコミットを表示して、
「ログ出力の改善」に関連するコミットだけを hotfix/logging に
cherry-pickしたいです。対象コミットのハッシュを教えてください。git push --force、git reset --hard、git branch -D などの破壊的コマンドは、実行前に必ず「何が失われる可能性があるか」をClaudeに説明させましょう。CLAUDE.mdに「破壊的コマンドの実行前には必ず確認を取る」と明記しておくと、Claudeが自発的に確認を挟むようになります。
# Git運用ルール（CLAUDE.md抜粋）
- rebase、force push、reset --hard等の破壊的操作は、実行前に必ず影響範囲を説明し、確認を取ってから実行する
- mainブランチへの直接コミット・force pushは行わない
- コンフリクト解消時は、両方の変更意図を説明してから解消方針を確認するまとめ
このレッスンでは、Git操作をClaude Codeで効率化する方法を学びました。
- コミットメッセージ: CLAUDE.mdに規約を書き、背景情報を添えることで質が上がる
- コミット分割: 差分を意味のある単位にグルーピングさせ、段階的にステージング・コミットする
- PR作成:
ghCLI連携でテンプレートに沿ったPRを自動生成し、レビュー対応も継続できる - ブランチ整理・コンフリクト解消: 自動解消の前に、両方の変更意図を説明させるステップを挟む
- 高度なGit操作: rebase・cherry-pick・破壊的コマンドは、実行前の説明と確認を徹底する
次のステップ
次のレッスンでは、個人のグローバルCLAUDE.mdやチーム共有テンプレート、モノレポでの階層的な設定運用など、複数プロジェクトを横断してClaude Codeを活用する方法を学びます。
Lesson 7: 複数プロジェクトで横断的に活用する に進みましょう。