.gitignoreの書き方｜除外すべきファイルと基本ルール
.gitignore を使うと、コミットしたくないファイルを Git の追跡対象から外せます。ログ、ビルド成果物、OS が自動生成するファイル、API キーを含む設定ファイルなどを除外したい場面で使います。
実務では「とりあえず書く」より、何を共有し、何を各自の手元だけに残すかを決めてから書くのが重要です。ここを曖昧にすると、不要ファイルが混ざったり、逆に必要な設定まで消えたりします。
- 先に結論:
.gitignoreは「まだ Git に追跡されていないファイル」を除外する設定 - よく除外するもの: ログ、キャッシュ、ビルド成果物、一時ファイル、秘密情報を含む
.env - 注意点: すでにコミット済みのファイルは、
.gitignoreを追加しただけでは消えない - 実務のコツ: プロジェクト共通の除外と、個人環境だけの除外を分けて考える
.gitignore でできることと前提
.gitignore は、Git が新しく見つけたファイルを「無視する」ための仕組みです。対象は主に次の 3 つです。
- 自動生成されるファイルを混ぜない
- ローカル環境だけで使うファイルを共有しない
- 誤って秘密情報をコミットする事故を減らす
一方で、次の点は先に押さえておく必要があります。
.gitignoreは削除ツールではない- 追跡済みファイルにはそのまま効かない
- 何でも除外すればよいわけではなく、チームで必要な設定は残す
ここがポイント:
.gitignoreは「不要ファイルを隠す設定」ではなく、「追跡対象を整理するルール」です。
基本の書き方
まずは最小の例です。
# ログファイル
*.log
# Python のキャッシュ
__pycache__/
*.pyc
# 環境変数ファイル
.env
# macOS の不要ファイル
.DS_Store
各行の意味はシンプルです。
*.log: 拡張子が.logのファイルを無視__pycache__/: その名前のディレクトリを無視.env: 特定のファイル名を無視#: コメント
よく使う記号
書き方でつまずきやすいのが、パターンの意味です。
*: 任意の文字列に一致/: ディレクトリ区切り、またはディレクトリ指定に使う!: いったん無視したものを再度含める
例をまとめるとこうなります。
# すべての log を除外
*.log
# build ディレクトリだけ除外
build/
# docs 配下の tmp ディレクトリを除外
docs/tmp/
# markdown は残す
*.md
# いったん全部の txt を除外して、一部だけ含める
*.txt
!important.txt
配置場所
通常は、リポジトリのルートに .gitignore を置きます。
my-project/
├─ .gitignore
├─ src/
├─ tests/
└─ README.md
この位置に置くと、そのリポジトリ全体に対してルールが効きます。
除外すべきファイルの定番
ここが実務で最も重要です。.gitignore は文法より、何を除外するかの判断で差が出ます。
1. ビルド成果物とキャッシュ
ソースコードから毎回生成できるものは、基本的に Git に入れません。
dist/build/target/.cache/__pycache__/node_modules/（プロジェクト方針によるが通常は除外）
理由は明確です。
- 容量が大きくなりやすい
- 差分が読みにくい
- 環境ごとに中身が変わる
- 再生成できるため Git で管理する意味が薄い
2. ログと一時ファイル
作業中に増えるだけで、共有価値が低いファイルです。
*.logtmp/temp/*.tmp*.swp
エラー調査用ログを残したい場合でも、通常は Git 管理ではなく保存先を分けます。
3. OS やエディタが作るファイル
チーム開発では地味に混ざりやすい部分です。
.DS_Store
Thumbs.db
.vscode/
.idea/
ただし、.vscode/ や .idea/ は一括除外でよいとは限りません。共有したい設定があるなら、全部消すより必要ファイルだけ選ぶほうが安全です。
4. 秘密情報を含むファイル
.env、認証情報、秘密鍵は最優先で見直すべき対象です。
.env
.env.local
*.pem
*.key
secrets.json
API キーやパスワードを含む可能性があるなら、まず Git に入れない設計にします。すでに公開リポジトリへ入ってしまった場合は、.gitignore の追加だけでは不十分です。鍵の無効化や再発行も必要になります。
サンプル: 開発環境ごとの .gitignore
Node.js プロジェクトの例
node_modules/
dist/
coverage/
.env
npm-debug.log*
.DS_Store
この構成なら、依存パッケージ、ビルド成果物、テストカバレッジ、ローカル環境変数を除外できます。
Python プロジェクトの例
__pycache__/
*.py[cod]
.venv/
.env
.pytest_cache/
dist/
build/
Python では仮想環境ディレクトリも除外対象になりやすいです。共有すべきなのは環境本体ではなく、通常は requirements.txt や pyproject.toml のような依存定義です。
汎用的な最小例
どの言語でも使いやすい形なら、まずは次のように始められます。
# OS
.DS_Store
Thumbs.db
# Logs
*.log
# Temp
tmp/
temp/
*.tmp
# Secrets
.env
.env.*
# Editor
.vscode/
.idea/
入力例と結果のイメージ
たとえば次のような構成のプロジェクトがあるとします。
project/
├─ .gitignore
├─ app.py
├─ .env
├─ error.log
├─ __pycache__/
│ └─ app.cpython-312.pyc
└─ README.md
.gitignore が以下なら、
.env
*.log
__pycache__/
Git が通常追跡するのは主に次のファイルです。
app.pyREADME.md.gitignore
逆に無視されるのは次のものです。
.enverror.log__pycache__/配下のファイル
このように、「共有すべきソースだけを残す」状態を作るのが .gitignore の役目です。
よくある失敗と対処
すでに追跡済みのファイルが無視されない
最も多い失敗です。.gitignore を追加しても、過去に git add したファイルは追跡されたままです。
対処は、インデックスから外して再評価させます。
git rm --cached .env
ディレクトリごと外すなら、たとえば次の形です。
git rm -r --cached __pycache__
そのあとでコミットします。
git commit -m "Stop tracking ignored files"
必要なファイルまで除外してしまう
たとえば *.json をまとめて無視すると、設定ファイルやサンプルデータまで消えることがあります。
NG 例:
*.json
改善例:
secrets.json
local-settings.json
広すぎるパターンは事故の元です。まずは対象を狭く書くほうが安全です。
ディレクトリ配下の一部だけ残したい
! を使えば例外を作れます。
logs/
!logs/.gitkeep
この書き方なら、logs/ は基本的に無視しつつ、空ディレクトリ維持用の .gitkeep だけは残せます。
実務での使いどころ
.gitignore は個人開発より、複数人開発で効果が大きく出ます。
レビューが読みやすくなる
不要ファイルが差分に混ざらないので、レビュー対象がコードや設定変更に集中します。ビルド成果物まで毎回出てくる状態だと、レビュー精度が落ちやすくなります。
コンフリクトが減る
環境依存ファイルやローカル設定を Git 管理から外すと、開発者ごとの差分衝突が減ります。とくに IDE 設定や一時ログは、その効果が大きい部分です。
情報漏えいリスクを下げやすい
秘密情報を含むファイルを最初から除外しておけば、誤コミットの確率を下げられます。もちろん 100% 防げるわけではないので、レビューやシークレットスキャンと併用するのが実務向きです。
代替手段と使い分け
.gitignore だけで足りない場面もあります。
個人だけの除外は .git/info/exclude
自分の環境でだけ無視したいファイルなら、リポジトリ共有の .gitignore ではなく .git/info/exclude を使う方法があります。
向いている場面は次のとおりです。
- 自分だけのメモファイル
- 一時的な検証ファイル
- チーム全体には共有したくないローカル設定
全リポジトリ共通ならグローバル ignore
OS の不要ファイルやエディタの一時ファイルのように、毎回同じものを除外したいならグローバル設定も便利です。
たとえば Git のグローバル ignore を設定すると、各リポジトリに同じ記述を繰り返さずに済みます。
迷ったときのチェックリスト
.gitignore を書く前に、次の順で確認すると失敗しにくくなります。
- そのファイルはソースなのか、生成物なのか
- 他の開発者にも必要か
- 環境ごとに変わるか
- 秘密情報を含むか
- すでに Git で追跡されていないか
この 5 点で判断すると、除外すべきかどうかをかなり整理できます。
まず押さえたい基本ルール
最後に、初心者が最初に覚えるべきルールを絞ると次の 4 つです。
- 再生成できるものは基本的に除外する
- 秘密情報を含むファイルは最優先で除外する
- 広すぎるパターンを書かない
- 追跡済みファイルには別途
git rm --cachedが必要
.gitignore は短いファイルですが、プロジェクトの運用をかなり左右します。書き方そのものより、何を共有し、何を共有しないかの線引きを早めに決めることが、後から効いてきます。
次に見直すべきなのは、手元のリポジトリで *.log や .env だけを足すことではありません。いま追跡されている不要ファイルが残っていないかです。そこを掃除してから .gitignore を整えると、リポジトリの状態が一気に安定します。