【Git】.gitignoreの書き方を初心者向けにわかりやすく解説
はじめに
Gitを使って開発を進めるとき、バージョン管理の対象に含めたくないファイルが出てくることがありますね。
たとえば、エディタの設定ファイルや、一時的に生成されるログファイルなどは、チームで共有してもメリットがありません。
また、APIキーなどが書かれた機密情報を誤ってリポジトリに含めてしまうのは、大きなリスクにつながります。
こういった不要あるいは機密なファイルをリポジトリに含めないために、.gitignore という設定ファイルを利用するのが一般的です。
しかし、書き方が独特なため、初心者の方は「どこに置けばいいのか？」「ファイルやフォルダを指定するにはどう書くのか？」と悩むことが多いのではないでしょうか。
そこでこの記事では、.gitignore の具体的な書き方をわかりやすく解説します。
実際の開発現場で遭遇しやすい例も交えながらお話しするので、これを読み終えた頃には「なぜ .gitignore が大切なのか」や「どうやって書けばいいか」が一通りわかるようになるはずです。
この記事を読むとわかること
- .gitignore の基本的な役割
- よく使うパターン指定の方法やコメントの書き方
- 実務でよくある除外設定の事例
- トラブルを防ぐための注意点
ここから順番に見ていきましょう。
.gitignore とは？
.gitignore は、Git のリポジトリ管理から外すべきファイルやフォルダのパターンを定義するためのファイルです。
拡張子やフォルダ構成、機密ファイルなどをあらかじめ指定しておくと、それらはコミット対象から外れます。
チーム開発の場面でも、メンバー全員が同じ .gitignore を使用すれば「共有したくない情報がリポジトリに含まれない」という安心感を得られます。
Git管理から除外できる仕組み
.gitignore に書かれたパターンと合致するファイルは、Git が「このファイルは追跡しなくていい」と認識します。
そのため、git add . などで追加しても無視されるようになります。
ただし、すでにリポジトリにコミットされているファイルを後から .gitignore に追加しても、すでに追跡されているファイルは除外されません。
その場合は、ファイルをステージングから外したり、コミット履歴から削除したりする必要があります。
どのような場面で使うか
実務においては、次のようなファイルを除外するケースがよくあります。
- IDE（統合開発環境）の設定ファイル
- ログファイル（例:
debug.logやerror.logなど） - 一時ファイル（例: OSが自動生成する
.DS_Storeなど） - 秘匿情報を含むファイル（例:
.envなど） - ビルド後に生成されるファイルやディレクトリ（例:
dist/やbuild/など）
これらをリポジトリに入れてしまうと、チームの別のメンバーが不必要なファイルの差分を受け取ることになったり、機密情報が外部に漏れたりしてしまいます。
そうならないためにも、.gitignore をきちんと書いて管理することが大切です。
.gitignore の基本的な書き方
ここからは、.gitignore ファイルの中身をどのように書くかを具体的に見ていきましょう。
書き方そのものは単純ですが、少し独特なルールがあります。
ファイルやディレクトリの指定方法
一般的に、.gitignore には以下のような指定を行います。
ファイル名
例: secret.txt と書くと、リポジトリ直下にある secret.txt を無視します。
ディレクトリ名/
例: logs/ と書くと、logs ディレクトリ以下のすべてを無視します。
* を使ったワイルドカード指定
例: *.log と書くと、拡張子が .log のファイルをすべて無視します。
また、ディレクトリ構成を区切る場合は / を使います。
たとえば、/config/*.yaml と書くとプロジェクト直下の config フォルダ内にある .yaml ファイルを無視できます。
一方、config/*.yaml と書いた場合は、プロジェクト配下にあるすべての config フォルダにマッチします。
特定の拡張子をまとめて除外するケース
特定の拡張子をまとめて除外するケースはよくあります。
たとえば、ログファイル全般を無視したいときは以下のように記述します。
*.log *.log.*
この指定で、拡張子が .log のファイルや、.log.1 などのように後ろにバージョン番号が付いたファイルもまとめて無視できます。
特定のフォルダをまとめて除外するケース
たとえば、ビルド時に生成される dist フォルダを無視したい場合は、次のように書きます。
dist/
こうすることで、dist フォルダ以下のすべてのファイルやサブフォルダを除外できます。
複数のフォルダを一度に除外したいときは、それぞれを別の行に書いていきます。
コメントや空行の扱い
.gitignore はテキストファイルですが、以下のルールが適用されます。
#で始まる行はコメントとして扱われる- 空行は無視される
たとえば、次のように書くとコメントを入れて可読性を上げられます。
# ビルド生成物を除外 dist/ # ログファイルを除外 *.log
途中でメモを残したいときにも便利です。
除外を取り消す（!）演算子
.gitignore には、いったん無視対象にしたファイルを再度追跡させたい場合に使う仕組みがあります。
それが ! 演算子です。
たとえば、以下のように書くと、.env は無視するけれど .env.example は無視しない設定にできます。
.env !.env.example
ここで !.env.example と書くことで、.env.example は追跡対象（除外しない）として扱われます。
この機能を使うと、ベースとなるサンプルファイルだけは共有しつつ、実際の機密情報が書かれたファイルはコミットしないという運用が可能になります。
よくある .gitignore の実務例
ここからは、実際に開発をしていくうえで、よく除外するファイルやディレクトリの具体例を見ていきましょう。
現場で遭遇しやすいケースを挙げますので、必要に応じて自身のプロジェクトにも適用してみてください。
IDEの設定ファイルを除外
エディタやIDEを使っていると、ユーザーごとの設定ファイルが生成されることがあります。
たとえば、Visual Studio Code なら .vscode/ ディレクトリ、JetBrains系 IDE なら .idea/ ディレクトリが該当することが多いです。
これらを共有してしまうと、ほかの人の環境に合わせた設定が不必要に混ざってしまいます。
.vscode/ .idea/
このようにディレクトリごと無視リストに入れておくと、開発環境の違いによる設定ファイルがリポジトリに含まれずに済みます。
ビルド結果やキャッシュファイルを除外
コンパイルやビルドを行うプロジェクトでは、大量のファイルが生成されることがよくあります。
たとえば、JavaScript の世界では node_modules/ フォルダ、Java の Maven や Gradle プロジェクトだと target/ や build/ フォルダなどが代表的です。
node_modules/ target/ build/
これらはあくまでビルド時に自動生成されるものなので、リポジトリには含めません。
無駄なファイルを追跡しなくなるため、クリーンな履歴を保つことができます。
秘匿情報を含むファイルを除外
実務では .env ファイルのように、APIキーやデータベースのパスワードなどを記載するケースが多いでしょう。
これらは公開するとセキュリティリスクがあるので、基本的にはリポジトリに含めません。
そのため、.gitignore に以下のように書いておくのが一般的です。
.env *.key *.pem
中には、設定ファイルのほんの一部にだけ秘密情報を含むケースもあるかもしれません。
そういった場合にはファイルの分割や、鍵情報を別途保管するなどの工夫をするのがよいですね。
共同開発の場合は、サンプル用の .env.example などを共有し、どんな変数が必要なのかだけわかるようにしておくと便利です。
.gitignore ファイルの管理で気をつけること
.gitignore を書いたらそれで終わりではありません。
運用面でいくつか気をつけるポイントがあります。
コミット前に確認すべきポイント
まず、.gitignore に追記しただけでは、すでにコミット済みのファイルは除外されません。
もし「本来なら追跡されるべきでないファイルが既にコミットされている」という状況なら、git rm --cached ファイル名 などのコマンドで追跡対象から外す作業をする必要があります。
また、チームで開発している場合は、.gitignore を更新した際にメンバー間で共有しましょう。
「どんな理由で除外したのか？」といった背景もコメントに残しておくと、あとで混乱しづらいです。
トラブルシューティング
.gitignore が効かないように見える場合、多くは以下の理由が考えられます。
- すでにコミットされているファイルだった
- 書き方のルールに誤りがある（ディレクトリ末尾の
/が抜けている など） - パターンの指定が期待と異なる形でマッチしている
一度、git status でファイルの状況を確認し、.gitignore の書き方を見直すと原因がわかることが多いです。
それでも解決しないときは、.gitignore の書き方をもう一度見直し、できれば不要なファイルが追加される前に早めに調整しておきましょう。
まとめ
ここまで、.gitignore の基本的な仕組みと書き方、そして実務でよくある具体例について紹介してきました。
初心者の方にとって .gitignore は少しとっつきにくいかもしれませんが、チーム開発や機密情報の保護を考える上では欠かせない要素です。
以下のポイントを振り返ってみてください。
- .gitignore は指定したファイルやフォルダをGitの管理から除外する設定ファイル
*や!を使ってパターンマッチが可能- IDEの設定ファイル、ログファイル、ビルド成果物、機密ファイルなどを除外するのが一般的
- 不要なファイルが既にコミットされている場合は、手動で追跡対象から外す必要がある
しっかり書き込んだ .gitignore をプロジェクトに用意しておけば、チーム全体でスムーズに開発を進められます。
ぜひこの記事を参考に、上手に除外設定を行ってみてください。