新しいプロジェクトを作るたびに、.gitignoreをなんとなくコピペしていませんか？
- 「
node_modulesをうっかりコミットして、リポジトリが重くなった」 - 「
.envをプッシュしそうになって、冷や汗をかいた」 - 「Macの
.DS_Storeが、気づけば差分に混ざっている」
.gitignoreは、一度しっかりした「型」を持っておくだけで、こうしたトラブルをほとんど先回りで防げます。
今回は、現場でよく使われている.gitignoreのパターンを、そのままコピーして使えるテンプレとしてまとめました。「なぜそれを無視するのか」もあわせて解説します。
- どのプロジェクトでも使える「共通テンプレ」
- Node.js・Python・Goなど、言語別に足すパターン
- OSやエディタのファイルをまとめて防ぐ「グローバル設定」
- よくある失敗と、公開前のチェックリスト
まず考え方：「再現できるもの」と「秘密」は入れない
Gitで管理するのは、プロジェクトの「設計図」にあたるソースコードです。それ以外のファイルは、次の4つに分けると判断しやすくなります。
| 種類 | 例 | 無視する理由 |
|---|---|---|
| 依存ライブラリ | node_modules/、.venv/ | 設定ファイルから何度でも入れ直せる。しかも巨大 |
| ビルド成果物・キャッシュ | dist/、__pycache__/ | ソースコードから自動で作り直せる |
| 秘密情報 | .env、鍵ファイル | リポジトリに入ると漏えいの原因になる |
| 個人の環境ファイル | .DS_Store、エディタの設定 | 他の人には関係なく、差分を汚すだけ |
迷ったときは、「このファイルが消えても、コマンド一つで元に戻せるか？」と自分に聞いてみてください。戻せるなら無視してOK、戻せないならコミットすべきものです（ただし秘密情報は例外で、別の安全な場所で管理します）。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
graph TD
A["プロジェクト内のファイル"] --> B{"秘密情報？"}
B -- "YES" --> F[".gitignoreで無視<br>（別の場所で管理）"]
B -- "NO" --> C{"コマンド一つで<br>作り直せる？"}
C -- "YES" --> F2[".gitignoreで無視"]
C -- "NO" --> D{"自分の環境だけの<br>ファイル？"}
D -- "YES" --> G["グローバル設定で無視"]
D -- "NO" --> E["コミットする"]どのプロジェクトでも使える「共通テンプレ」
まずは、言語に関係なく入れておきたい基本のセットです。新しいリポジトリを作ったら、最初にこれを置いておくと安心です。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
# ===== 秘密情報 =====
.env
.env.*
!.env.example
*.pem
*.key
# ===== ログ・一時ファイル =====
*.log
tmp/
*.tmp
# ===== ビルド成果物 =====
dist/
build/
# ===== テスト・カバレッジ =====
coverage/ポイントは!.env.exampleの行です。!を頭につけると「これは無視しない」という例外になります。本物の.envは入れず、「どんな設定項目が必要か」だけを書いた見本ファイルは共有する、という現場でよく使われる形です。
言語別に足すパターン
共通テンプレに、使っている言語の分だけ足していきます。
Node.js
- 1
- 2
- 3
- 4
- 5
node_modules/
npm-debug.log*
.npm/
.next/
.astro/package-lock.jsonは無視しないのが一般的です。チーム全員が同じバージョンのライブラリを入れるための大事なファイルだからです。
Python
- 1
- 2
- 3
- 4
- 5
- 6
- 7
__pycache__/
*.py[cod]
.venv/
venv/
.pytest_cache/
.mypy_cache/
*.egg-info/仮想環境（.venv/）は、requirements.txtなどがあれば作り直せるので無視します。
Go
- 1
- 2
- 3
- 4
*.exe
*.test
*.out
/bin/Goはビルドすると実行ファイルができるので、それを入れないようにします。go.sumは依存関係の確認に使うので、package-lock.jsonと同じくコミットします。
言語ごとの「無視するもの・残すもの」早見表
| 言語 | 無視するもの | 残すもの（無視しない） |
|---|---|---|
| Node.js | node_modules/、ビルド結果 | package.json、package-lock.json |
| Python | __pycache__/、.venv/ | requirements.txt、pyproject.toml |
| Go | 実行ファイル、テスト用バイナリ | go.mod、go.sum |
自分の環境に合わせたテンプレがほしいときは、GitHubが公開しているgithub/gitignoreリポジトリや、言語名を入れるとテンプレを作ってくれるgitignore.ioも便利です。ただし、中身を読まずに丸ごと使うのではなく、上の表のように「なぜ無視するのか」を確かめてから使うのがおすすめです。
OS・エディタのファイルは「グローバル設定」へ
.DS_Store（Mac）やThumbs.db（Windows）、エディタの設定フォルダは、プロジェクトではなくあなたのパソコンに結びついたファイルです。リポジトリごとに書くより、パソコン全体でまとめて無視するほうが漏れがありません。
まず、ホームディレクトリに~/.gitignore_globalを作ります。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
# macOS
.DS_Store
# Windows
Thumbs.db
# エディタ
.idea/
*.swp次に、Gitに「このファイルを共通の無視リストとして使って、と伝えます。
- 1
git config --global core.excludesFile ~/.gitignore_globalこれで、どのリポジトリでも自動的にこのルールが効きます。
.vscode/は少し注意が必要です。チームで推奨拡張機能などを共有している場合は、丸ごと無視せず、プロジェクトの.gitignoreで個人設定のファイルだけを無視する形にしましょう。 よくある失敗：書いたのに効かない
.gitignoreに書いたのに、なぜかファイルが無視されない。これはほとんどの場合、そのファイルがすでにGitの管理対象になっているのが原因です。
.gitignoreは「まだ管理していないファイル」にしか効きません。すでにコミットしてしまったファイルは、次のコマンドで管理から外します。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
# ファイルは手元に残したまま、Gitの管理からだけ外す
git rm --cached .env
# フォルダの場合は -r をつける
git rm -r --cached node_modules
git commit -m "Stop tracking ignored files"どのルールが効いているかわからないときは、次のコマンドも便利です。
- 1
git check-ignore -v ファイル名どの.gitignoreの何行目のルールで無視されているのかを教えてくれます。
git rm --cachedだけでは履歴に残ります。まずはそのキーやパスワードを無効にして発行し直すことを優先してください。 公開前のチェックリスト
新しいリポジトリを作ったら、最初のプッシュの前に確認しておきましょう。
.envと鍵ファイル） package-lock.json、go.sumなど）を無視していない .env.exampleのような見本ファイルは共有されるようになっている git statusで、余計なファイルが出てこないことを確かめた まとめ
今回は、現場でよく使われる.gitignoreのパターンをテンプレとして紹介しました。
- 判断基準は「作り直せるもの」と「秘密」は入れない
- まず共通テンプレ、そこに言語別のパターンを足す
- OS・エディタのファイルはグローバル設定へ
- 効かないときは
git rm --cachedとgit check-ignore -v
次の一歩として、今作業中のリポジトリでgit status --ignoredを実行してみてください。無視されているファイルの一覧が出るので、この記事のテンプレと見比べると、足りないものがすぐに見つかります。
チームでの.gitignoreのトラブルについては、こちらの記事で詳しく解説しています。
チームのGitが毎日荒れる意外な原因、実は「.gitignore」にあった？