Git入門：設定・概念・使い方を“実務で困らない”まで一気に押さえる

はじめに

すでにGitに関しては記事としてはありふれているのですが、
ちょうどまとめる機会があってせっかくなので記事にもしました。

この記事でわかること

• Gitの基本概念（リポジトリ / コミット / ブランチ / HEAD / インデックス）
• 初学者がまず入れておくべきGit設定（理由つき）
• 1人開発〜チーム開発での基本フロー（PR前提）
• やらかしたときの復旧手段（reflog / reset / stash / revert）
• VS Code / WSL での実務的な使い方（迷いどころを先回り）

対象読者

• Git歴0〜3ヶ月くらい
• なんとなく git add / git commit / git push はできるが、仕組みが腹落ちしていない
• チーム開発（PR）に備えて「事故らない手順」を知りたい

想定環境（コマンドの実行場所）

• macOS / Linux / Windows(WSL) を基本に記載
• Windowsネイティブ（PowerShell）の場合は補足

⚠️ 本記事は git switch / git restore を使います（Git 2.23+）。
もし switch / restore が見つからない場合は、Gitを更新するか、次のように git checkout で読み替えてください。

• 例：git switch main → git checkout main
• 例：git restore <file> → git checkout -- <file>

図1: Gitで「変更」がどこに存在しているか（作業ツリー / インデックス / 履歴 / リモート）を整理。最初にここを押さえると迷子になりにくいです。

Gitの超基本：まず「4つの場所」をイメージする

Gitが難しく感じる最大の理由は、変更がどこにあるのかが見えにくいことです。
まずは以下の4つの場所（層）を覚えるのが近道です。

1. 作業ツリー（Working Tree）
   エディタで編集している、いま見えているファイルたち
2. インデックス（Staging Area / Index）
   次のコミットに入れる変更を「選んで置く場所」
3. ローカル履歴（Commit History）
   git commit で積み上がる履歴（あなたのPCの中）
4. リモート（Remote）
   共有用の履歴（例：GitHubなど）

ここが腹落ちすると、add/commit/push の意味が自然に繋がります。

• git add = 作業ツリー → インデックスへ「載せる」
• git commit = インデックス → ローカル履歴へ「確定」
• git push = ローカル履歴 → リモートへ「共有」

Gitの用語を最短で整理

図2: ブランチは「コミットへのラベル」、HEADは「いま見ている場所」。この関係が分かると、checkout/switchの混乱が減ります。

リポジトリ（repository）

履歴を管理する単位です。フォルダ直下に .git/ が作られます。

コミット（commit）

スナップショット（差分の集合）です。
コミットにはID（ハッシュ）が付きます。

ブランチ（branch）

「特定のコミットを指すラベル」です。
ブランチ自体が分岐しているというより、コミットがグラフ構造になっており、ブランチはその先頭を指します。

HEAD

「自分が今見ているコミット（またはブランチ）」です。
多くの場合、HEADはブランチを指しています（＝ブランチの先頭コミットを見ている）。

マージ（merge）とリベース（rebase）

• merge：2つの履歴を合流させる（マージコミットが増えやすい）
• rebase：履歴を付け替える（きれいになりやすいが、共有ブランチで乱用すると事故る）

まずやる：Gitのインストールと動作確認

インストール（例）

macOS

# Homebrew
brew install git

Ubuntu / Debian（WSL含む）

sudo apt update
sudo apt install -y git

Windows（WSLを使わない場合）

• Git for Windows をインストール（公式インストーラ）
• ただし、チーム開発では WSL + VS Code Remote の方がトラブルが少ないケースも多いです（改行コードやパスなど）

動作確認（成功条件）

git --version

git version x.y.z のように表示されればOKです。

図3: 初学者が迷いやすい設定を「何のために必要か」で整理。

最初に入れるGit設定（コピペ可）

ここでは「迷ったらこれ」で進められる、安全寄りの設定を紹介します。
あとから変更できますが、最初に整えておくとチーム開発で揉めにくいです。

✅ ポイント

• まずは user.name / user.email は必須
• 改行コード（Windows）とエディタ設定（VS Code）を早めに固める
• pull の挙動はチームと揃える（rebase派/merge派）

1) 名前・メール（必須）

git config --global user.name "YOUR_NAME"
git config --global user.email "[e-mail]"

確認

git config --global --list

2) デフォルトブランチ名（main推奨）

