【2025年】gitignore設定について【備忘録/解説・説明】

こんにちは、カヨです。

今回のお題は、

gitignore設定について
【備忘録/解説・説明】

ビットバケットでコード管理していましたが、WEBサイトの画像素材が大きすぎて管理から除外する設定をしていました。さらに扱う画像の拡張子webpを増やそうということになり、webpの記述をコードに追加したところgitignoerの設定を追加することになり再度見直すことにしました。

こんな方に読んでいただきたいと思っています！

✔︎これから新しいプロジェクトを立ち上げコード管理の設定をおこなう人
✔gitで管理したくないファイルがある人
✔gitignoerを作成・編集しようとしている人

前提

・Windows
・Bitbucket（ビットバケット）使用
・SourceTree（ソースツリー）使用
・Git
・WEBサイトの編集
・Gitでの画像管理を対象外にしている

gitignoreの内容記録

筆者自身がよく使う設定のまとめです。設定はプロジェクトによって全然違うのでそのまま使わず内容確認にごりようください。

# gitignore

.vscode
/aspnet_client/**/*
/node_modules/**/*
/vendor/**/*
/www/web.config
/www/css/**/*


## mac隠しファイル
.DS_Store


## 画像ファイル
*.jpeg
*.jpg
*.png
*.gif
*.tiff
*.svg
*.svgz
*.bmp
*.pdf
*.webp


## 動画ファイル
*.mp4
*.mpg
*.avi
*.mov
*.flv
*.wmv
*.mkv


## 差分用
/compare/
/diff/

gitignore設定詳細

それぞれの設定の詳細です。、Gitで管理しないものです。

✔.vscode
#VS Codeの設定ファイル（開発環境依存）【定番】
　⇒VS Codeの個人設定を無視

✔/aspnet_client/**/*
# ASP.NETのクライアントファイル（プロジェクト依存）【ASP.NETなら定番】

✔/node_modules/**/*
# Node.jsのパッケージ（npm/yarn）【超定番】
　⇒ node_modules/ はGitに含めるとリポジトリが重くなりすぎる
　⇒package.json と package-lock.json さえあれば、環境を再現可
　⇒環境によって node_modules/ の中身が変わるため、Gitで管理するとトラブルのもとになる
　⇒例外的に、オフライン環境や特殊な環境では管理することもあるが、一般的には推奨されない

✔/vendor/**/*
# PHP（Composer）のライブラリ【LaravelなどのPHPプロジェクトなら定番】
　⇒composer install すれば vendor/ を再構築できるから
　⇒vendor/ はGitに含めず、composer.json + composer.lock を管理するのがベスト！
　⇒基本は /vendor/ を .gitignore で無視して、Git管理しない

✔/www/web.config
# ASP.NETの設定ファイル（プロジェクト依存）【ASP.NETなら定番】
　⇒web.config は Git で管理しないのが定番
　⇒本番環境の web.config をGitで管理すると、設定が上書きされるリスクがあるので注意！
　⇒ASP.NET Core を使っているなら、web.config をGit管理するより appsettings.json を活用したほうが柔軟！

✔/www/css/**/*
# CSSファイル全体を無視（ケースバイケース）【一般的ではない】
　⇒SCSSをコンパイルするなら、www/css/ はGitで管理しないのが一般的
　⇒デプロイ時に npm run build や gulp でCSSを生成すればOK
　⇒CSSをGit管理するなら、*.min.css や *.map だけを無視する方法もあり！

✔.DS_Store
# .DS_Store はmacOSの隠しファイル【管理しないのが定番！】
　⇒.DS_Storeはアイコンの配置・ウィンドウサイズ・ソート順などの設定を記録
　⇒.DS_Storeは各フォルダに自動的に作られるため、不要なゴミファイルになりがち
　⇒Gitリポジトリに含める必要がないので無視するのが定番

✔「## 画像ファイル」「## 動画ファイル」
#画像や動画をGitで管理しない最大の理由は「ファイルサイズが大きく、リポジトリが重くなる」【超定番】
　⇒Gitに入れるとリポジトリが肥大化し、管理が面倒になる
　⇒例外的に Gitで管理することもあるけど、その場合は Git LFS を使うのが推奨。

