.gitignoreには最初に何を書けばいい？

学生の個人開発なら .env、node_modules/、.venv/、__pycache__/、.DS_Store の5行を迷わず入れる。.vscode/ は個人開発なら無視、チーム開発なら中身を見て決める。言語が増えたらGitHub公式のgithub/gitignoreテンプレで足せばいい。

.gitignoreに書いたのに無視されないのはなぜ？

すでにコミットして追跡が始まっているファイルは、.gitignoreに書き足しただけでは外れない。git rm --cached ファイル名で追跡から外してからコミットする。--cached付きなら手元のファイルは消えない。

.envを公開リポジトリに上げてしまったらどうする？

追跡を外して消しても履歴には残るし、拾われた時点で手遅れなので、中のAPIキーやトークンを発行元で再発行（ローテーション）する。消して終わりにしないのが一番大事。

.gitignoreの書き方｜最初に入れる6行と、上げてしまった時のgit rm --cached

GitHubにリポジトリを上げたら node_modules が丸ごと入ってて、pushに何分もかかった。あるいは .env をうっかりステージしかけて手が止まった。

GitHubを使い始めた頃、だいたいみんなここを通る。僕も通った。

結論から言うと、.gitignoreは最初に6行書いておけばほぼ事故らない。全部覚える必要はなくて、仕組みと「絶対に上げちゃいけないもの」だけ押さえれば十分だ。

目次 / INDEX

結論: 学生の開発でまず入れるのはこの6行

新しいリポジトリを作ったら、直下に .gitignore という名前のファイルを作って、これを貼る。

.env
node_modules/
.venv/
__pycache__/
.DS_Store
.vscode/

各行が何を防ぐかはこの通り。

行	防げること
`.env`	APIキーやトークンの流出。一番大事
`node_modules/`	Nodeの依存パッケージ。巨大でリポジトリが重くなる
`.venv/`	Pythonの仮想環境。環境ごと上げても他人は使えない
`__pycache__/`	Pythonが勝手に作るキャッシュ。ゴミ
`.DS_Store`	Macが勝手に作る隠しファイル。ゴミ
`.vscode/`	エディタの個人設定。共有したい派もいるので条件つき

上の5行は迷わず入れていい。.vscode/ だけは後で書くけど判断が分かれる。まずはこの6行で始めて、言語やツールが増えたら足していけばいい。

そもそも.gitignoreは「追跡しないで」をGitに伝えるファイル

.gitignoreは、Gitに「このパターンに合うファイルは追跡しないで」と伝えるためのただのテキストファイルだ。リポジトリの直下に置くのが基本で、コミットして共有もできる。むしろ共有するのが普通で、チーム全員が同じものを無視できる。

書式のルールは少ない。

1行に1パターン
末尾に / を付けるとディレクトリ指定(node_modules/)
* はワイルドカード(*.pyc で拡張子pyc全部)
# で始まる行はコメント
! を付けるとそのパターンだけ無視の打ち消し(除外の除外)

これだけ。凝った正規表現は要らない。困ったら「ディレクトリは / を付ける」「拡張子ごと無視するなら *.拡張子」の2つを思い出せば大体書ける。

gitそのものが初めてなら、先に git／GitHub入門で add → commit → push の流れを一周しておくと、この記事の「追跡」「ステージ」がすっと入る。

一番大事なのは.envを絶対に上げないこと

6行の中で優先度が飛び抜けて高いのが .env だ。他は「重い」「汚い」で済むけど、これだけは事故になる。

.env にはAPIキー・アクセストークン・データベースの接続情報みたいな秘密が入っている。これを公開リポジトリにpushすると、世界中の誰でもそのトークンを読める状態になる。

実際、公開リポジトリを機械的に巡回してAPIキーを収集するbotは存在していて、push後ものの数分で拾われるという話もあるはずだ。クラウドのキーなら勝手に使われて課金が走るし、外部サービスのトークンならアカウントを乗っ取られる。

しかも後述するけど、pushした後に消しても手遅れだ。履歴には残るし、拾われた時点で終わり。

だから「上げてから消す」じゃなくて「最初から追跡させない」しかない。リポジトリを作った瞬間、コードを書くより先に .gitignore に .env と書く。習慣にしていい。

