.gitignoreとは？初心者向けに仕組みや使い方を解説
はじめに
プログラミング未経験や学習を始めたばかりの方でも、開発現場でよく耳にするのが「Git」というバージョン管理システムではないでしょうか。
そんなGitを使う際に、一緒によく登場するのが**.gitignore**というファイルです。
このファイルをうまく活用することで、バージョン管理が格段に楽になります。
いったいどんな役割をしているのか、どのように使えばいいのか、最初は少し戸惑うかもしれません。
この記事では、.gitignoreが何のために存在し、どんな仕組みになっているのかを初心者向けにわかりやすく紹介します。
プロジェクトでの実際の利用シーンを交えながら、具体的な作成例や注意点も解説していきます。
最後まで読んでいただくと、無駄なファイルをバージョン管理から除外し、効率よくGitリポジトリを整理できるようになるでしょう。
この記事を読むとわかること
- .gitignoreが果たす役割と基本的な構文の理解
- プロジェクトでどのように利用されているかの具体例
- チーム開発でのトラブルを回避するベストプラクティス
- よくある質問とトラブル時の対処法
.gitignoreとは何か
バージョン管理における役割
Gitでプロジェクトを管理していると、成果物以外にも多くのファイルが生成されます。
例えば、エディターやOSが自動生成するファイル、テスト時に作られるログファイル、ビルド後の成果物などです。
これらをそのままGitで追跡すると、履歴が膨れ上がったり、他の人とファイルの差分が頻繁に衝突したりといった問題が起きやすくなります。
そこで登場するのが**.gitignore**というファイルです。
.gitignoreは「指定したパターンに合致するファイルやディレクトリを、Gitが追跡対象から外す」ための設定ファイルです。
これによって、不要なファイルがGitリポジトリに含まれないように管理できるようになります。
.gitignoreの基本構文と仕組み
このファイルの中で指定するルールは、とてもシンプルなパターンマッチングによって実現されています。
以下のような形式で、無視したいファイル名やディレクトリ名を列挙していきます。
# コメントは # で始める
# 例えば、OSのゴミファイルを無視したい場合
.DS_Store
Thumbs.db
# ログファイルや環境変数ファイルを無視したい場合
*.log
.env
# ディレクトリを無視したい場合
node_modules/
このように、特定のファイル拡張子やフォルダ名を記述しておくと、Gitはそのパターンに合致したものを追跡しなくなります。
ワイルドカードとして * が使えるため、.logファイルをすべて無視したい場合は *.log と書くのが便利です。
シンプルなパターン
*.tmpのように書くと、その拡張子をもつファイルがすべて無視されますtemp/と書くと、tempディレクトリ下すべてを無視しますmyfile.txtと書くと、その特定ファイルが無視されます
これらのシンプルな書き方だけで、基本的な無視設定は十分カバーできるでしょう。
特殊なパターン
- 先頭に
!を付けると、そのパターンに合致するファイルを逆に無視しない設定が可能です /*/cache/のように書けば、1階層下の任意のフォルダにあるcacheディレクトリを無視するといった応用もできます
実際にはそこまで複雑なパターンを使わなくても済むケースが多いですが、特別な運用やプロジェクト構造の場合に知っておくと便利です。
なぜ .gitignore が重要か
バージョン管理では、不要なファイルを追跡しないことが大切です。
もし、環境変数ファイルなどをうっかりリポジトリに含めてしまうと、チーム外に漏れてはいけない情報が見えてしまう可能性があります。
また、ビルド済みの成果物や画像キャッシュなどが混ざると、コミットのたびに大量のファイルが差分として表示され、管理が煩雑になります。
このようなトラブルを防ぐために**.gitignore**が存在します。
それゆえ、.gitignoreはプロジェクトの運用の基盤と言えるでしょう。
実務での活用シーン
一般的によく無視するファイルとフォルダの例
開発現場では、以下のようなファイルがしばしば無視リストの上位に挙がります。
OS固有のファイル
例: .DS_Store, Thumbs.db
ビルドやコンパイル後に生成されるファイル
例: dist/, build/, out/
各種ログファイル
例: *.log
環境変数や認証に関するファイル
例: .env, .aws-credentials
パッケージ管理システムが生成するディレクトリ
例: node_modules/, vendor/
ここをあらかじめ設定しておくことで、コミットに含める必要のないものをGit上で管理せずに済みます。
プロジェクトごとの .gitignore の構成例
プロジェクトの性質によっては、無視対象をより細かく設定することもあります。
Webアプリのプロジェクトならnode_modules/やビルド成果物を無視し、デスクトップアプリならインストールファイルなどを無視対象にします。
また、同じ言語でもフレームワークやライブラリによって生成されるフォルダやログの場所が異なるケースがあります。
そこで、プロジェクトごとに合わせた .gitignore のテンプレートを用意しておくと便利です。
こうすることで、チーム全員が同じ基準で無視設定を共有できます。
共同開発時に気をつけるポイント
チームで開発をすると、開発環境がメンバーごとに微妙に異なることがあります。
たとえば、Macを使っている人とWindowsを使っている人がいると、OS固有ファイルの無視設定が共有されていないと余計なファイルがコミットされるかもしれません。
そこで、チーム全体の無視ルールをあらかじめ明確に決め、みんなが使うリポジトリに同じ.gitignoreを配置するのが望ましいです。
もし、個人の好みで無視したいファイルがあれば、グローバル設定（後述）を使うなどして分けておくのがおすすめです。
プロジェクトの例で学ぶ .gitignore
Node.js プロジェクトの .gitignore
Node.jsを使ったプロジェクトでは、以下のような.gitignoreをよく目にします。
# Node.jsプロジェクトでよく無視するファイル例 node_modules/ npm-debug.log yarn.lock dist/ *.env
node_modules/は大容量になりやすく、コミットされるとリポジトリのサイズが急激に増えてしまいます。
また、.envなどのファイルには環境変数が含まれている場合があるため、セキュリティ面でも無視しておいたほうが安全です。
dist/などビルド後の成果物ディレクトリもコミット対象にしないことが多いです。
Python プロジェクトの .gitignore
Pythonプロジェクトの場合には、以下のような内容をよく含めます。
# Pythonプロジェクトでよく無視するファイル例 __pycache__/ *.py[cod] .venv/ *.log
.venv/ という仮想環境ディレクトリや、Pythonが生成するキャッシュファイル__pycache__/を無視することで、余計なものがリポジトリに含まれずに済みます。
.pycや.pyoといったファイルも同様に、コミットしても意味がないので除外対象になります。
Go言語プロジェクトの .gitignore
Go言語の場合は、ビルドによってbin/などのフォルダが生成されることがあります。
# Goプロジェクトでよく無視するファイル例 bin/ *.log *.exe
プラットフォームによっては、.exe拡張子の実行ファイルが生成されるので、必要に応じて除外設定を加えるとよいでしょう。
Windows・Macなど特定OSの例
WindowsユーザーとMacユーザーが混在しているプロジェクトでは、以下のようにOS固有ファイルを無視するルールを加えることが多いです。
# Mac系ファイル .DS_Store # Windows系ファイル Thumbs.db
不要なファイルが混ざらないようにすることで、差分管理やレビューがスムーズになります。
よくあるトラブルと対処法
すでにコミット済みファイルを無視したい場合
一度Gitにコミットしたファイルは、.gitignoreに書いただけでは追跡をやめません。
例えば、大きなログファイルを間違えてコミットしてしまったあとに、.gitignoreに *.log を追記してもそのまま追跡対象になることがあります。
その場合、以下のような手順で一度追跡を外す必要があります。
# 一度キャッシュをクリア git rm -r --cached . # その後、改めてコミット git commit -m "Remove tracked files based on .gitignore"
こうすることで、すでにコミットされていたファイルを追跡から外し、新たに.gitignoreに沿った状態で管理できるようになります。
ただし、履歴自体からファイルを完全に消し去るには、さらにGitの履歴を操作する方法が必要です。
そういった操作は履歴改変になり、チーム開発への影響も大きいので取り扱いには注意が必要です。
.gitignore の変更を反映させる際の注意点
開発途中で.gitignoreを編集することは珍しくありませんが、そのタイミングで新たに無視したいファイルがすでにリポジトリに含まれている可能性があります。
これは先ほどの対処法と同じく、git rm --cachedなどを使って追跡を外す必要があります。
また、チームメンバー全員とタイミングを合わせないと、メンバーによって無視設定が異なる状態になり、コミット時に余計なファイルが含まれる場合もあります。
都度コミュニケーションを取りながら作業を進めるのが大切です。
OS固有ファイルをコミットしないための対策
OS固有のファイルはメンバーごとに異なることが多いです。
このようなファイルを誤ってコミットしないための対策として、リポジトリの.gitignoreに一通り書いておくほか、グローバル設定で無視する方法があります。
グローバル設定は、ユーザー単位で無視したいファイルを指定する仕組みです。
例えば、以下のようなコマンドでグローバルの.gitignoreを設定します。
git config --global core.excludesfile ~/.gitignore_global
そこに.DS_StoreやThumbs.dbなどを書いておけば、全リポジトリでそれらのファイルを無視するようにできます。
プロジェクト依存ではなく、自分の使う環境に合わせた設定を個人で管理できるというわけです。
チーム開発における .gitignore のベストプラクティス
リポジトリ全体に適用する .gitignore
チームが同じリポジトリを共同で使う場合、.gitignoreファイルはリポジトリのルートディレクトリに置くのが一般的です。
これにより、リポジトリ配下のファイルやフォルダに対して一括でルールが適用されます。
とくにフレームワークを使った大規模プロジェクトでは、キャッシュやビルドフォルダなど、明確に無視すべきものがたくさんあるので、最初にしっかり整備しておくことが重要です。
途中で設定を変えると、ファイルの追跡を外す必要が出るなど手間が増えるので、プロジェクト開始時に相談して確定しておくとスムーズです。
グローバル .gitignore
先ほど触れたように、OSやツール固有のファイルを毎回リポジトリごとに書くのは面倒に感じることがあります。
それはグローバル .gitignoreで管理するのがおすすめです。
たとえば、自分だけが使うテキストエディタが生成するバックアップファイルなどは、プロジェクトとは関係ありません。
そのようなものはチーム全員が共有する.gitignoreではなく、個人のグローバル設定として除外しておくとトラブルを回避しやすくなります。
セキュリティと .gitignore
開発を進める上で、よくあるファイルとして.envや.aws-credentialsなど、認証情報やAPIキーを入れておくものがあります。
これらが万一リポジトリにコミットされると、チーム以外の第三者に見えてしまうリスクがあります。
オープンソースプロジェクトだと、公開リポジトリにAPIキーが含まれるケースもあり、大問題になりかねません。
そこで、プロジェクト開始時に.envなどの重要ファイルは必ず.gitignoreに追加しておきましょう。
この一手間で漏洩リスクを大幅に下げられます。
APIキーやパスワードの管理
APIキーやパスワードは、.gitignoreを使うだけで安心とは言い切れません。
万が一コミットしてしまった場合には、履歴を修正する大掛かりな対処が必要です。
それを防ぐには、必ず秘密情報用のファイル名を明示的に無視リストに加えることが大事です。
チームメンバー全員に「APIキーを格納するファイルはこの名前に統一しよう」と決めるだけでも、漏洩防止に役立ちます。
プライベート情報が漏れる原因を防ぐ
実務でありがちなケースとして、個人のPC設定やユーザー名を含んだファイルをうっかりコミットしてしまう事例があります。
これは一種のプライバシー情報や個人情報になり得るため、注意が必要です。
.gitignoreを適切に設定しておけば、不必要なファイルや個人にひもづく設定ファイルがコミット対象に入る可能性を低減できます。
定期的なメンテナンスも含め、チーム全体で管理ルールを共有しておくと良いでしょう。
.gitignore作成の流れ
新規でプロジェクトを始めるときのフロー
- プロジェクトのディレクトリを作成する
- そのディレクトリで
git initを行う - .gitignore ファイルを作成し、無視すべきファイルをリストアップ
- ファイルを追加し、初回のコミットを行う
このタイミングで無視設定を整備しておけば、不要なファイルがコミットされるのを防ぐことができます。
勢いでコードを書いてから.gitignoreを用意すると、気づかないうちにいろいろなファイルが追跡されている場合があります。
最初にしっかりと整備するのが理想です。
既存のプロジェクトに追加するフロー
既存プロジェクトにあとから.gitignoreを導入する場合は、次のようになります。
- リポジトリルートに**.gitignore**ファイルを作成
- 無視したいファイルを追記
- 既にコミットされている不要ファイルがある場合は
git rm --cachedコマンドで追跡を外す - コミットして変更を共有
このとき、チームメンバーに変更内容を周知しないと、**「自分の環境では無視ルールが違う」**という事態を招く恐れがあります。
必ずコミュニケーションをとりながら進めていきましょう。
自動生成ツールの活用
プロジェクトによっては、初期設定用のテンプレートに.gitignoreを含めていることがあります。
たとえば、各種フレームワークのCLIツールなどを使うと、自動生成されるプロジェクトのディレクトリ構成に、あらかじめ最適化された.gitignoreが付いてくる場合もあります。
このような便利な仕組みを使うと、初心者でも無視設定を漏れなく整備しやすいでしょう。
ただし、プロジェクト固有の要素がある場合には、生成された.gitignoreを後から編集して最適化する必要があります。
よくある質問
共同開発者が別の .gitignore を適用したいと言ったら？
リポジトリのルートに存在する.gitignoreは、そのリポジトリ全体に対して適用されます。
もし、どうしても別の無視設定を適用したい理由があるなら、以下のような選択肢が考えられます。
- 個人の環境だけで除外したいファイルは、グローバルの
.gitignoreで対応する - サブフォルダごとに
.gitignoreを置く方法を検討する
ただ、プロジェクト全体に関わる部分はリポジトリルートの.gitignoreで統一しないと、混乱を招く原因になります。
チームとしての合意を優先しながら、用途に応じた分割や役割分担を考えてみるのがよいでしょう。
.gitignore ファイルは複数作れるのか？
Gitでは、サブディレクトリごとに.gitignoreを設置することができます。
たとえば、frontend/ディレクトリとbackend/ディレクトリがある場合、それぞれのディレクトリ内に.gitignoreを置いてもOKです。
ただし、ルートにある.gitignoreの設定がベースとなり、それに加えてサブディレクトリの無視ルールが適用される仕組みです。
ルールが競合する際は、より深い階層にある.gitignoreが優先されることになります。
ただあまり複雑にしすぎると、チームメンバーが「このファイルが無視される理由がわからない」と混乱するかもしれません。
そのため、1つのプロジェクトに対して、できるだけ1つの.gitignoreで管理するのが一般的でしょう。
.gitignore と .gitattributes の違い
たまに混同されがちですが、.gitignoreは無視したいファイルやディレクトリを指定するためのファイルです。
一方で、.gitattributesはファイルの属性や改行コードの扱いなどを指定するためのファイルです。
.gitignoreはリポジトリに含めるかどうかを制御しますが、.gitattributesはファイルの扱い方を制御すると考えるとよいでしょう。
内容としてはまったく別の目的を果たしますが、両方ともプロジェクトのルートに配置されることが多いので混同しないよう注意が必要です。
まとめ
.gitignore は、バージョン管理において「不要なファイルやセキュリティ上重要なファイルを除外する」ために欠かせない存在です。
実務では、チームがうっかりコミットしては困るファイルをしっかり無視リストに含めることで、大きなトラブルを防ぐことができます。
初心者の方は、とりあえずnode_modules/や__pycache__/など、よく知られた無視対象から始めてみると良いでしょう。
チームで開発する際には、同じ.gitignoreを共有しつつ、必要に応じてグローバル.gitignoreを活用すると混乱が減ります。
設定を忘れたまま進めてしまうと、後でファイルを追跡から外す作業が大変になってしまいます。
プロジェクト開始時に**.gitignore**を整備しておくのが、円滑な開発の第一歩です。