✔## 差分用の「/compare/」「/diff/」
# 差分比較のための「一時的な差分チェック用フォルダ」【管理しないのが一般的！】
　⇒ サイズが大きくなることが多く、リポジトリを重くしないため
　⇒.頻繁に変更されるため、Gitに含めると履歴が無駄に増える

そもそもgitignoreとは？

✔「Gitに入れたくないファイル・フォルダを指定するリスト」💡

■gitignoreの役割
・Gitが追跡しないファイルを指定できる
・不要なファイルをリポジトリに含めないようにする
・個人環境の設定ファイルや、ビルド後のファイル、機密情報を誤ってコミットしないようにする

筆者

追跡して記録して管理しておかない方がいいファイルがあるってことですね。例えば本番とローカルで異なる設定を行うものや共同開発同士でも違う場合があり揃えないときは追跡させない。

■gitignoreを使うメリット
・リポジトリをスッキリさせる（不要なファイルを管理しない）
・誤って機密情報をコミットするのを防ぐ（.env など）
・チーム開発で不要なファイルが混ざらないようにする（OS依存の .DS_Store など）

✔簡単に言うと。。。
⏩ 「Gitに入れたくないものをリスト化するファイル」 🚀
⏩ 「余計なものがGitに入らないようにするチェックリスト」 🔍
⏩ 「環境設定や一時ファイルを除外して、スッキリ管理するためのもの」 🗂✨

その他

その他gitignoreについて気になることをまとめてみました。

✔gitignoreはいつ作成するもの？
すでに作成されていて新規プロジェクトのいつごろ新規作成するのかと思ったのがきっかけ。
　⇒リポジトリを作成する時点で作る
　⇒新規プロジェクトの 「Git管理を始める最初の段階」 で作るのが理想的💡
　⇒「Gitリポジトリを作る時 ( git init 直後)」や「新規プロジェクトを作成した直後」または「フレームワークやツールをインストールする前（npm installの前）」

✔どこに配置するの？
プロジェクトのルートディレクトリ（リポジトリの最上位）に .gitignore を置くのが一般的！ルートに配置すれば、プロジェクト全体に適用される！

/my_project/ ← プロジェクトのルート
  ├── .git/ ← Gitの管理フォルダ（`git init` で作成される）
  ├── .gitignore ← ✅ ここに配置！
  ├── src/ ← ソースコード
  ├── wwwroot/ ← Web関連ファイル
  ├── node_modules/ ← `npm install` で生成（Git管理しない）
  ├── dist/ ← ビルド後のファイル（Git管理しない）
  ├── package.json ← Node.jsプロジェクトの場合
  ├── composer.json ← PHP（Laravelなど）の場合

✅ この場所に .gitignore を置くと、リポジトリ全体に適用される！

✔.gitignoreは隠しファイル？どうやって作るのか？
「隠しファイル」扱いになるけど、特別なファイルではない！

■ .gitignoreが隠しファイル扱いになる理由
　・「.（ドット）」が先頭についているファイルは、Unix系OS（Linux, macOS）では隠しファイルとして扱われる。
　・そのため、通常のファイル一覧には表示されないことがある（Finderやエクスプローラーで見えない）。
　・でも、Gitの動作には関係なく、普通のテキストファイルとして扱える。

■Windowsでは「.gitignore」を直接作れないことがある
　✅ Windowsでは「ドットだけのファイル名」を作れない制限がある
　・.gitignoreのように、拡張子なしで「.（ドット）」から始まるファイルを作るのが難しい。
　・エクスプローラーでは「名前を変更」すると「.gitignore.txt」になってしまう 😱

　✅ 解決策：「.gitignore.」で作って、後ろのドットを削除する
　・Windowsでは .gitignore.と「最後にドットを付けて」保存すると、勝手にドットが消えて .gitignoreになる。

✔ソースツリーに表示されても間に合う？
gitignoreに書かれてないファイルを追加してしまったけど、今追跡したくないと気付いた。。。そんな時。
　⇒コミット前なら：間に合った。その場gitignoreに書き込むと反映された。
　⇒コミット後なら：間に合わない！取り消し作業が必要！

✔もしすでにコミットしてしまった場合
修正は可能だが手間がかかる。プッシュ前なのかプッシュ後なのかで変わる。