設定ファイルを直して上書き保存した。翌日、動かなくなった。昨日の自分は何をどう変えたのか、思い出せない。バックアップ代わりに config_old.txt config_old2.txt config_最新.txt が増えていく。どれが本当の最新か分からない。「Git を使え」と言われるけれど、コミットとか GitHub とか、何が何をしているのかが掴めない。この記事は、上書き保存で困る3つのことから始めて、Git を「版の台帳」として掴み、最初の3つの動作だけを覚えるところまでを1本にします。
この記事の結論
- Git とは、ファイルの「版」を台帳のように残していく道具です。上書きではなく、積み重ねます。
- 上書き保存で困るのは、前に戻れない・誰が何を変えたか分からない・2人で同時に触れない、の3つです。
- 最初に覚える動作は3つ。ファイルを変更する → 次の版に入れるものを選ぶ（add）→ 版として確定する（commit）。
- Git は手元で動く道具、GitHub はその台帳を置いて人と共有する場です。GitHub が無くても Git は動きます。
- クラウドで Git が要るのは、サーバーの構成や設定を「文字」で持ち、その変更を台帳に残すのが仕事の土台になるからです。
上書き保存の何が困るか。3つの「戻れない」
Word でもメモ帳でも、保存すると前の中身は消えて新しい中身に置き換わります。これが上書き保存です。1人で短い文章を書いているうちは困りません。困るのは、ファイルが「動くもの」の設定になったときです。
- 前に戻れない。 昨日まで動いていた設定に戻したいのに、上書きしたので昨日の中身が無い。
- 誰が何を変えたか分からない。 「いつ・誰が・なぜ」この行を足したのかが、ファイルのどこにも残っていない。
- 2人で同時に触れない。 同じファイルを2人が開いて、それぞれ保存すると、あとから保存した方が先に保存した方の変更を消してしまう。
config_old2.txt を増やすのは、1の「戻れない」を人力でしのぐ工夫です。でも2と3は解けませんし、どれが最新かも分からなくなります。この3つを同時に解くために作られた道具が、バージョン管理システムです。
OVERWRITE VS VERSIONS何が困るか
上書きは消える。版は積み重なる
上書き保存
保存すると前の中身が消える
- 昨日の設定に戻れない
- 誰がいつなぜ変えたかが残らない
- 2人で触ると、あとから保存した方が勝つ
版を残す（Git）
保存のたびに台帳に1行足す
- どの時点の版にも戻れる
- 誰が・いつ・なぜ、がコミットに残る
- 2人の変更を合流できる。黙って消さない
Git とは「版の台帳」。上書きせず、積み重ねる
Git は、バージョン管理システムの1つです。ファイルを保存するたびに前の中身を消すのではなく、「この時点の中身」を版として台帳に1行ずつ足していきます。
たとえるなら、紙の台帳です。ページを破って書き直すのではなく、「8月13日、山田、設定 A のポート番号を 80 から 443 に変更」と1行ずつ書き足していく。台帳をさかのぼれば、どの時点にも戻れるし、誰が何をしたかも読めます。
この「台帳に載った1行」がコミットです。コミットには、変更後の中身、誰が、いつ、そして「なぜ」を書くメッセージが付きます。Git は中身を上書きせず、コミットを積み重ねる。これが Git の全部と言ってもよいくらいの中心です。
台帳そのもの（ファイル一式と、その版の履歴の全部）をリポジトリと呼びます。自分のパソコンの中のフォルダ1つが、そのままリポジトリになります。
なぜ台帳を「自分のパソコンの中」に持つのか。Git 以前のバージョン管理は、台帳が中央のサーバーに1つだけあり、つながらないと履歴を見ることも版を残すこともできませんでした。Git は台帳の全部を手元に持つので、ネットが無くてもコミットでき、あとで共有すればよい。この設計が、次の節の「3つの動作」と、その後の「GitHub との違い」の両方につながっています。
CHECK 1ここまでの確認
「上書き保存」と比べたとき、Git が解いてくれる困りごととして正しくないものはどれ?
答えと解説
答え: 3. ファイルの中身の間違いを自動で直してくれない
Git は「版を残す台帳」であって、中身の正しさは判定しません。戻れる・誰が変えたか分かる・同時に触れる、の3つが Git の担当です。「上書き保存の何が困るか」の節を読み直してください。
最初の3つの動作。変更する → add → commit
Git には数十のコマンドがありますが、最初に覚えるのは3つの動作です。ファイルは、この3つの動作で3つの場所を移動していきます。
| 動作 | 何をするか | ファイルの状態 | たとえ |
|---|---|---|---|
| 変更する | エディタでファイルを直して保存する | 直したが、Git はまだ「次の版に入れる」と聞いていない | 机の上で書類を直す |
| add | 次の版に入れるファイルを選ぶ | 「次の版の候補」の箱に入った状態（ステージング） | 提出する書類だけをトレイに載せる |
| commit | 候補の箱の中身を、メッセージ付きで版として確定する | 台帳に1行載った | トレイの書類に日付と名前を書いて綴じる |
「変更したのに、なぜわざわざ add で選ぶのか」と最初は誰もが思います。理由は、1回のコミットを「意味のある1つの変更」にそろえるためです。設定 A の修正と手順書 B の追記を同時にやったとき、A だけを選んで1つ目の版にし、B を2つ目の版にできる。あとで「A だけ戻したい」ができるのは、この選ぶ段階があるからです。
CHANGE / ADD / COMMIT / PUSH変更が版になるまで
変更して、選んで、確定する。共有はそのあと
-
変更する
エディタで直して保存。Git はまだ知らない
-
add — 選ぶ
次の版に入れるファイルを箱に入れる
-
commit — 確定
メッセージ付きで台帳に1行載せる
-
push — 送る
手元の台帳の新しい行を置き場に写す
4つ目の駅が push です。これは「手元の台帳の新しい行を、置き場の台帳にも写す」動作で、共有のための一歩です。ただし3つの動作が身についてからで構いません。1人で手元のファイルを管理しているうちは、変更 → add → commit を回すだけで、上書き保存の困りごと1と2は解けています。
ターミナルの読み方で見た黒い画面で、この3つを git add git commit と打つのが基本の形です。細かい書き方は公式ドキュメントに「Git の基本」としてまとまっているので、そこで確認してください。
CHECK 2ここまでの確認
ファイルを直したあと git add を打った。この時点でファイルの状態は?
答えと解説
答え: 2. 次の版に入れる候補として選ばれただけ（まだ確定していない）
add は「次の版に入れるものを選ぶ」動作で、版として確定するのは commit です。GitHub に送るのはさらに別の push です。「最初の3つの動作」の節の旅の図を読み直してください。
Git と GitHub の違い。道具と、置き場
Git の話をすると必ず出てくる GitHub は、Git そのものではありません。
- Git は道具。 自分のパソコンの中で動き、台帳（リポジトリ）を作り、版を残す。インターネットが無くても動く。
- GitHub は置き場と、共同作業の場。 Git の台帳をインターネット上に置いて、人と共有し、変更を見せ合い、取り込むためのサービス。
たとえるなら、Git は「台帳を書く技術」、GitHub は「台帳を保管して回覧する事務所」です。事務所が無くても台帳は書けますが、2人以上で同じ台帳を育てるには、置き場がある方が便利です。上書き保存の困りごと3「2人で同時に触れない」を解くのが、この置き場と、そこでの「取り込み」の仕組みです。
THE LOOP OF WORK2人以上で回す輪
手元で確定し、置き場で共有し、相手の分を取り込む
版の台帳
- 変更する
- commit で確定
- push で共有
- 相手の分を取り込む
Git
台帳を書く道具
手元で動く。ネットが無くても commit できる
GitHub
台帳を置いて回覧する場
共有と取り込みを担う。無くても Git は動く
2人で作業するときの輪はこうなります。自分が手元で変更して確定する（commit）→ 置き場に送る（push）→ 相手も同じことをする → 相手の変更を自分の手元に取り込む。Git は、2人が別の行を直していれば自動で合流させ、同じ行を直していたら「どちらにするか決めて」と止めてくれます。黙って片方を消すことはしない。これが上書き保存との決定的な差です。
置き場は GitHub だけではなく、GitLab など他のサービスもありますが、Git の3つの動作はどこでも同じです。
CHECK 3ここまでの確認
Git と GitHub の関係として近いのはどれ?
答えと解説
答え: 2. Git は手元で版を残す道具、GitHub は版を置いて人と共有する場
Git は自分のパソコンの中だけで完結する道具で、GitHub は台帳を置いて共同作業する場（サービス）です。GitHub 無しでも Git は使えます。「Git と GitHub の違い」の節を読み直してください。
クラウドで Git が要る理由。構成を「文字」で持つ入口だから
「自分はプログラマーではなく、インフラをやりたい。それでも Git は要るのか」という問いには、要る、と答えます。理由はクラウドの仕事の形にあります。
クラウドでは、サーバーの台数・ネットワークの区画・門（セキュリティグループ）の札といった構成を、画面で押すのではなく文字のファイルで書いて、それを AWS に渡して作らせる方法があります。これを IaC（Infrastructure as Code、構成をコードで持つ）と呼びます。AWS では CloudFormation や CDK がその代表です。
構成が文字のファイルなら、Git の台帳に載せられます。すると、「先週、誰が、なぜ、この門の札を全世界に開けたのか」が台帳に残る。戻したければ前の版に戻せる。2人で同じ構成を育てられる。上書き保存の3つの困りごとが、そのままインフラの事故の形だと気づけば、Git が要る理由は自明です。
もう1つ、自動デプロイの入口でもあります。「台帳に新しい版が載ったら、検査を走らせて、通ったら AWS に反映する」という流れは、Git のコミットを合図に動きます。この流れそのものは上の段で扱いますが、その合図が「commit」であることだけ、いま覚えておいてください。
まとめ
Git とは、ファイルの版を台帳のように残していく道具です。上書き保存で困るのは、前に戻れない・誰が何を変えたか分からない・2人で同時に触れない、の3つ。Git はコミットを積み重ねることでこの3つを解き、GitHub はその台帳を置いて共有する場です。最初に覚える動作は、変更する → add → commit の3つだけ。クラウドでは構成を文字で持つ（IaC）ので、その変更を台帳に残す Git が仕事の土台になります。
最初にやることは1つです。手元にある設定ファイル（シェルの設定でも、SSH の設定でも、メモでも構いません）を入れたフォルダを1つ Git の台帳にして、直すたびに add と commit を回してみる。1週間も続ければ、台帳をさかのぼって「先週の自分が何をしたか」を読む体験ができます。それができたら、次は「画面で押すこと」を文字で頼む AWS CLI とは何かへ。全体の進め方は最初の1か月にまとめてあります。
READ ALSO — 未経験向け・段1 入口
未経験がクラウドを学ぶ最初の1か月｜週ごとの順番と、やらないことを先に決める
参照ソース
- Pro Git（日本語版）1.1 バージョン管理に関して — バージョン管理が「版を記録して呼び戻せる」仕組みであること、中央集中型と分散型（Git は台帳の全部を手元に持つ）の違いの根拠（第2版、2026年9月時点）
- Pro Git（日本語版）1.3 Git の基本 — ファイルが「変更した・ステージした・コミットした」の3つの状態を移ること、Git が差分ではなくスナップショット（版）を残すことの根拠（第2版、2026年9月時点）
- git-add(1)・git-commit(1)・git-push(1) — add が「次のコミットに入れる内容を選ぶ」、commit が「ステージした内容を記録する」、push が「リモートの台帳を更新する」動作であることの根拠（2026年9月時点）
- AWS CloudFormation とは（AWS CloudFormation ユーザーガイド） — インフラの構成をテンプレート（文字のファイル）で書いて作れること、それがバージョン管理できることの根拠（2026年9月時点）
