非エンジニアがGitを最低限使うための手順──コミットと差し戻しだけ覚える

Claude CodeやCursorのようなAIコーディングエージェントに作業を任せると、コードの編集だけでなくGitの操作(add・commit・場合によってはreset)も代わりにやってくれる。便利な反面、非エンジニアがGitの意味を理解しないまま任せきると、何が起きたか分からないまま変更が消えたり、意図しないファイルがコミットに混ざったりする。この記事では、コードを書けなくても最低限押さえておきたいGit操作と、実際に自分の運用で起きたステージング事故を書く。

• Gitの操作で非エンジニアが最初に覚えるべきは3つだけでいい。今の状態を見るstatus、変更を記録するcommit、そして取り消しの中でも「作業中のファイルまで消す」危険なreset --hardを見分けること
• 2026年8月14日、AIエージェントを複数並行で走らせている最中にgit add -A(全部まとめてステージ)を使い、まだ編集途中だった別の作業を意図せずコミットに巻き込む事故が同じ日に3回起きた
• Git公式ドキュメントによると、git reset --hardは指定したコミットにない変更を作業ディレクトリ側からも削除する。「コミットを取り消す」操作の中でも、これだけは対象範囲が別格に広い

最低限これだけ

非エンジニアがAIエージェントと一緒にコードを触る場合、覚えるコマンドは多くなくていい。最低限、次の3つが分かっていれば、エージェントが何をしたか・何をしようとしているかを追える。

これに加えて、「取り消し」に関わるコマンドは、実行前に何が起きるかを理解してから使う必要がある。特にgit reset --hardは影響範囲が広いので、次の節で分けて書く。

実際に起きた事故: git add -Aが別の作業を巻き込んだ

2026年8月14日、複数のAIエージェントを並行して走らせ、それぞれ別々の記事ファイルを編集させていたときのことだ。1つのエージェントの作業が終わったのを確認してコミットしようとした際、対象ファイルを1つずつ指定するのが面倒でgit add -Aを使った。

なぜこれが事故につながるのか、Git公式リファレンス（git-add）の該当箇所を確認すると理由が明記されていた。

If no <pathspec> is given when -A option is used, all files in the entire working tree are updated (old versions of Git used to limit the update to the current directory and its subdirectories).

（-Aオプションを使う際に<pathspec>を指定しなければ、作業ディレクトリ全体のすべてのファイルが更新対象になる。旧バージョンのGitでは、この更新をカレントディレクトリとそのサブディレクトリに限定していたが、現在はそうではない）

つまり-Aは「今いるディレクトリ以下」ではなく「リポジトリ全体」が対象になる。この操作は、その時点でまだ編集が終わっていない別のエージェントの作業途中のファイルまで一緒に巻き込んでしまう。同じ日に3回同じ失敗を繰り返し、3回目は46ファイルがステージされた時点で気づいてgit reset(ステージを取り消す。ファイルの中身は変わらない)でいったん戻した。

この事故から得た教訓はシンプルだ。並行して複数の作業が走っている可能性があるときは、-Aのような一括指定を使わず、対象ファイルを名前で指定する。

git add -- content/news/slug1.md
git add -- content/news/slug2.md

「今動いている作業が本当に0件か」を確認してから一括指定を使う、という順番を守ることで再発を防いだ。

resetには種類があり、危険度が違う

コミットを取り消したいとき、Gitには--soft・--mixed・--hardという選択肢がある。このうち非エンジニアが特に注意すべきは--hardだ。Git公式リファレンスには次のように書かれている。

Overwrite all files and directories with the version from <commit>, and may overwrite untracked files. Tracked files not in <commit> are removed so that the working tree matches <commit>. (訳: <コミット>時点のバージョンで、すべてのファイルとディレクトリを上書きする。追跡されていないファイルも上書きされうる。<コミット>に含まれていない追跡済みファイルは削除され、作業ディレクトリが<コミット>と一致する状態になる)