git config --global init.defaultBranch main

✅ 補足：この設定は「これから git init する新規リポジトリ」に効きます。
すでに master で作られたリポジトリは、必要に応じて git branch -M main でブランチ名を変更してください。

3) エディタをVS Codeに（使う人向け）

git config --global core.editor "code --wait"

--wait は「コミットメッセージ入力が終わるまでGitが待つ」ために必要です。

✅ 補足：code コマンドが見つからない場合は、VS Codeのコマンドパレットで Shell Command: Install 'code' command in PATH を実行してPATHに追加してください（または別エディタを指定します）。

4) pull時の方針（チームで統一推奨）

ここが初学者の事故ポイントです。
よく分からないうちは pull.rebase=true にして、履歴を直線に寄せるのが扱いやすいことが多いです。

git config --global pull.rebase true
git config --global rebase.autoStash true

• pull.rebase=true：git pull を rebase で行う（履歴が散らかりにくい）
• rebase.autoStash=true：作業中の変更があっても一時退避してrebaseして戻す

⚠️ rebase は履歴を書き換える操作です。main などの共有ブランチで安易に使うと事故ります。
「自分だけが触るfeatureブランチ」で push 済みコミットをrebaseした場合は、通常 git push --force-with-lease が必要になります（分からないうちは避けるのが安全です）。

注意：チームが「merge派（pullはmerge）」の場合、ここは合わせてください。
その場合は git config --global pull.rebase false が無難です。

5) 追跡枝の掃除（運用で効く）

git config --global fetch.prune true

消されたリモートブランチを fetch 時に掃除します。ブランチ一覧が汚れにくいです。

6) 便利なエイリアス（初学者に効く）

git config --global alias.st "status -sb"
git config --global alias.lg "log --oneline --decorate --graph --all"
git config --global alias.unstage "restore --staged"
git config --global alias.last "log -1 --stat"

✅ 補足：git unstage はここで設定したエイリアスです（標準コマンドではありません）。
エイリアスを設定していない環境では git restore --staged <file> を使ってください。

使い方例：

git st
git lg

（重要）Windows/WSLの改行コード設定

「なぜか差分が全部出る」「CIで落ちる」原因の上位が改行コードです。

推奨の考え方

• WSLで作業するなら：Linuxとして扱う（CRLF変換を極力しない）
• Windowsネイティブだけで作業するなら：変換ルールを明示する

WSLで作業する場合（推奨）

git config --global core.autocrlf input

• input：コミット時にCRLF→LFへ正規化、チェックアウト時はLFのまま

Windowsネイティブの場合（目安）

git config --global core.autocrlf true

Tips：チームでOS混在なら .gitattributes をリポジトリに入れて統一するのが強いです（後述）。

図4: コマンドごとに、作業ツリー/インデックス/履歴/リモートのどこが動くかを対応させると理解が一気に進みます。

日常でよく使うGitコマンド（最短で実務に効く）

状態を見る（最優先で覚える）

git status

差分を見る

git diff           # 作業ツリーの差分
git diff --staged  # ステージング済みの差分

追加してコミット

git add .
git commit -m "feat: add login page"

⚠️ git add . は便利ですが、意図しないファイルまで混ざりがちです（例：生成物・ログ・.env）。
慣れるまでは git status で確認しつつ、git add <file> で個別に追加するのが安全です。

直前のコミットに含める（コミットメッセージ修正含む）

git commit --amend

注意：すでにpushしたコミットを --amend で書き換えるのは原則NG（共有履歴が壊れます）

取り消し（復旧含めて整理）

• ステージングを外す：

git restore --staged <file>
# またはエイリアス
git unstage <file>

• 作業ツリーの変更を捨てる（危険）：

git restore <file>

「捨てた…」の復旧は git reflog が頼りです（後述）。

ブランチ運用：初心者がまず覚える“安全な型”

図5: mainは安定、作業はfeatureブランチ、PRでレビュー→マージ。迷ったらこの型。

推奨フロー（PR前提）

1. main を最新にする
2. feature/xxx を作る
3. 小さくコミットを積む
4. pushしてPR（Pull Request）を作る
5. レビュー→マージ
6. ブランチ削除

コマンド例（コピペ可）

# 1) mainへ移動して最新化
git switch main
git pull

# 2) ブランチ作成
git switch -c feature/add-login

