#claude-code-git

置換を1回で全部終わらせようとして、あとで何が起きたか分からなくなる。これ、かなりありがちな失敗だ。Claude Code に大量の修正を投げると、ファイルのあちこちを同時に触れて、差分がでかくなり、どこで壊れたのか追いにくくなる。巻き戻したいのに、戻す単位すら見えない。そこで効くのが段階コミットだ。小さく直して、小さく確かめて、小さくコミットする。これだけで手戻りの痛さがかなり減る。 たとえば、プロジェクト内の文言を「旧サービス名」から「新サービス名」に置き換える、フォルダ名を整理する、説明文の表記ゆれを直す、不要ファイルをまとめて消す。こういう作業を Claude Code に任せるとき、いきなり「全部やって」で済ませると危ない。実際、筆者は過去に、似た名前のファイルをまとめてリネームさせたあとで、関連参照の修正まで一気に走らせてしまい、どの変更がどの影響を生んだのか見えなくなったことがある。diff が肥大化して、結局、途中まで戻してやり直しだ。あれはだるい。 やり方は単純だ。ひとつの巨大タスクを、意味のある小片に分ける。Claude Code には、その都度「この範囲だけ」「こ

そのコード、ただ動くだけで満足していないか。いちばん厄介なのは「何のために残っているか誰も覚えていない行」だ。消すと壊れそうで怖い、残すと読みづらい。こういうときに Claude Code に git 履歴を当たらせると、ただの謎コードが「いつ、誰が、どの意図で入れたか」に変わる。意味が見えるだけで、保守のストレスはかなり減る。 この手の調査でやることは単純だ。コード片を見せて、「このコードが入った経緯と目的を、git 履歴から説明して」と頼む。うまくやれば、変更を入れたコミット、関連しそうな差分、前後の文脈をたどって、なぜそこにその実装があるのかを整理してくれる。非エンジニアなら、たとえばファイル整理ツールの不思議な判定条件や、ドキュメント生成用のスクリプトがなぜその保存先を使うのかを理解するのに使える。弁護士や事務職でも、案件フォルダの命名ルールや不要ファイル削除の条件を追うときに役立つ。 やり方は、まず対象を小さく切るのがコツだ。巨大なファイル丸ごとを投げると、履歴の説明より表面の要約に逃げやすい。むしろ「この関数」「この定数」「この if ブロック」のように、意味を知りたい単位

コンフリクトを見つけた瞬間に、雑に「直しといて」と投げるとだいたい余計にこじれる。Claude Code もそこは人間と同じで、何を残すべきか、どこまで触っていいかが曖昧だと、無難そうな修正を広げてしまう。結果、差分が太る。あとで自分が読むと、何を直したのか分からない。これが一番だるい。 この手の場面で大事なのは、解決作業そのものより、渡し方だ。コンフリクトの前後関係、残したい意図、触ってよい範囲を小さくまとめて渡すだけで、手戻りがかなり減る。開発でも文書整理でも同じで、片方だけ見せて丸投げするのが一番危ない。 まず押さえるべきなのは、Claude Code に見せる情報を「衝突したファイルそのもの」だけに絞らないことだ。コンフリクトは、たいてい前後の変更履歴や目的が分からないと解けない。たとえば設定ファイルなら、「新しい値にしたい」のか「既存の値を残したい」のかで答えが変わる。文書なら、片方の修正が表現の整理で、もう片方が事実の追加かもしれない。そこを切り分けずに渡すと、見た目は直っても意図が死ぬ。 実際の渡し方は、こういう形が使いやすい。 ```text このコンフリクトを解消して

プルリクの説明文を、毎回ゼロからひねり出しているなら、その時間はかなりもったいない。差分は読めるのに、説明だけが薄っぺらい。あれはだいたい、頭の中にある変更点をそのまま文章化していないのが原因だ。 Claude Code はここでかなり使える。コードの差分、変更したファイル、作業メモを拾わせて、PR のたたき台を一気に作らせればいい。自分で書くのは最後の調整だけになる。説明文の骨組みが先に出るので、抜け漏れも減る。 ただし、雑に「PR説明文を作って」で投げると、ふわっとした要約が返ってきて終わる。これがいちばんつまらない。人間が欲しいのは、読む相手がそのまま判断に使える文章だ。なので、最初から「何を見て、どの形式で、何を入れて、何を省くか」まで指定する。 まずは、作業中の変更があるリポジトリを開いた状態で、Claude Code にこう頼めばいい。 ```text 変更内容をもとに、プルリクエストの説明文を日本語で下書きしてください。 次の構成で出してください。 変更の要約 背景と目的 主な変更点 動作確認 レビュー時に見てほしい点 補足 重要: 変更差分を読んだうえで書くこと 推測で

