何を無視し、何をコミットするか

よい .gitignore は長さではなく基準で判断する。基準は 1 つである。リポジトリを新たに clone した人が、ソースと設定だけで同じ結果を作り直せるか。 作り直せるものは無視し、作り直せないもの、あるいは結果を固定するものはコミットする。

無視するもの

種類	例	理由
ビルド成果物	`dist/`, `build/`, `target/`, `.o`, `.class`	ソースから作り直す
依存関係のインストール結果	`node_modules/`, `vendor/`(PHP), `.venv/`	マニフェストと lockfile で再インストールする
キャッシュ・ログ	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	実行するたびに変わる
ローカル環境・秘密	`.env`, `.pem`, `local.properties`, `.tfstate`	人や環境ごとに異なる、または流出してはならない
個人のツール状態	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	プロジェクトと無関係である (グローバル gitignore を推奨)

lockfile: package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl。全員が同じバージョンでインストールできるようにする。テンプレートの中には Angular のように lockfile を無視するものもあるので、結果を確認する。
サンプル設定: .env.example, config.example.yml。どんな値が必要かを伝えつつ、実際の秘密は含めない。
ビルドツールのラッパー: gradlew と gradle/wrapper/、mvnw。Java テンプレートの *.jar によってラッパー jar が無視されていないか確認する。
チームで合意したエディター設定: .editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/。フォーマットとリントの設定を共有するとレビューが楽になる。

.gitignore はルートにしか置けないわけではない。下位ディレクトリの .gitignore はそのディレクトリを基準に動作し、上位のファイルより優先される。モノレポでパッケージごとに必要なルールが異なるなら、パッケージのフォルダーに別途置く方が読みやすい。

repo/
├── .gitignore          # 共通: .DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

git はファイルだけを追跡し、空ディレクトリは保存しない。ログフォルダーのようにフォルダーは必要だが中身は無視したい場合は、フォルダー内に目印のファイルを置き、否定ルールで残す。

/log/*
!/log/.keep

.keep や .gitkeep という名前は git の公式機能ではなく、慣例にすぎない。どんな名前でも動作する。別の方法として、そのフォルダー内に次の内容の .gitignore を置けば、自分自身だけを残して残りを無視する。

*
!.gitignore

言語・フレームワーク 1〜2 個 + OS + エディターの組み合わせが一般的である。OS・エディターのルールをグローバルに置いているなら省略してもよい。
順序を確認する。 否定ルールを含むテンプレート(Gradle、VisualStudioCode)は、広いルールを持つテンプレート(Java、Kotlin)より後ろに置く。
重複除去は意味を守る方式で。 同じルールが繰り返されても動作は同じだが、読みにくくなる。このサイトのジェネレーターは、間に否定ルールがない場合にのみ重複を削除する。
セクションコメントを残す。 数か月後に、どのルールがどこから来たのかわかってこそ安全に削除できる。
テストする。 git ls-files で取り出した実際のパスをパターンテストに入れ、意図しないファイル(例: Python テンプレートの lib/ に一致したフロントエンドのコード)が無視されていないか確認する。

*.json のように広すぎるルールは設定ファイルまで飲み込む。できるだけパスを絞り(/dist/)、ディレクトリには末尾にスラッシュを付けて同名のファイルと区別する。ルールの上に 1 行のコメントで理由を書いておけば、次の人が削除してよいか判断できる。