# 3) 作業→add→commit
git add .
git commit -m "feat: add login page"

# 4) リモートへpush（初回は-u）
git push -u origin feature/add-login

リモート接続（HTTPS/SSH）：どっちがいい？

初学者が詰まりやすいので、整理します。

• HTTPS：始めやすい。トークン/資格情報管理が必要（Credential Manager等）
• SSH：一度設定すると快適。鍵管理が必要

HTTPSでclone（まずはこれでOK）

git clone https://example.com/your/repo.git

SSHでclone（慣れたら）

git clone [e-mail]:your/repo.git

“事故りにくい”コンフリクト解消の手順

図6: 何が起きているかを手順化すると、焦らず解消できます。

コンフリクトとは

同じ箇所が別々に変更され、Gitが自動で統合できない状態です。

解消手順（基本）

まずは「状態確認 → 手で直す → add → 完了」の順で落ち着いて進めます。

# 1) コンフリクトが起きたら状態確認
git status

# 2) コンフリクトファイルを開いて手で修正（<<<<<<< / ======= / >>>>>>> を解消）
# 3) 修正したらステージング
git add <conflicted_file>

merge の場合（git merge / git pull が merge になる設定）

# 4) マージを完了（メッセージはエディタで確認して保存）
git commit

rebase の場合（git pull --rebase / pull.rebase=true）

# 4) rebase を続行
git rebase --continue

困ったら中断：mergeなら git merge --abort、rebaseなら git rebase --abort。

VS Codeでの解消（おすすめ）

VS Codeはコンフリクト箇所に「現在/受け入れ/両方」ボタンが出るので、初学者にやさしいです。

“やらかした”ときの復旧：reflogが最強

図7: 「消えたコミット/ブランチ」を救う最後の砦がreflog。Git初心者ほど早めに知っておくと安心です。

よくある事故

• reset したらコミットが消えた
• ブランチを消した
• restore で編集内容を消した

reflogで探す

git reflog

出てきた履歴から戻したい地点（例：HEAD@{2} やコミットID）を見つけます。

✅ 補足：reflog はローカル専用の履歴です（通常リモートには送られません）。
また一定期間で消えることがあるので、気づいたら早めに救出するのが安全です。

その地点に戻す（例）

# 例：コミットIDに戻す（作業ツリーも含めて戻るので注意）
git reset --hard <commit_id>

注意：--hard は作業ツリーも巻き戻すので、必要なら事前に git stash を使うと安全です。

実務で効く“守りの設定”：.gitignore / .gitattributes / secrets対策

1) .gitignore（追跡しないファイルを定義）

例：Node.js + Python混在の最小

# Node
node_modules/
dist/
build/
.next/

# Python
.venv/
__pycache__/
*.pyc

# Env / secrets
.env
.env.*
*.key

# OS
.DS_Store

Tips：.env をコミットしてしまったら、消しても履歴に残ります。
事故ったら「履歴から消す」対応（filter-repo等）が必要になり、重いです。最初から防ぐのが一番です。

2) .gitattributes（改行コードを統一）

OS混在チームで強いです。

* text=auto eol=lf
*.bat text eol=crlf

3) 最低限のsecretsチェック（pre-commit）

完全ではありませんが「うっかり防止」になります。

mkdir -p .git/hooks
cat > .git/hooks/pre-commit <<'EOF'
#!/bin/sh
set -eu

# ざっくり危険ワード（必要に応じて増やす）
PATTERNS="AWS_SECRET_ACCESS_KEY|BEGIN PRIVATE KEY|xoxb-|ghp_"

if git diff --cached -U0 | grep -E "$PATTERNS" >/dev/null 2>&1; then
  echo "❌ Secretっぽい文字列がステージングに含まれています。コミットを中断します。"
  echo "   対象を確認して除外・無効化してください。"
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

✅ 補足：.git/hooks はリポジトリに含まれないため、チームには自動で共有されません。
チームで揃えたい場合は pre-commit / lefthook などの仕組みを使うのが一般的です。

VS Code × Git：初学者が最初に見る場所

• 左メニュー「ソース管理」
  • 変更ファイル、ステージング、コミット、プッシュがGUIで見える
• 差分ビュー
  • どこがどう変わったかが直感的
• 追加推奨拡張（任意）
  • Gitの履歴・ blame を見やすくする拡張（チームによる）