「コミットを取り消す」というと、記録だけが消えて今書いている途中のファイルは残るように感じるかもしれないが、--hardはそうではない。作業ディレクトリ側の変更そのものを、指定したコミットの状態に合わせて上書き・削除する。まだコミットしていない編集中の内容も、この操作で失われる。

非エンジニアがAIエージェントに「変な状態になったので元に戻して」と頼んだとき、エージェントがreset --hardを提案してくることがある。それ自体が間違いとは限らないが、実行する前に「今のコミットされていない変更は消えていいものか」を必ず確認した方がいい。

push --forceは「リモート側の記録」を上書きする

reset --hardが手元の作業ディレクトリを上書きするのに対し、push --forceはリモート（GitHub等）側の記録を上書きする。Git公式リファレンス（git-push）は次のように説明している。

Usually, git push will refuse to update a branch that is not an ancestor of the commit being pushed. This flag disables that check... It can cause the remote repository to lose commits; use it with care.

（通常、git pushはプッシュ対象のコミットの祖先になっていないブランチの更新を拒否する。このフラグはそのチェックを無効化する…リモートリポジトリ側のコミットが失われる可能性があるため、注意して使うこと）

「リモート側のコミットが失われる可能性がある」と公式ドキュメントが明記している通り、push --forceは自分の手元だけでなく、共同作業者や別の場所（別マシン・CI環境など）から見えているコミット履歴そのものを書き換えてしまう。1人で作業している場合でも、GitHub上に公開しているリポジトリであれば影響範囲は手元のディスクを超える。AIエージェントがこのコマンドを提案してきたら、reset --hard以上に「なぜ必要か」を確認してから実行すべきだ。

これだけ守れば大きな事故は防げる

• 変更を加える前と、コミットする前にはgit statusを見る癖をつける。AIエージェントに聞くだけでなく、自分でも打てるようになっておくと、エージェントの説明が実際の状態と合っているか確認できる
• ファイルを一括指定(-Aや.)でステージする前に、他に動いている作業がないか確認する
• reset --hard・push --forceのような、対象範囲が広い取り消し系のコマンドをAIエージェントが提案してきたら、実行前に「何が消えるか」を聞いてから答える。分からないまま「はい」と答えない

Gitのバージョンによる挙動差は確認していない

• 本記事で引用したGit公式リファレンスの文言は、2026年8月27日にcurlで取得したgit-scm.comのドキュメントページに基づく。手元の環境で実際に使っているGitのバージョンと、ドキュメントが説明しているGitのバージョンが完全に一致するかは確認していない。-Aオプションの挙動は「旧バージョンのGitではカレントディレクトリ以下に限定されていた」と公式ドキュメントにも明記されている通り、バージョンによって変わってきた経緯がある
• git add -Aの事故については自分の運用ログに基づく記述で、他の環境・他のエージェント（Cursor・GitHub Copilot等）でも同様の事故が起きるかどうかは検証していない
• AIエージェントがreset --hardやpush --forceを「提案してくる」という記述は、自分が実際に使っているエージェント（Claude Code）での経験に基づくもので、すべてのAIコーディングエージェントが同じように振る舞うと一般化できるものではない

この記事で扱わなかったこと

正直に書いておくと、この記事はブランチを切って複数人で作業を分担する場面や、コンフリクト(競合)の解決には触れていない。それらは非エンジニアが1人でサイトや個人開発を回している段階では、優先して覚える必要性が低いと判断したためだ。チームでの共同作業が発生する段階になったら、別に学ぶ必要がある領域として切り分けている。

AIエージェントが直接ファイルをデプロイする仕組みを使っている場合、git statusが示す内容と本番に反映されている中身が一致しないことがある点は、Vercel CLIはgitではなく作業ツリーを直接デプロイするで扱った。公開前にAIが生成した変更のどこを見るかは、非エンジニアがAI生成コードを本番に出す前に見る判断基準に整理している。ビルドやプロセス管理まわりで実際に起きた事故は非エンジニアがAIコーディングで事故った話にまとめた。