.gitignoreとは
Gitでプロジェクトを管理するとき、すべてのファイルをリポジトリへ入れる必要はありません。
実行時に自動生成されるファイル、仮想環境、IDE固有の設定、build成果物、秘密情報を含む設定ファイルなどは、通常はGit管理から外します。
そのために使うのが .gitignore です。
.gitignore は、意図的にGitで追跡しないファイルやディレクトリをパターンで指定するファイルです。
リポジトリ内の .gitignore をcommitすれば、除外ルールそのものを別PCや他の開発者と共有できます。
重要なのは、.gitignore がファイルを削除する仕組みではないことです。
Gitが「この未追跡ファイルは通常の追跡候補として扱わない」と判断するためのルールです。
なぜ管理しないファイルがあるのか
Gitへ保存したいのは、基本的にプロジェクトを再現するために必要なソースコードや設定です。
一方、次のようなものはGitへ保存しないほうが適切な場合があります。
- 実行すると再生成できるcache
- PCごとに作り直せる仮想環境
- editorやIDEが生成する個人設定
- buildによって生成される成果物
- API keyやpasswordなどを含む秘密設定
不要な生成物までcommitすると、変更履歴にノイズが増えます。
本当に確認したいsource codeの変更と、自動生成されたファイルの変更が混ざり、diffが読みにくくなるからです。
秘密情報の場合はさらに深刻です。
API keyやpasswordを一度Gitの履歴へ入れてしまうと、あとからファイルを削除しただけでは十分でない場合があります。
.gitignore は、こうした問題を起こさないための最初の防御線でもあります。
Pythonでよく使う.gitignore
Pythonプロジェクトなら、たとえば次のような設定から始められます。
# Python cache
__pycache__/
*.py[cod]
# Virtual environment
.venv/
venv/
# Environment / secrets
.env
.env.*
# Build artifacts
build/
dist/
*.egg-info/
# IDE / editor
.vscode/
.idea/ただし、ここに書いたものを必ずすべて除外すべきという意味ではありません。
たとえば .vscode/ には、プロジェクト全体で共有すると便利な設定が入る場合があります。
その場合は、ディレクトリ全体を無条件でignoreするより、共有すべきファイルと個人固有ファイルを分けたほうが適切です。
重要なのは、
「生成されるから除外する」のではなく、「リポジトリで共有・再現する価値があるか」で判断すること
です。
.gitignoreの基本パターン
.gitignore では、基本的に1行につき1つのpatternを書きます。
たとえば、
*.logと書くと、.log で終わるファイルをignore対象にできます。
ディレクトリを指定する場合は、
build/のように書けます。
また、
# Python cache
__pycache__/のように # から始めるとcommentとして扱えます。
何を除外しているかだけでなく、なぜ除外しているのかを書いておくと、あとから見たときに理解しやすくなります。
! を使って一部だけ除外しない
ignoreしたpatternの中から、一部だけ再び対象に含めたい場合は ! を使えます。
たとえば、
.env*
!.env.exampleとすれば、.env 系ファイルをignoreしつつ、.env.example はGit管理できます。
ただし、ignore patternには優先順位やディレクトリ構造に関するルールがあります。
複雑な例外を大量に作るより、できるだけ単純な .gitignore を保つほうが管理しやすくなります。
.envをGitへ入れない
.env には、次のような秘密情報が置かれることがあります。
API_KEY=example-placeholder
DATABASE_PASSWORD=example-placeholderここで使っている値は説明用のダミーです。
実際のAPI key、token、passwordをsource code、記事、log、Git repositoryへ書いてはいけません。
一般的には、
.env
.env.*
!.env.exampleのように実値を持つファイルをignoreし、必要な変数名だけを書いた .env.example をGit管理します。
たとえば、
API_KEY=
DATABASE_PASSWORD=という形です。
これなら、
「このアプリにはどの環境変数が必要なのか」
という情報は共有できますが、実際の秘密値は共有されません。
すでにtrackedのファイルには効かない
.gitignore で特に重要なのがこの点です。
すでにGitが追跡しているファイルは、あとから .gitignore に追加しただけでは追跡対象から外れません。
.gitignore は基本的に、意図的に追跡しないファイルを指定する仕組みです。
たとえば .env をすでにcommitしたあとで、
.envを .gitignore に追加しても、それだけでは追跡は止まりません。
working treeにはファイルを残したまま、Gitのindexから追跡を外したい場合は、
git rm --cached .envを使えます。
そのあと、
git commit -m "Stop tracking environment file"などとして変更をcommitします。
ただし、ここで注意が必要です。
秘密情報をすでにcommitしてしまった場合、git rm --cached を実行しても過去の履歴に秘密値が残っている可能性があります。
その場合は、credentialの失効・再発行なども必要です。
.gitignore は秘密情報流出後の修復手段ではなく、そもそもGitへ入れないための予防策と考えるべきです。
ignoreされているか確認する
まずは通常どおり、
git statusで状態を確認します。
ignore対象になったuntracked fileは、通常のuntracked file一覧には表示されなくなります。
さらに、
「なぜこのファイルがignoreされているのか」
を調べたいときは、
git check-ignore -v .envを使えます。
-v を付けることで、どのignoreファイルのどのpatternに一致したのかを確認できます。
.gitignore が少し複雑になったときに便利な確認方法です。
.gitignore以外にもignore設定がある
Gitのignore設定は .gitignore だけではありません。
用途によって使い分けることができます。
.gitignore
プロジェクト全体で共有したいruleに使います。
repositoryへcommitして、cloneした環境でも同じruleを利用します。
.git/info/exclude
そのrepositoryだけで使いたいが、他の人とは共有したくないruleに使えます。
たとえば自分のeditorだけが作る一時ファイルなどです。
この設定自体は通常commitされません。
global ignore
すべてのrepositoryで共通して除外したい、個人環境固有のファイルにもignore設定を使えます。
OSやeditorが生成する個人固有ファイルなどが候補になります。
つまり、
- プロジェクト共通 →
.gitignore - repository内の個人設定 →
.git/info/exclude - 自分のPC全体 → global ignore
というように考えると整理しやすくなります。
.gitignoreは再現性の設計ファイル
.gitignore は単なる「不要ファイル一覧」ではありません。
もう少し広く見ると、
何をsourceとして保存し、何を生成物として捨て、何を秘密情報として外部化するか
を定義するファイルです。
たとえばPythonなら、
source code
↓ Gitで管理
requirements / pyproject
↓ Gitで管理
.venv
↓ 各環境で再生成
__pycache__
↓ Pythonが再生成
.env
↓ 環境ごとに用意という役割分担になります。
この境界が明確なら、別のPCでrepositoryをcloneしたときも、
- sourceを取得する
- 仮想環境を作る
- dependencyをinstallする
.envを用意する
という手順で環境を再構築できます。
そのため .gitignore は、repositoryの再現性を保つための設計ファイルとも言えます。
よくある失敗
.gitignoreを書いたのにファイルが消えない
.gitignore はファイル削除機能ではありません。
さらに、すでにtrackedのファイルにはそのままでは効きません。
まず、
git statusや、
git ls-filesなどでtracked状態を確認します。
.envをignoreしたから絶対安全だと思う
.gitignore は誤commit防止には役立ちますが、秘密情報対策のすべてではありません。
すでにcommitした秘密情報や、source codeへ直接書いた秘密情報は別問題です。
重要なcredentialを誤ってcommitした場合は、まず失効・再発行を検討します。
git add . を毎回無条件で使う
.gitignore があっても、commit前の確認は必要です。
git statusや、
git diff --cachedを使って、何をcommitしようとしているのか確認する習慣が重要です。
まとめ
.gitignore では、
Gitで管理するものと管理しないものの境界を明示すること
が重要です。
Pythonプロジェクトなら、
__pycache__/
.venv/
build/
dist/などは代表的な除外候補です。
.env のような秘密情報を含む可能性のあるファイルは特に注意し、実値をrepositoryへ入れない運用を徹底します。
そして必ず覚えておきたいのが、
.gitignore はすでにtrackedのファイルを自動的に追跡解除しない
という点です。
.gitignore を単なる掃除用ファイルとしてではなく、
repositoryの再現性・安全性・管理境界を定義する設定
として扱うと、Git管理はかなり安定します。
参考資料
- Git公式：gitignore Documentation
- GitHub Docs：ファイルを無視する
