エックスサーバー・SWELL・Claude ほか、運営に役立つサービスをまとめました
オレンジ枠のサービスは、ジャベ雄が今も使っているものです
※ 一部のリンクは広告(アフィリエイト)を含みます
Gitが何をする道具かは分かった、でも実際どう使うのか
そこで止まっていませんか?
結論から言うと、操作はぜんぶAIに日本語で頼めます
コマンドは出てきますが、打つ必要はなくて意味が読めれば足りるんです
ここで通すのは入れる → 最初のセーブを打つ → 毎日回す → 戻すの4つ
用語の意味はGitとは何か 未経験のための最小の説明にまとめてあります
Claude Codeに「Gitを入れて」と頼むところから
Gitが入っていないパソコンでもClaude Code自体は動くので、入れる作業から任せられるんです
winget install --id Git.Git -e --source winget
これはAIが裏で実行するコマンドなので、読めれば十分
入れ終わった直後に、ちょっとだけ人の手が要ります
ターミナルとAIのセッションを一度閉じて、開き直すことです
新しく入ったソフトの居場所が開いたままの画面に反映されないためです
私も最初これを飛ばして、Gitが見つからないと言われて止まったんです
開き直したら、最初に1回だけの初期設定をまとめて頼みます
名前・メールアドレス・初期ブランチ名・日本語ファイル名の表示を、「この内容で設定して」と伝えるだけ
git config --global user.name "表示したい名前" # コミットに残る名前
git config --global user.email "使いたいアドレス" # コミットに残るメールアドレス
git config --global init.defaultBranch main # 初期ブランチ名をmainに(GitHubの既定と揃う)
git config --global core.quotepath false # 日本語のファイル名をそのまま表示する
ここで入れたメールアドレスはコミットの履歴に残ります
手元だけなら見えませんが、あとでGitHubに公開すると誰でも読める状態になるんです
私用のアドレスを避けるか、GitHub側の公開用noreplyアドレスを使うのがおすすめ
設定まで終わったら「Gitが入ったか確認して」と頼むだけ
git --version

wingetが使えないパソコンもあります
そのときは公式サイトの git-scm.com からインストーラを落としてください
選択画面はけっこう続きますが、初期ブランチ名だけmainにすれば、あとは既定のままで大丈夫

自分でターミナルを触るのはここまで
この先はAIに日本語で頼むだけ
見張ってもらうフォルダは記事の原稿フォルダで構いません
Gitの解説はソースコードを前提にしたものが多いですが、中身がMarkdownでも仕組みは同じなんです
頼み方はだいたいこのくらいの粗さで通じます
一度この言い方で試してみたら、そのまま最初のコミットまで進みました

