#claude-code-git

古いコードや見慣れない削除を前にしたとき、いちばん欲しいのは「誰が書いたか」より「なぜ残っているか」です。Claude Code には、対象ファイルを読みつつ git の履歴も手がかりにして、変更の背景を文章で整理させる使い方があります。単なる要約ではなく、「この行がいつ入ったか」「直前に何が壊れていたか」「削除してよいかの判断材料は何か」を拾わせるのがコツです。 たとえば、リファクタリング前の分岐が妙に残っている、見えないところで古い設定が生きている、文書フォルダに古いテンプレートが増殖している。そういう場面で、Claude Code に履歴を追わせると、コードの現在形だけでは見えない理由が見えてきます。非エンジニアでも、ファイル整理や文書作成の「これは何のために置いてあるのか」を詰める用途に向いています。 使い方は、先に「いま見えているファイル」と「履歴」を両方見せることです。Claude Code に対して、対象の場所を決めたうえで、こんなふうに頼みます。 ```text このファイルについて、git 履歴を手がかりに「なぜこのコードやこの記述があるのか」を説明してください。 見

Claude Code にコンフリクト解消を手伝ってもらうときは、いきなり「直して」と丸投げするより、ぶつかった場所と、元に戻せる材料を一緒に渡すほうがうまくいきます。 Git のマージ衝突でも、文章ファイルの差分でも、やることは似ています。迷っている箇所を見える形にして、判断材料を少し添える。これだけで、やり直しの手間がかなり減ります。 まず渡すべきなのは、コンフリクトが起きたファイルそのものです。できれば `<<<<<<<` `=======` `>>>>>>>` が残った状態のまま、修正前の内容を含めて見せます。Claude Code は周辺の文脈を読めますが、衝突の境目が消えてしまうと「どこが両者の食い違いか」が分かりません。 実際の依頼は、こんな形が使いやすいです。 ```text このコンフリクトの解消を手伝ってください。 優先したいのは A ブランチ側の意図ですが、B ブランチ側の次の変更も残したいです。 このファイルは最終的に読みやすい文章にしたい 数値や固有名詞は B 側を優先したい 文章のトーンは A 側に寄せたい 衝突マーカーが残っている状態のまま、このフ

プルリクエストの説明文は、あとで見返したときに「何を、なぜ、どう変えたか」が残る大事な記録です。Claude Code を使うと、差分やコミットメッセージ、メモを材料にして、ひとまず読める下書きを短時間で作れます。空白のフォームを前にして止まる時間が減り、説明の抜けもかなり抑えられます。 やり方は難しくありません。Claude Code に「変更内容を要約して、PR 本文の形に整えて」と頼むだけです。ただし、任せきりにすると危ないところもあるので、下書きに入れてほしい材料と、入れてほしくない推測をはっきり伝えるのがコツです。 たとえば、ローカルの作業ディレクトリで次のように頼めます。 ```text このブランチの変更を読んで、プルリクエスト本文の下書きを日本語で作ってください。 次の構成で、Markdown のまま出してください。 変更の要約 背景と目的 主な変更点 動作確認 気になる点・未対応事項 条件: 事実だけを書く 変更内容を勝手に補わない 断定できないことは「要確認」と明記する 読み手はこのリポジトリを知っている社内メンバーを想定する 箇条書きは短く、説明は簡潔に ```

