個人開発者が最初に覚える Git の基本コマンド
git init は打った。あとは git add . と git commit -m "..." を、半分呪文のように繰り返している。エラーは出ていないし、動いてはいる。でも、内部で何が起きているのかは、正直よく分かっていない。
個人開発で Git を使い始めた人の多くが、しばらくこの状態で止まります。コードは書けるのに、Git になると手が止まる。怖く感じる原因は、たいていこの 3 つです。
addしてからcommit、という 2 段階が何のためにあるのか分からない- 間違えてコミットしたら、もう元に戻せない気がする
git pushが赤い英語のメッセージで弾かれて、そこで固まる
先に、いちばん大事な結論を書きます。Git は「間違いを戻すための道具」です。 ターミナルの rm が一発でファイルを消す道具なのに対して、Git はその逆 ── 作業を記録し、いつでも前の状態に戻れるようにしておく道具です。怖さの向きが、そもそも逆なのです。
最初の 1 ヶ月で使うコマンドは 15 個ほど。この記事では、状態を見る・記録する・やり直す・GitHub とつなぐ、までを、詰まりやすい点とセットで順に整理します。ターミナル自体がまだ不安なら、先にターミナル初学者が最初に覚えるべき基本コマンドを読んでおくと、この記事がぐっと楽になります。
1. 状態を見る
Git では「いま何が記録待ちで、何が記録済みか」が常に起点になります。これが見えていれば、ほとんどの操作は怖くありません。
| コマンド | 動作 |
|---|---|
git status | 変更・ステージの状況を表示 |
git log | コミット履歴を表示 |
git log --oneline | 履歴を 1 行ずつ簡潔に表示 |
git diff | まだステージしていない変更の中身 |
git diff --staged | ステージ済みの変更の中身 |
挫折ポイント：Git で迷ったら、考える前にまず git status。これはターミナルの pwd に当たる方位磁針で、「いま何が起きているか」を教えてくれます。git status を読む癖がつくだけで、Git の不安の半分は消えます。英語が並んでいても、Changes not staged（記録待ち）と Changes to be committed（記録対象）の 2 つだけ拾えれば、当面は十分です。
2. 記録する（add → commit）
Git の中心は、変更を「コミット」という単位で記録していくことです。記録は 2 段階に分かれています。
| コマンド | 動作 |
|---|---|
git add ファイル名 | そのファイルの変更を、次の記録対象に加える |
git add -A | 変更を全部まとめて記録対象に加える |
git commit -m "メッセージ" | 記録対象を 1 つのまとまりとして確定する |
git commit -am "メッセージ" | 追跡中ファイルの add と commit をまとめて行う |
挫折ポイント：なぜ add と commit が分かれているのか ── ここが最初の関門です。add（ステージ）は「この変更を、次の記録に含める」という仕分け作業。commit は「仕分けたものを、1 つの記録として確定する」作業です。10 個ファイルを変更しても、add した分しか commit には入りません。最初は難しく考えず、「全部記録したい」なら git add -A のあとに git commit -m "..."、これだけで回ります。コミットメッセージは「何をしたか」を一行で（記事を1本追加 のように）書けば十分です。
3. やり直す
Git を使う最大の安心材料が、このセクションです。
| コマンド | 動作 |
|---|---|
git restore ファイル名 | 作業中の変更を捨て、最後のコミットの状態へ戻す |
git restore --staged ファイル名 | add を取り消す（変更そのものは残る） |
git commit --amend | 直前のコミットをやり直す（メッセージ修正・入れ忘れの追加） |
挫折ポイント：restore と、よく聞く reset は紛らわしいので、最初は割り切ります。覚えるのは git restore（作業中の変更を捨てる）と git restore --staged（add を取り消す）の 2 つだけ。git reset --hard は履歴ごと巻き戻す強い操作なので、意味が分かるまで使いません。一度 commit してあれば、その後はたいてい何をしても元の状態に戻せます。 だから、こまめにコミットしておくほど、安心して実験できます。
4. .gitignore で「記録しないもの」を決める
リポジトリには、記録すべきでないファイルもあります。.gitignore という名前のファイルを作り、1 行に 1 つ、記録から外したいものを書きます。
node_modules/
.env
dist/挫折ポイント：個人開発で多いのが、.env（API キーやパスワードを書くファイル）をうっかりコミットしてしまう事故です。リポジトリを作ったら、最初に .gitignore へ node_modules/・.env・dist/ を書いておきます。注意したいのは、一度コミットしてしまった秘密情報は、後から .gitignore に足しても履歴には残り続けること。その場合はファイルを消すだけでは不十分で、漏れたキー自体を作り直すのが安全です。
5. GitHub とつなぐ
手元のリポジトリを GitHub と同期します。
| コマンド | 動作 |
|---|---|
git clone URL | リモートのリポジトリを手元に複製する |
git remote add origin URL | 手元のリポジトリに、GitHub 上の場所を登録する |
git push | 手元のコミットを GitHub へ送る |
git pull | GitHub 側の変更を手元に取り込む |
挫折ポイント：git push が rejected（拒否）で弾かれるのは、ほとんどの場合「GitHub 側に、手元が持っていないコミットがある」ときです。あわてず git pull で取り込んでから、もう一度 push すれば通ります。個人開発では、git push がそのままサイトのデプロイ（公開）になる構成も少なくありません（このサイト自身も、git push で本番に反映されます）。push を「保存」と「公開」の両方の意味で意識しておくと、事故が減ります。
6. ブランチ（慣れてきたら）
ブランチは、作業の流れを枝分かれさせる仕組みです。
| コマンド | 動作 |
|---|---|
git branch | ブランチの一覧を表示 |
git switch -c 名前 | 新しいブランチを作って移動する |
git switch 名前 | 既存のブランチへ移動する |
git merge 名前 | 指定したブランチの変更を、今のブランチへ取り込む |
挫折ポイント：個人開発のごく初期は、ブランチを使わず main 1 本でも問題なく回ります。「試したいけれど、動いている状態は壊したくない」変更が出てきたとき、初めて git switch -c try-xxx を覚えれば十分です。マージ時にまれに起きる衝突（コンフリクト）は、両方で同じ行を変えたという合図。慌てず該当ファイルを開き、<<<<<<<・=======・>>>>>>> の印の間を見比べて、残したい形に手で整え、印の行を消す ── やることは、それだけです。
まとめ
Git を最初の 1 ヶ月で使えるようになるコツは、3 つです。
- 困ったら
git statusとgit log：今の状態さえ見えれば、たいていの操作は怖くない。迷ったらこの 2 つに戻る - 強い操作だけ恐れる：
git reset --hard、git push --forceは、意味が分かるまで使わない。それ以外は、コミットさえしてあれば戻せる - 小さく、こまめにコミットする：「動いた」「1 機能できた」の単位で
commitする。大きく溜めるほど、後で戻れる場所が粗くなる
最初は遅くて構いません。1 週間で add・commit・status が手に馴染み、2 週間で push・pull が反射的に出るようになります。1 ヶ月後には、Git は「黒い画面の不安な何か」ではなく、履歴を気にせず実験できる安全網に変わっています。
コミットやレビューを AI に任せる場面も増えました。Claude Code から Git をどう触るかは、別記事 Claude Code のスラッシュコマンド 30 個 が参考になります。