2つ目をあいだに挟むのには理由があります
コミットする前に、履歴へ入れないものを決める工程を通しておきたいからです
Gitに「このファイルは管理しないでね」と伝えるリストが .gitignore
パスワードだったりAPIキーだったりを書いた設定ファイルは、外に出ると困るので除外します
一度コミットすると履歴に残り続けるので、最初のコミットの前に決めておくのが要点
ここだけは、何を入れないかを中身まで見て自分で決めてください
除外リストの案そのものはAIが作ってくれます
でも公開したら困るファイルを知っているのは自分なので、出てきたリストにはちゃんと目を通します
git init # このフォルダをGitの管理下に置く
# ここで .gitignore を用意する(履歴に入れないものを書く)
git status # 今どのファイルが対象になっているかを見る
git add . # 今あるファイルをセーブの対象に載せる
git commit -m "記事フォルダの初期状態" # セーブを1つ打つ(メッセージ付き)
git log --oneline # 打ったセーブを一覧で見る
右側のコメントが各行の意味
何をしているかだけ読めれば、打つ必要はありません
導入が終われば、あとは同じ輪を回すだけ
私が回している順番はこれ
作業を頼む前に「今の状態でコミットして」と伝えます
ここが戻り先になるので、順番を入れ替えないのがコツ
いつもどおり書き換えを頼みます
戻り先があるぶん、もっと大きめの依頼も出しやすくなります
「何を変えたか教えて」と聞くだけ
量が多いときは「変更点を3行で教えて」と要約させると読み切れます
受け入れるならセーブを打ち、要らないなら前の状態に戻します
この判断だけは人がやる工程
3番目の差分を見る工程がいちばん大事
ここを飛ばすと、気づかないうちに書き換わった箇所がそのまま履歴に積まれていきます
新しく作られたファイルは差分に出てこないことがあります
だから「新しく増えたファイルもある?」まで聞いておくと取りこぼしません
コミットの頻度は作業の区切りごとに1回で足ります
私は記事1本を書き終えたときと、大きめの修正を頼む直前の2回が中心
戻すと言っても影響の大きさが違う3つがあります
軽いものから順に試すのが安全
| 戻したいこと | AIへの言い方 | 消える範囲 |
|---|---|---|
| この原稿だけ、さっきのセーブの状態に戻したい | 「記事.md をさっきのセーブの状態に戻して」 | 小 |
| まだセーブしていない変更を、まとめて捨てたい | 「まだコミットしていない変更を全部捨てて」 | 中 |
| セーブを打った時点まで、丸ごと戻したい | 「3つ前のコミットの時点まで丸ごと戻して」 | 大(最後の手段) |
git restore articles/記事.md # そのファイルだけ、直前のセーブの状態に戻す
git restore . # 追跡済みファイルの変更だけ、直前の状態に戻す
git reset --hard <コミットのID> # その時点まで丸ごと戻す(消える範囲が一番広い)
3つとも、捨てた作業は戻りません
とくに1つ目・2つ目で消える「まだコミットしていない分」は、Gitの中のどこにも残っていないので取り戻せません
3行目を最後の手段と呼ぶのは、その時点より後のセーブごと無くなるからです
丸ごと戻すような操作は、何が消えるのかを先に聞いてから進めてください
戻したあとは「今どうなってる?」と聞いて状態を確かめます
新しく作られたファイルは戻す操作で消えないので、要らないものが残っていないかをここで見ておきます
戻したのに内容が変わらないときは、AIがすでに変更をステージに上げている状態
そのときは「直前のコミットの内容に戻して」と頼めば済みます
ジャベ雄Claude Codeの /rewind で戻せるなら、Gitは要らないんじゃないか?



役割が違います
rewindは会話の中の巻き戻し、Gitは会話の外にも残る杭です
Claude Codeには、会話の途中まで戻す /rewind があります
送った指示ごとにチェックポイントが作られていて、コードだけ・会話だけ・両方という単位で戻せるんです
でも守備範囲は会話の中だけ
公式の説明でもチェックポイントは手元の取り消し、Gitは残る履歴という整理で、置き換えるものではないと書かれています
/rewind が拾わない範囲もあります
コマンド経由で書き換わったファイルだったり、その会話の外で手を加えた変更だったりは追いかけていません
だからしばらく経ってからの安心は、やっぱりGit側が担います
ここまで一度もGitHubが出てきていません
Gitは手元のパソコンで動く仕組みで、GitHubはそれをネットに置いておく場所という別物なんです
どれも当てはまらないなら今は入れなくて大丈夫
使う理由がないまま登録しても、宿題が1つ増えるだけでしょう
始めるときはprivate(非公開)から入るのがおすすめ
非公開なら自分と招待した人以外は中身を見られませんし、備えとしての用途はこれで足ります
外に出すと、いまのファイルだけでなく過去のコミットの中身まで見られます
あとから非公開を公開に切り替えたときも同じで、ファイルを消しただけでは履歴に残った情報は消えません
もしパスワードやAPIキーが混ざっていたら、履歴を直すより先にそのキーを無効にして作り直すのが先決です
裏返しの注意も1つ
除外リストに書いたファイルはGitHubにも上がりません
設定ファイルや写真の元データは、別に控えを取っておいてください
アカウントの作り方や、手元のコミットを送る手順(プッシュ)はここでは扱いません
上の3つのどれかに当てはまってから調べれば間に合います
コメント