最近、オープンにできないプロジェクトやObsidianのデータなど、ローカル環境でバージョン管理したいというケースが増えてきたため、ローカル環境でのGitの使い方をまとめました。
目次
この記事のねらい（コンテキスト＆前提）
- ネット接続やGitHub不要で、PC内だけでGitを使って履歴管理する方法を解説。
- Windows／macOS／Linux 共通。ターミナル（またはGit Bash）での操作を前提。
- すでにGitをインストール済みであることを想定。
クイックスタート（最短3分）
# 0) 初回のみ：グローバル設定（PC全体）
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
# 初期ブランチ名をmainに（推奨）
git config --global init.defaultBranch main
# 1) プロジェクトをGit管理下に\ nmkdir my-project && cd my-project
git init
# 2) 除外ルール（例）
printf "__pycache__/\n*.log\n.DS_Store\n.vscode/\n" > .gitignore
# 3) 初回コミット
echo "# My Project" > README.md
git add .
git commit -m "Initial commit"
これで“ローカル完結”の履歴管理がスタート。以降は**編集 →
git add→git commit**のサイクルだけでOK。
なぜ“ローカルGitだけ”で十分なのか
- Gitは分散型。履歴（ブランチ・タグ・差分）は**プロジェクト直下の
.git/**に保存される。 - 共有・公開をしないなら
git pushは不要（そもそもリモート未設定）。 - 単一PC運用ならコミットだけで履歴が積み上がり、過去版へのロールバックも可能。
基本ワークフロー（編集→確認→記録）
# 変更状況を確認
git status
# 差分の確認（Markdownは語単位diffが見やすい）
git diff --word-diff
# 反映したい変更をステージ
git add <file> ... # まとめてなら: git add .
# 意味単位でコミット（要約＋理由を意識）
git commit -m "Fix: typos in article; add table of contents"
ポイント
- コミットは小さく・意味単位で。後から履歴をたどる生産性が上がる。
- Markdownは
--word-diffで可読性UP。
ブランチ運用（安全な試行のために）
# 作業ブランチを作成して切替
git switch -c feature/refresh-docs
# ...編集・コミット...
# mainへ統合
git switch main
git merge feature/refresh-docs
コツ：試行錯誤や大規模リライトは別ブランチで。問題なければmainへ統合。
タグで“スナップショット”を残す
# リリースや公開前の目印に
git tag v1.0.0
# 一覧
git tag
失敗からの“安全な戻し方”
# 作業ツリーの変更を取り消し（未ステージ）
git restore <file>
# ステージから外す
git restore --staged <file>
# 過去コミットを打ち消す専用コミットを作る（公開履歴に安全）
git revert <commit-hash>
revertは“履歴を壊さずに”取り消せる安全策。reset（履歴書き換え）はローカル専用・上級者向け。
.gitignore の最小例（使い回しOK）
# OS一時ファイル
.DS_Store
Thumbs.db
# ログ/キャッシュ
*.log
__pycache__/
*.pyc
# エディタ/IDE
.vscode/
.idea/
ヒント：言語・IDEごとのテンプレを追加して“ゴミのコミット”を防ぐ。
よくある質問（FAQ）
Q1. ローカル運用で “ は必要？
A. 不要です。pushはリモートと同期するためのコマンド。ローカルだけならcommitで完結します。
**Q2. **“で“master”が初期ブランチと出た
A. git config --global init.defaultBranch main を一度設定すれば、以後はmainで始まります。既存は git branch -m master main で変更可能。
Q3. 既存フォルダを途中からGit管理したい
A. そのディレクトリでgit init→.gitignore整備→git add→git commit。余計な生成物を先に.gitignoreへ。
Q4. バイナリや巨大ファイルは？
A. なるべくコミットしない。必要なら後述の“拡張”を検討。
ローカル“だけどリモートっぽく”バックアップする（任意）
別ドライブ／NASにbareリポジトリを作り、そこへ
pushすると“バックアップ兼同期ポイント”にできる。
# バックアップ側（例：Dドライブ）
cd /d
mkdir article-backup.git && cd article-backup.git
git init --bare
# 開発側（元プロジェクト）
cd /c/work/article
git remote add backup /d/article-backup.git
# 初回のみ、mainを送る
git push -u backup main
# 以後、節目でバックアップ
git push backup main
効果：PCの障害時に別媒体から復旧できる。複数PCから同一バックアップ先を使うことも可能。
トラブルシュート早見表
| 症状 | 原因/確認 | 解決策 |
|---|---|---|
fatal: not a git repository | .gitが無い/階層を間違えた | ルートでgit init、または正しいディレクトリへ移動 |
nothing to commit | ステージや変更が無い | git statusで確認→git add→git commit |
.gitignoreが効かない | 既に追跡済み | 一度追跡解除：git rm -r --cached <path>→再コミット |
初期ブランチがmaster | 既定がmainでない | git config --global init.defaultBranch main、既存はgit branch -m master main |
| 差分が読みにくい | Markdownの特性 | git diff --word-diff を活用 |
運用Tips（生産性アップ）
- コミットメッセージ：
<type>: <summary>＋理由で残す（例：Fix: broken links; explain 301 redirects）。 - 部分追加：
git add -pで変更を塊ごとに選択してコミット粒度を整える。 - 履歴可視化：
git log --oneline --graph --decorateでブランチ構造を一目で把握。 - テンプレ整備：プロジェクトの雛形（README、.gitignore、ライセンス）を用意して初動を高速化。
まとめ
- ローカル完結のGit運用はコミットだけで成立し、軽量・高速・安全。
- 最低限のセットアップ（
user.name/user.email、init.defaultBranch、.gitignore）で快適に運用開始。 - 将来の拡張（bareバックアップ、複数端末同期）も段階的に追加可能。
コメント