📦 .gitignore / .dockerignore ジェネレーター
言語 (Node / Python / Go / Rust / Java / PHP / Ruby など) / フレームワーク (React / Next.js / Django / Rails / Laravel) / IDE (VSCode / JetBrains / Vim) / OS (macOS / Windows / Linux) のプリセットを重ね合わせて .gitignore または .dockerignore を一発生成。重複排除・コメント保持・ライブプレビュー・コピー / ダウンロード対応。
📝 .gitignore (プレビュー)
# プリセットを 1 つ以上選択してください
📖 つまずきやすいポイント
言語・フレームワーク・IDE・OS のプリセットを重ね合わせて .gitignore または .dockerignore を生成します。重複行は除き、コメントは残します。処理はブラウザ内で完結します。ただし .gitignore は「これから追加されるファイル」にしか効きません — すでに Git が追跡しているファイルは、何を書いても無視されません。そして最も多い誤解がここです: .env を commit してから .gitignore に足しても、リポジトリからも履歴からも消えません。無視することと、無かったことにすることは別です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| すでに追跡しているファイルには効かない | Git は追跡対象になった時点で .gitignore を参照しなくなります。したがって、一度 commit した .env・node_modules・ビルド成果物は、後からルールを足しても差分に出続けます。そして本当の問題は、目の前の作業ディレクトリではなく履歴です — git rm --cached で追跡を外しても、過去のコミットの中身は消えません。git log -p を打てば誰でも読めますし、すでに push していれば、fork・ミラー・CI のキャッシュ・各種のクローンにも同じものが残っています。公開リポジトリなら、機械的に鍵を収集しているスキャナが数分で見つけます — 実際、公開直後の漏洩鍵が悪用されるまでの時間は分単位で観測されています。 |
まず追跡を外します: git rm --cached .env を実行し、.gitignore への追加と一緒に commit してください (--cached を付けないとファイル自体が消えます)。ディレクトリなら -r を足します。そして機密が含まれていた場合、対処はただ 1 つです: その鍵をローテーションしてください。履歴の書き換え (git filter-repo) は可能ですが、それを唯一の対策にしないでください — 全員が clone を作り直す必要があり、しかも他人の fork や push 済みのオブジェクトには手が届きません。予防としては、追加する前に止めるのが最も安上がりです: git add の前に git status を読む習慣と、gitleaks や git-secrets を pre-commit フックに入れることです。 |
.gitignore をそのまま .dockerignore にする |
この 2 つは形式が同じで目的が違います。.gitignore はバージョン管理から外すものを書き、.dockerignore はビルドコンテキストに送らないものを書きます。そのまま流用すると 2 方向に壊れます。ビルドに必要なものを除外してしまう — dist/ は .gitignore では正しい除外ですが、事前ビルドした成果物を COPY する Dockerfile では必須のディレクトリです。逆に、除外すべきものが残る — .git/ と node_modules/ を除外しないと、コンテキストが数百 MB になりビルドが目に見えて遅くなります。しかも ホストでインストールした node_modules がイメージに入ると、プラットフォームの違うネイティブモジュールが混入して実行時に落ちます。 |
2 つを別々に書いてください。 .dockerignore は「イメージのビルドに必要なものだけを通す」という発想で作ると外しません — 最低限、.git・node_modules・.env・*.log・テスト・ドキュメント・CI 設定を落とします。.env は必ず入れてください — コンテキストに入れば COPY . . でイメージに焼き込まれ、イメージを配布した相手全員が読めます。効果の確認は簡単で、docker build の最初に出るコンテキスト転送量を見ます — 数 MB 以下に収まっていれば適切です。そして .dockerignore はリポジトリのルート (ビルドコンテキストの起点) にしか置けません — サブディレクトリに置いても読まれません。 |
| パターンが思ったところに当たらない | 書き方の細部で意味が変わります。スラッシュを含まない build は、どの階層にある build にも当たります。先頭にスラッシュを付けた /build はルート直下だけ、末尾にスラッシュを付けた build/ はディレクトリだけです。最も分かりにくいのが除外の打ち消し (!) で、親ディレクトリを除外していると、その中のファイルを ! で戻すことはできません — Git は除外されたディレクトリの中身を走査しないので、そこに書いたルールは読まれもしません。node_modules/ と !node_modules/mylib を並べても、後者は何も起こしません。エラーも警告も出ないので、「書いたのに効かない」という形でだけ現れます。 |
迷ったら git check-ignore -v <パス> を実行してください。 どのファイルの何行目のルールが効いたかを 1 行で表示します — このコマンドを知っているかどうかで、調査時間が桁で変わります。何も出力されなければ、そのパスは無視されていません。ディレクトリの中の 1 つだけを戻したいときは、ディレクトリごとではなく中身を除外してください: node_modules/* と書いてから !node_modules/mylib を並べれば意図どおりに動きます。プリセットを重ねると行数が増えますが、量そのものは問題になりません — 問題になるのは「なぜこの行があるのか分からない」状態なので、プロジェクト固有の行はコメントを添えて末尾にまとめてください。 |
無視の設定は 1 か所ではありません。Git は リポジトリの .gitignore・サブディレクトリの .gitignore・.git/info/exclude・グローバル設定 (core.excludesFile) を順に見ます。ここでの使い分けには明確な基準があります: そのプロジェクトの誰にとっても不要なもの (ビルド成果物・依存ディレクトリ) はリポジトリの .gitignore へ、あなたの環境だけの事情 (エディタの設定・OS が作るファイル・個人的なメモ) はグローバル設定へ入れてください。.DS_Store や Thumbs.db や .idea/ をリポジトリの .gitignore に書くのは、厳密には他人に自分の環境を押し付けていることになります — ただし現実には全員がやっているので、チームで揃えるほうが摩擦が少ないのも事実です。最後に 空のディレクトリは Git が追跡しません — logs/ のような空ディレクトリを残したいなら、logs/.gitkeep という空ファイルを置いてください (.gitkeep は Git の機能ではなく、ただの慣習的なファイル名です)。
📖 使い方
-
1
モードを選ぶ上部の「.gitignore」または「.dockerignore」タブで生成するファイルの種類を選択。.dockerignore は image bloat 対策プリセット (node_modules / .git / *.log など) を優先的に含めます。
-
2
スタックを選ぶ使う言語・フレームワーク・IDE・OS のチップをクリックして選択。複数選択するとマージ + 重複排除されたファイルが生成されます。
-
3
コピー or ダウンロードプレビュー右上のコピーボタンで即クリップボードへ。ダウンロードボタンを押すと .gitignore / .dockerignore というファイル名で即保存できます。
❓ よくある質問
.gitignore と .dockerignore の違いは?
生成された .gitignore を既存のものに追加できますか?
GitHub 公式の gitignore リポジトリと何が違いますか?
プリセットを増やしてほしい
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。