代わりに .env.example みたいな名前で、値を空にしたテンプレートだけコミットしておくのが定番だ。「どんな環境変数が必要か」は共有できて、中身は漏れない。

.gitignoreはあくまで第一防衛線で、ignoreし忘れた新しい秘密ファイルをコミットの瞬間に機械で止めたいなら、pre-commitフックを重ねる手もある。

言語とOSで足すものが変わる

6行の内訳を見ると分かる通り、無視すべきファイルは「何の言語で書くか」と「どのOSで作業するか」で決まる。

分類	入れるもの	理由
Python	`.venv/` `__pycache__/` `*.pyc`	仮想環境とキャッシュ。再生成できる
Node.js	`node_modules/` `dist/` `.next/`	依存とビルド成果物。`npm install` で戻る
Mac	`.DS_Store`	Finderが勝手に作る
Windows	`Thumbs.db`	エクスプローラーが勝手に作る
エディタ	`.vscode/`	個人設定。入れるかは場合による

共通するのは「コマンド一発で再生成できるものは上げない」という考え方だ。node_modules/ は npm install、.venv/ は仮想環境の作り直しで戻る。戻るものをリポジトリに入れても、重くなるだけで誰も得しない。

.vscode/ だけは意見が割れる。無視する派は「エディタ設定は個人の自由で、人のフォントサイズやテーマまで押し付けたくない」。

共有する派は「推奨拡張機能やデバッグ設定をチームで揃えたい」。どっちも正しくて、個人開発なら無視、チームや授業のグループ開発なら settings.json の中身を見て決める、くらいの温度感でいいと思う。

複数のリポジトリを並行で触っていると、この判断をリポジトリごとにやることになる。

毎回手で書かない: GitHub公式テンプレと生成サービス

ここまで手で書く前提で説明したけど、実務ではゼロから書かない。

一番確実なのはGitHubの公式テンプレ集だ。github/gitignore というリポジトリ(github.com/github/gitignore)に、言語・フレームワーク別の.gitignoreが揃っている。

Python用、Node用、Unity用まである。中身を読むと「こんなファイルも無視するのか」という発見もあって、教材としても悪くない。

もっと楽なのは、GitHubで新規リポジトリを作るときの画面だ。「Add .gitignore」で言語を選ぶだけで、そのテンプレが最初から入った状態でリポジトリができる。新規で作るならこれが最速だと思う。

あとは、使う言語やエディタを複数指定すると合成した.gitignoreを吐いてくれるWebサービスもある(Toptalが運営しているgitignore生成サービスが有名なはず)。PythonとNodeが混ざったプロジェクトみたいな時に便利だ。

テンプレは行数が多くて最初は面食らうけど、冒頭の6行が読めれば残りも読める。分からない行はコメント(#)を見ればだいたい書いてある。この辺の環境構築はお金をかけずに全部揃うので、学生が無料で使える開発・学習ツールまとめも合わせてどうぞ。

もう上げちゃった時の直し方: git rm —cached

一度コミットして追跡が始まったファイルは、.gitignoreに書き足しただけでは無視されない。すでにGitの管理下にあるからだ。追跡から外すにはこのコマンドを使う。

git rm --cached .env
git commit -m "stop tracking .env"

ディレクトリごと外すなら -r を付ける。

git rm -r --cached node_modules

--cached が付いているので、ローカルのファイル自体は消えない。Gitの管理対象(インデックス)から外れるだけで、手元の .env はそのまま残る。

ただし注意がひとつ。すでにpushしてしまった秘密は、これで消しても無効化されない！履歴には残るし、公開された時点で見られた前提で動くべきだ。

.env の中身を公開リポジトリに上げてしまったら、追跡を外すのと同時に、そのトークンやキーを発行元で再発行(ローテーション)すること。消して終わりにしない。

Gitの仕組み(インデックス・履歴・リモート)をちゃんと押さえたい人は、git／GitHub入門で全体の流れを一周しておくと、事故のたびに調べる時間が減る。

まとめ

.gitignoreは冒頭の6行から始めて、言語が増えたら公式テンプレで足せば十分だ。今すぐ自分のリポジトリの.gitignoreを開いて、.env の1行があるかだけ確認してみてほしい。