.envは無視して.env.exampleはコミットしたい時の.gitignoreの正しい設定とトラブルシューティング
はじめに
モダンなWebアプリケーション開発、特にDockerを使った環境構築では、docker-compose.yml
と.env
ファイルを使ってデータベースのパスワードやAPIキーなどの設定を管理するのが一般的です。
このとき、開発チームで必ず直面するのが「機密情報が入った.env
ファイルはGitの管理下に置きたくない。でも、どんな環境変数が必要かという情報共有のために、テンプレートとなる.env.example
ファイルはGitで共有したい」という要件です。
これは多くの初学者がつまずきやすいポイントであり、設定を間違えるとエディタ上でファイルが無視されてコミットできなくなる、といった問題が発生します。
この記事では、実際の開発で起きたトラブルシューティングの事例を基に、この問題を解決するための正しい.gitignore
の設定方法と、問題発生時の原因特定方法を解説します。
.env
と.env.example
を分けるのか?
なぜまず、なぜこの2つのファイルが必要なのかを理解することが重要です。
-
.env
ファイル: 実際のパスワードやAPIキーなど、絶対に外部に漏れてはいけない機密情報を記述するファイルです。このファイルはローカル環境でのみ使用し、Gitリポジトリには絶対に含めてはいけません。 -
.env.example
ファイル:.env
ファイルのテンプレート(雛形)です。どのような環境変数が必要かをチームメンバーに知らせる役割を持ちます。実際の値の代わりにダミーの値を記述し、こちらはGitリポジトリに含めてチームで共有します。
プロジェクトに新しく参加した開発者は、リポジトリをクローンした後に以下のコマンドを実行するだけで、自分のローカル用.env
ファイルを簡単に準備できます。
cp .env.example .env
.gitignore
の正しい設定方法
.env
だけを無視し、.env.example
は無視しないようにするための.gitignore
の記述は非常にシンプルです。
悪い例 👎
初心者がやりがちな間違いは、ワイルドカード *
を使ってしまうことです。
# この書き方だと .env.example も無視されてしまう
.env*
この書き方では、.env
で始まるすべてのファイル(.env.example
, .env.development
など)が無視対象となってしまいます。
良い例 👍
無視したいファイル名を正確に、ピンポイントで指定するのが最も確実で安全な方法です。
# .env ファイルだけを無視する
.env
たったこれだけです。この1行を.gitignore
ファイルに記述すれば、Gitは.env
という名前のファイルのみを追跡対象から外し、.env.example
は通常通り追跡対象として扱います。
トラブルシューティング事例
まさに自分がこの問題に直面したので解決までの道のりを事例として紹介します。
状況:エディタ上でファイルが無視される
.gitignore
に.env
を追記し、リポジトリで共有すべき.env.example
ファイルを作成したところ、エディタ(VS Code)上でファイル名の横に🚫のような「無視(Ignored)」を示すマークが表示され、git add
ができない状態になりました。
原因の調査と特定
「.gitignore
には.env
としか書いていないのになぜ?」と混乱してしまいがちですが、こういう時はGitのコマンドを使って原因を正確に特定するのが近道です。
ターミナルで以下のコマンドを実行すると、どのファイル」の「どの行」のルールによって、指定したファイルが無視されているかをGitが直接教えてくれます。
git check-ignore -v .env.example
もし、チャット履歴のケースのように.env*
という記述がどこかに残っていた場合、実行結果は以下のようになります。
# 実行結果の例
.gitignore:10:.env* .env.example
この結果は、「.gitignore
ファイルの10行目にある.env*
というルールが、.env.example
を無視している原因です」ということを明確に示しています。
解決策
原因が特定できれば、あとは簡単です。
.gitignore
ファイルを開き、原因となっていた.env*
のような広範囲なルールを削除し、前述した「良い例」である.env
という1行だけを残すように修正します。
ファイルを保存すれば、エディタ上の🚫マークが消え、無事に.env.example
をgit add
できるようになります。
まとめ:推奨される作業フロー
最後に、一連の正しい作業フローをまとめます。
- プロジェクトに必要な環境変数を洗い出し、ダミーの値を入れた
.env.example
ファイルを作成します。 -
.gitignore
ファイルを作成(または追記)し、以下の1行を記述します。.env
- 作成した2つのファイルをコミットします。これでチームメンバー全員が同じ設定を共有できます。
git add .env.example .gitignore git commit -m "feat: Add environment template and gitignore settings"
- ローカルの開発環境で、テンプレートをコピーして**
.env
ファイルを作成**します。このファイルはGitに追跡されないので安全です。cp .env.example .env
- 作成した
.env
ファイルに、自分のローカル環境用の実際のキーやパスワードを記述して開発を始めます。
この.env
と.env.example
を使い分ける方法は、チーム開発における基本であり、セキュリティを保つ上で非常に重要です。もしトラブルに遭遇したら、まずはgit check-ignore -v
コマンドを思い出してください。
Discussion
README に .env は以下のように作成してくださいって書けば終わりでは。。。
または .env を作成するシェルっぽいなにか(チームの環境差もあるからシェルに限らない)を用意して、環境変数(.envが使われてても使われてなくてもいい)からデフォルト値を読み取るようにして、入力を促しつつ最後に .env を出力するようなものを用意しておくとか。
いつでも何回でも実行できて追加変更削除が容易になるのでおすすめ。