Tips：WSL利用時は「WSL側でリポジトリを置いて、WSLからVS Codeを起動」が安定しやすいです。
Windows側パスとWSL側パスを跨ぐと、ファイル監視やパーミッションでハマることがあります。

トラブルシュート（よくあるエラーと対処）

fatal: not a git repository

いまいるディレクトリがGit管理下ではありません。

• .git があるディレクトリで実行する
• 新規なら git init

error: failed to push some refs

リモート側のブランチが先に進んでいて、あなたのローカルの履歴と食い違っています。

• 初回pushで upstream（追跡先）をまだ設定していない場合：

  git push -u origin <branch>
  

• upstream がある場合：まず取り込んでから再push（チーム方針に合わせる）

  git pull --rebase  # merge派なら `git pull`（--rebase を外す）
  git push
  

detached HEAD と出た

ブランチではなくコミットを直接見ています。

• ブランチに戻す（例）

git switch main

改行コードで差分が大量に出る

• .gitattributes で統一
• core.autocrlf をチームで揃える

【演習】失敗リカバリーを体験する

ここまで読んで概念は分かったけど、「本番で失敗するのが怖い」という方へ。
安全な練習環境で、わざと失敗→復旧を体験してみましょう。一度やっておくと、実務での心理的ハードルが下がります。

図8: 演習全体像。まずは1→2でreflogの安心感を得て、余裕があれば3→4へ進むのがおすすめです。

💡 この演習の所要時間：全体で30〜40分程度

準備：練習用リポジトリを作る（5分）

使い捨てのリポジトリをローカルに作ります。本番リポジトリでは絶対にやらないでください。

# 作業用ディレクトリを作成
mkdir git-recovery-practice && cd git-recovery-practice

# Git初期化
git init

# 初期ファイルを作成してコミット
echo "# Recovery Practice" > README.md
echo "console.log('hello');" > app.js
git add .
git commit -m "initial commit"

# ブランチ名を確認（master なら main に変更）
git branch
# もし "* master" と表示されたら main に変更
# git branch -M main

成功条件: * main と表示されればOK（* master の場合は上の git branch -M main を実行して main に揃えましょう）

オプション：演習3（push後のリカバリー）を試したい場合は、GitHubにリモートリポジトリを作成して git remote add origin <URL> & git push -u origin main しておいてください。

演習1: mainに直commitしてしまった → 取り消す（10分）

状況: 本来 feature ブランチで作業すべきだったのに、main で直接コミットしてしまった。

Step 1: 失敗を再現する

# mainにいることを確認
git branch

# mainで直接編集してコミット（本来やってはいけない）
echo "// new feature" >> app.js
git add .
git commit -m "feat: add new feature"

# 履歴を確認（mainに新しいコミットがある）
git log --oneline

Step 2: リカバリーする

# 直前のコミットを取り消す（変更内容はインデックスに残す）
git reset --soft HEAD~1

# 状態を確認（変更がステージングに戻っている）
git status

# featureブランチを作成して移動
git switch -c feature/new-feature

# 改めてコミット
git commit -m "feat: add new feature"

# 履歴を確認（featureブランチにコミットがある）
git log --oneline
git switch main
git log --oneline

成功条件: main のログには "initial commit" だけ、feature/new-feature に "feat: add new feature" があればOK

演習2: 間違えたファイルをcommit → 消す → reflogで復旧（15分）

状況: .env ファイル（機密情報）をうっかりコミットしてしまった。消したい。でも「やっぱり必要だった」となったときの復旧も体験する。

⚠️ 実務で .env や鍵をコミット（特にpush）してしまった場合は、履歴操作より先に 秘密情報を失効・再発行（ローテーション） してください。
履歴から消しても、すでに漏洩している可能性はゼロになりません。

Step 1: 失敗を再現する

# mainに戻る
git switch main

# 機密ファイルを作成してコミット（本来やってはいけない）
echo "SECRET_KEY=abc123" > .env
git add .
git commit -m "add config"

# 履歴を確認
git log --oneline

Step 2: コミットを取り消す

# 直前のコミットを完全に取り消す（変更内容も消える）
git reset --hard HEAD~1

# 状態を確認（.envが消えている）
ls -la
git log --oneline

Step 3: .gitignoreを追加して再発防止

# .gitignoreを作成
echo ".env" > .gitignore
git add .gitignore
git commit -m "add gitignore"

Step 4: 「やっぱり.envの内容が必要だった」→ reflogで復旧

