「ファイル名が『企画書_最終_修正2_これが本当に最終.docx』になっている」――この混沌を根本から解決するのがバージョン管理システムGit(ギット)です。
Gitはプログラマーだけの道具ではありません。文書・設定ファイル・Webサイトなど「変更履歴を残したいもの」すべてに使えます。この記事では、仕組みのイメージと最初に覚える5つのコマンド、GitHubとの関係までを初心者向けに解説します。
Gitは「巻き戻せるセーブ機能」
Gitを一言で言えば、フォルダの状態を好きなタイミングでセーブ(記録)し、いつでも過去のセーブ地点に戻れる仕組みです。ゲームのセーブデータを想像してください。
- セーブ地点(コミット)には「何を変えたか」のメモが付く
- いつ・誰が・どこを変えたかが全履歴として残る
- 失敗しても、動いていた時点に確実に戻れる
- 複数人で同じフォルダを安全に編集できる(仕事でGitが必須とされる理由)
基本の流れ:3つの場所を意識する
Gitには「作業フォルダ→ステージ→リポジトリ」という3つの場所があります。ポイントは、セーブが2段階に分かれていることです。「add」で記録したい変更を選び、「commit」でメモ付きの記録として確定する。この2段階のおかげで、複数の変更のうち一部だけをきれいに記録できます。
最初に覚える5コマンド
| コマンド | 働き |
|---|---|
| git init | フォルダをGit管理下にする(最初に1回だけ) |
| git status | 現在の変更状況を表示。迷ったらまずこれ |
| git add ファイル名 | 変更をステージに載せる(全部なら git add .) |
| git commit -m “メモ” | ステージの内容を履歴として記録 |
| git log –oneline | これまでの記録を一覧表示 |
コミットのメモ(コミットメッセージ)は「見出しを修正」「◯◯のバグを修正」のように、後で読む自分がわかる具体的な一文にするのがコツです。
GitとGitHubの関係
よく混同されますが、Gitは自分のPCで動く仕組み、GitHubはGitの履歴を預かるクラウドサービスです。GitHubに履歴を置く(push)ことで、バックアップ、他の人との共同作業、作品の公開(ポートフォリオ)ができるようになります。まずはPC内のGitだけで練習し、慣れたらGitHubへ進む2段階がおすすめです。
導入方法
- Windows:「Git for Windows」をインストール。またはWSL内なら
sudo apt install git - Mac:ターミナルで
git --versionと打つと、未導入なら開発ツールのインストールが案内されます - 初期設定:インストール後に名前とメールアドレスを登録します(
git config --global user.name "名前"など)
初心者がつまずくポイント
- コミットの粒度がわからない:「1つの意味のある変更=1コミット」が目安。細かすぎるほうが粗すぎるより安全です
- コマンドが怖い:VS CodeのGit機能やGitHub Desktopなど、画面操作(GUI)でも同じことができます。仕組みを理解していればGUIから入っても問題ありません
- 過去に戻る操作(reset/revert)で混乱:最初は「戻る前に現状をコミットしておく」だけ覚えれば大丈夫。失われて困る状態を作らないことが最優先です
よくある質問
Q. プログラミングをしない人にもGitは役立ちますか?
A. 役立ちます。設定ファイル、原稿、ブログのカスタマイズ記録など「壊したくないテキスト」の管理に最適です。ただし、WordやExcelなどのバイナリファイルは差分が見えないため、恩恵は薄めです。
Q. GitとGitHubは無料ですか?
A. Git自体は完全無料です。GitHubも個人利用の基本機能は無料で、公開・非公開リポジトリの両方を作れます。
Q. チーム開発で必要な「ブランチ」も最初に覚えるべきですか?
A. 1人での利用ならブランチは後回しで大丈夫です。add/commit/logのリズムが身についてから、「試験的な変更を分けて進める道具」として学ぶと、すんなり理解できます。
やり直したいときの、状況別コマンド
Gitで最も困るのが「間違えた。戻したい」という場面です。ところが戻し方は状況によって違い、間違ったコマンドを使うと作業内容が消えます。ここは表として手元に置いておく価値があります。
| やりたいこと | コマンド | 危険度 |
|---|---|---|
| 編集を取り消して、最後のコミットの状態に戻す（1ファイル） | git restore ファイル名 | 編集内容は消える |
| ステージ（add）を取り消す。編集内容は残す | git restore --staged ファイル名 | 安全 |
| 直前のコミットのメッセージを書き直す | git commit --amend | 共有前なら安全 |
| 直前のコミットを取り消す。編集内容は残す | git reset --soft HEAD~1 | 安全 |
| 直前のコミットを取り消し、編集内容も破棄 | git reset --hard HEAD~1 | 復旧が難しい。要注意 |
| 公開済みのコミットを打ち消す | git revert コミットID | 安全。取り消した記録が残る |
| 作業を一時的に棚上げする | git stash / 戻すときは git stash pop | 安全 |
覚え方の原則。まだ誰とも共有していない（pushしていない）なら reset、すでに共有したなら revert。共有済みの履歴をresetで書き換えると、他の人の手元と食い違い、収拾がつかなくなります。1人で使っていても、この使い分けを癖にしておくと安全です。
「消してしまった」ときの最後の砦
git reset --hard をしてしまっても、諦めるのはまだ早い場合があります。Gitは、履歴の移動を別の場所に記録しています。
git reflog と入力してください。これまでHEADがどこを指していたかの一覧が出ます。消してしまったコミットのIDがここにあれば、次のコマンドで戻せます。
git reset --hard そのコミットID
| 状況 | 救えるか |
|---|---|
| コミット済みのものをresetで消した | 救える。reflogに残っている |
| ブランチを間違えて削除した | 救える。reflogから復元できる |
| まだ一度もコミットしていない編集を消した | 救えない。Gitはコミットしたものしか記録していない |
| stashしたものを見失った | 救える。git stash listで一覧を確認 |
ここから導かれる実務上の教訓は1つです。不安な作業をする前には、とりあえずコミットしておく。メッセージが雑でも構いません。コミットさえしてあれば、ほぼ何をしても戻せます。
ブランチを、1人でも使う理由
ブランチはチーム開発の道具だと思われがちですが、1人で使っても効果があります。「本体を壊さずに試せる」からです。
| 場面 | ブランチなし | ブランチあり |
|---|---|---|
| 新機能を試したい | 動いていたコードを直接いじる。失敗すると戻すのが大変 | 別ブランチで試し、駄目なら捨てるだけ |
| 試している途中で緊急の修正が入った | 中途半端な状態が混ざる | 本体ブランチに切り替えて修正し、また戻れる |
| 2つの案を比べたい | 片方ずつしか作れない | 両方を並行して残せる |
最低限の流れは3コマンドです。
| 操作 | コマンド |
|---|---|
| 新しいブランチを作って移動 | git switch -c 名前 |
| 元のブランチに戻る | git switch main |
| 作業したブランチを取り込む | git merge 名前 |
命名は自由ですが、fix-login、try-new-design のように何をしているかが分かる名前にしておくと、数日後の自分が助かります。
公開してはいけないファイルを、確実に除外する
初学者が最も多く起こす事故が、パスワードやAPIキーを含む設定ファイルを、そのまま公開リポジトリに上げてしまうことです。公開されたキーは、自動巡回プログラムに数分で拾われます。
防ぐには、リポジトリの直下に .gitignore というファイルを作り、除外したいものを1行ずつ書きます。
| 書く内容 | 除外されるもの |
|---|---|
.env | 環境変数ファイル。APIキーの定番の置き場所 |
node_modules/ | 依存ライブラリ。再取得できるので上げる必要がない |
*.log | ログファイル。個人情報が含まれることがある |
.DS_Store | macOSが自動生成するファイル |
config.local.* | 個人の設定ファイル |
一度コミットしてしまったファイルは、.gitignoreに書いても消えません。すでに履歴に入っているためです。この場合、まず git rm --cached ファイル名 で追跡対象から外し、さらにそのキー自体を無効化して再発行してください。履歴からファイルを完全に消す作業は難しく、消したつもりでも残っていることがあります。漏れた鍵は、消すのではなく作り直す。これが原則です。
毎日の作業の型を、4行で固定する
コマンドを覚えようとするより、作業の型を決めてしまうほうが定着します。1人開発なら、次の4行を繰り返すだけで運用できます。
| タイミング | コマンド | 意味 |
|---|---|---|
| 作業を始める前 | git pull | 別の端末での変更を取り込む |
| 切りのいいところで | git add . | 変更を記録の対象にする |
| 続けて | git commit -m "何をしたか" | セーブポイントを作る |
| 作業を終えるとき | git push | 手元の記録を共有先へ送る |
コミットの粒度で迷ったら、「ここまでは動く」と言える状態ごとを目安にしてください。1日1回の巨大なコミットは、あとから問題箇所を特定できなくなります。逆に、細かすぎても履歴が読みにくくなります。1つの目的が達成されるたびに1コミット、が基本形です。
この記事で使える無料ツール
- ハッシュ値生成（SHA-256） — ファイルが同一かをハッシュ値で確認する
作ったものを公開するところまでを目標に据えると、学ぶ範囲が定まります。目標の立て方はプログラミング独学の目標の立て方を参照してください。
コミットのハッシュのような一意の識別子を自分で用意したい場面ではUUID・ランダム文字列生成が使えます。ブラウザの暗号用乱数で生成するため、推測されにくい値が得られます。
まとめ
Gitは「変更する→選ぶ(add)→記録する(commit)」のリズムさえ覚えれば、あとは必要に応じて広げていける道具です。ファイル名での版管理から卒業し、履歴という安心を手に入れましょう。プログラミング学習中の方は、作品づくりと並行して習慣にすると就職・案件でも強みになります。