Claude Code で壊れやすいコードを直すとき、いきなり書き換えに入らないのがコツです。先に「今の振る舞い」をテストや確認手順として残してから手を入れると、直したつもりで別の場所を壊す事故がぐっと減ります。コード整理でも、文書の大掃除でも、ディスク削減でも同じです。先に基準を作ってから触る。これだけで作業の怖さがかなり下がります。 リファクタという言葉は少し硬いですが、要するに「見た目や構造を整えるが、動きは変えない」作業です。Claude Code はこのとき、ただ修正案を出すだけでなく、「どこを保護するか」「何を確認してから変えるか」を一緒に考えさせると安定します。 たとえば、Python の関数を分割したい、古い命名を揃えたい、重複ファイルの整理ロジックを見直したい、契約書テンプレートの章立てを整えたい。どれも、先にテストの形を決めておくと安心です。機械的な単体テストでなくても、手順書や比較用のサンプルでもかまいません。 まずは Claude Code に、直す前に「守るべき現状」を拾わせます。依頼文はこんな感じで十分です。 ```text このリポジトリで、今の動きを変え

Claude Code でいちばん役に立つ使い方のひとつが、自分が触った差分をその場でレビューしてもらうことです。 書いた本人は「何をしたか」を知っているので、抜けや危うさに気づきにくいものです。そこで Claude Code に、変更したファイルだけを読ませて「この差分の気になる点を挙げて」と頼む。これだけで、ロジックの穴、説明不足、不要な変更、うっかり混ぜた雑修正がかなり見つかります。 エンジニアならコードレビューの補助に、非エンジニアなら文書や整理作業のセルフチェックに向いています。たとえば、契約書のドラフトで言い回しがぶれていないか、フォルダ整理で同じファイルを二重に残していないか、Markdown の文章で見出し構造が崩れていないか。人間の目だと見落としやすいところを、差分ベースで拾わせる使い方です。 --- まずは、変更したあとにそのままレビューさせます。大げさな設定は要りません。作業対象のディレクトリにいる状態で、普通に「レビューして」と依頼します。 ```text この変更内容をレビューしてください。 特に次を見てください。 仕様や意図から外れていないか 不要な

Claude Code にコミットメッセージを任せると、差分の要点を短く拾って、書きぶりも揃えやすくなります。人が毎回ゼロから考えるより、まず「何を変えたか」を安定した粒度で出させるほうが、履歴が読みやすくなります。特に、作業の切れ目が細かい日や、ひとつの修正に説明が要る日ほど効きます。 ただし、任せ方が雑だとメッセージも雑になります。Claude Code は“それっぽい文”を作るのは得意ですが、コミットの単位まで自動で整えてくれるわけではありません。ここで大事なのは、文章の上手さより先に、差分の見方を揃えることです。 たとえば、1 回のコミットで混ぜるのは「1 つの目的」に寄せます。誤字の修正、文書の言い回しの整理、不要ファイルの削除、設定ファイルの調整。これらをひとまとめにして「いろいろ修正」と書かせると、あとで履歴を追えません。Claude Code には、まず変更点を要約させ、その後でコミットメッセージに落とし込ませるのが扱いやすいです。 実際の使い方はシンプルです。Claude Code に対して、差分を見たうえで「短い要約 → コミットメッセージ」の順で出してもらいます。

Claude Code にまとめて置換を頼むと、たしかに早いです。けれど、ひとたび思った通りでない変更が混ざると、どこから直せばいいか分からなくなります。そこで効くのが、小さく直して、小さく確かめて、問題があればすぐ戻せる形に分けるやり方です。 これは開発だけの話ではありません。大量の文書名を揃える、案件フォルダの中身を整理する、重複した表記を統一する、といった作業でも同じです。 Claude Code は、ファイルを直接書き換える前に「どう分けて進めるか」を人間が決めておくと、とても扱いやすくなります。いきなり全件置換を指示するより、まず対象を絞り、次に一部だけ反映し、最後に確認して広げる。この順番にすると、途中で止めても作業が崩れません。 たとえば、社内文書の表記を「メールアドレス」から「連絡先」に寄せたい、あるいは案件資料のファイル名から日付の表記ゆれをなくしたい。そんなときは、最初から「全ファイルを一斉に置換して」と頼むのではなく、次のように進めます。 ```text 1. まず対象ファイルを一覧にして 2. 変更候補を確認できる差分を出して 3. 1つのフォルダだけ先