# reflogで履歴を確認
git reflog

# "add config" のコミットIDを探す（例：abc1234）
# そのコミットから .env の中身を取り出して復元（.gitignore により追跡されない）
git show <コミットID>:.env > .env
cat .env

# 使い終わったら削除（残してローカル実行に使ってもOK。ただし絶対にcommit/pushしない）
rm .env

成功条件:

• git log --oneline で "add config" が消えている
• git reflog で "add config" の履歴が見える
• reflogからファイル内容を復旧できた

🎉 これがreflogの力です。 reset --hard で「完全に消した」つもりでも、reflogには履歴が残っています。

演習3: push後にミスに気づいた → revertで打ち消す（10分）

状況: すでにリモートにpushしてしまった。履歴を書き換えると他の人に影響が出るので、revert で「打ち消しコミット」を作る。

⚠️ この演習はリモートリポジトリが必要です。準備していない場合はスキップしてOKです。

Step 1: 失敗を再現する

# バグ入りのコードをコミット＆プッシュ
echo "console.log('bug!');" >> app.js
git add .
git commit -m "feat: add buggy code"
git push

Step 2: revertでリカバリーする

# 直前のコミットを打ち消すコミットを作成
git revert HEAD --no-edit

# 履歴を確認（revertコミットが追加されている）
git log --oneline

# プッシュ
git push

成功条件: git log に Revert "feat: add buggy code" のようなコミットが増えていればOK

💡 revert は履歴を書き換えないので、チーム開発でも安全に使えます。

演習4: コンフリクトを起こして解決する（10分）

状況: 同じファイルの同じ箇所を2つのブランチで編集し、マージ時にコンフリクトが発生。

Step 1: コンフリクトを意図的に発生させる

# mainで編集
git switch main
echo "console.log('main version');" > app.js
git add .
git commit -m "update app.js in main"

# 別ブランチを作成して同じ箇所を編集
git switch -c feature/conflict-test HEAD~1
echo "console.log('feature version');" > app.js
git add .
git commit -m "update app.js in feature"

# mainにマージしようとする → コンフリクト発生
git switch main
git merge feature/conflict-test

Step 2: コンフリクトを解決する

# 状態を確認
git status

# ファイルを開いてコンフリクトマーカーを確認
cat app.js
# <<<<<<< HEAD
# console.log('main version');
# =======
# console.log('feature version');
# >>>>>>> feature/conflict-test

# 手動で解決（どちらかを選ぶ or 両方残す）
echo "console.log('merged version');" > app.js

# 解決したらステージング＆コミット
git add app.js
git commit -m "resolve conflict"

# 履歴を確認
git log --oneline --graph

成功条件: マージコミットが作成され、app.js の内容が意図通りになっていればOK

💡 VS Codeを使っている場合は、コンフリクト箇所に「Accept Current / Accept Incoming / Accept Both」ボタンが表示されるので、そちらを使うと楽です。詳細は「"事故りにくい"コンフリクト解消の手順」を参照してください。

演習のまとめ

お疲れさまでした。ここまでで体験したリカバリー手法を整理します。

状況	コマンド	特徴
コミット前に戻したい	git restore --staged <file>	ステージングを外す
コミットを取り消したい（変更は残す）	git reset --soft HEAD~1	インデックスに戻る
コミットを完全に取り消したい	git reset --hard HEAD~1	変更も消える
push後に取り消したい	git revert HEAD	打ち消しコミットを作る
「消しすぎた」を復旧したい	git reflog → git show <id>:<file>（中身確認） / git restore --source <id> -- <file>（復元）	履歴から救出

🎯 この演習で得てほしい感覚:
「Gitは失敗しても大丈夫。reflogがある限り、大抵のことは戻せる。」

まとめ（最短で実務に効く要点）

• まずは「作業ツリー / インデックス / 履歴 / リモート」の4層を理解する
• 初期設定は user.name/email と pull 方針、改行コードが重要
• ブランチ運用は「main安定・feature作業・PRでレビュー」の型が事故りにくい
• 困ったら git status、やらかしたら git reflog
• .gitignore と secrets対策は最初に仕込むと後悔しにくい

参考（次に読むと良い観点）

• チームのブランチ戦略（Git Flow / GitHub Flow）
• コミットメッセージ規約（Conventional Commits）
• リリース運用（タグ / リリースノート / CI）