テストもないのに手を入れて、あとで「何が壊れたか分からない」と泣く。これ、かなりありがちな事故だ。Claude Code を使うときも同じで、いきなり大工事を頼むより、先に“壊してはいけない形”をテストで囲ってから直したほうが圧倒的に安全になる。 ここで言うのは、大規模な自動テスト体制の話ではない。まずは、今ある挙動を固定するための最小限のテストを足す。それからリファクタする。Claude Code は差分を追いながら作業できるので、この段取りと相性がいい。指示の出し方さえ間違えなければ、雑に直して戻し作業を増やすより、ずっとましだ。 筆者も最初は「どうせ小さい変更だし」と思って直し始めて、関連ファイルまで連鎖的に触ってしまい、どこで壊したか探す羽目になった。特に Claude Code に曖昧な依頼をすると、要点を広く拾おうとして diff が膨らむ。だから順番が大事だ。先にテスト、次に修正。これで迷子になりにくい。 まず押さえるべきなのは、リファクタの前に「守るべき振る舞い」を1つでもいいから言葉にすることだ。関数の入力と出力、ファイルの生成結果、表示文言、削除してよい条件。何を固

差分をそのまま見せて「レビューして」と投げるだけでは甘い。だいたい見落とされる。Claude Code にやらせたいのは、単なる読み上げではなく、変更の穴を突かせることだ。 この使い方が効くのは、コード修正だけではない。設定ファイルの整理、文章の推敲、不要ファイル削除の前後確認、README の手直しみたいな作業でも同じだ。自分では「まあこんなもんか」で流しがちな差分に、第三者の目を入れる。しかも人間に頼む前に、まず機械に荒く突っ込ませる。これだけで手戻りが減る。 最初にやることは単純だ。変更したファイルを見せて、目的と合わせてレビューさせる。雑に「見て」では弱い。何を重点的に見てほしいかを言う。 ```bash claude ``` ```text この差分をレビューしてほしい。 目的は「検索しやすいようにファイル名を整理すること」だ。 次の観点で厳しめに見てください。 変更の意図と結果がずれていないか 例外ケースを壊していないか 命名が一貫しているか 余計な変更が混じっていないか もっと安全で単純なやり方があるか 指摘は重要度順に並べてください。 「問題なし」で終わらせず、気になる

コミットメッセージを「それっぽく一行で」済ませると、あとで自分が困る。Claude Code に任せるなら、そこを雑にしないほうがいい。粒度がバラついたメッセージは、履歴を読めなくするだけでなく、変更の単位まで崩す。逆に、作法を先に揃えておくと、コミットはただの作業ログではなく、あとから効くメモになる。 Claude Code は、雑に「コミットメッセージ書いて」と頼んでも一応それなりに出す。だが、その「それなり」は危ない。人間の頭の中にある意図が曖昧なままだと、AI は平気で広くまとめすぎるし、逆に細かすぎる差分を無理に1本へ寄せることもある。筆者は最初、ここを軽く見ていた。結果、1コミットに「UI の文言修正」と「不要ファイル削除」と「README 更新」が混ざり、あとで戻すときにかなり面倒だった。履歴が説明になっていない。あれは地味に痛い。 やるべきことは単純だ。Claude Code に「何を、どの粒度で、どういう型で」書かせるかを先に決める。 たとえば、こんな方針にする。 1コミット1目的に寄せる 変更の要約は命令形か現在形でそろえる 本文が必要なときだけ理由を書く 変更の範