Ignoring Dependency Directories in Git
Ignore dependency directories like node_modules, vendor, and venv in git. Covers all major package managers and explains why lockfiles must be committed.
Detailed Explanation
Dependency directories are the single largest category of files that should be ignored in any project. They contain third-party libraries downloaded by package managers and can easily reach gigabytes in size. Every developer and CI server regenerates them from lockfiles.
Dependency directories by ecosystem:
| Directory | Package Manager | Language |
|---|---|---|
node_modules/ |
npm, yarn, pnpm | JavaScript/TypeScript |
vendor/ |
Composer, Bundler, Go modules | PHP, Ruby, Go |
venv/, .venv/, env/ |
pip, Poetry | Python |
.bundle/ |
Bundler | Ruby |
Pods/ |
CocoaPods | Swift/Objective-C |
packages/ |
NuGet (older format) | C#/.NET |
.dart_tool/ |
pub | Dart/Flutter |
Why dependencies should not be committed:
- Size —
node_modules/alone can contain 100,000+ files for a moderate project. This makes cloning, fetching, and diffing painfully slow. - Platform binaries — Many packages include compiled native modules (
.node,.so,.dll) that are platform-specific. Anode_modules/from macOS will not work on Linux. - Redundancy — Lockfiles (
package-lock.json,yarn.lock,Gemfile.lock,composer.lock) already encode the exact versions of every dependency. Running the install command reproduces the directory identically.
Critical: commit your lockfiles!
Never add lockfiles to .gitignore. They ensure:
- Deterministic builds — every developer and CI server installs the exact same versions.
- Security auditing — tools like
npm auditand Dependabot analyze lockfiles for known vulnerabilities. - Faster installs — package managers skip dependency resolution when a lockfile is present.
The exception — library authors: If you maintain a library (not an application), some ecosystems recommend NOT committing lockfiles so that downstream consumers test against the latest compatible versions. This applies to npm packages and Ruby gems but NOT to deployed applications.
Monorepo note: In monorepos, the root node_modules/ and hoisted dependencies are typically ignored at the root level. Each workspace may have its own nested node_modules/ that is also covered by the root-level ignore pattern.
Use Case
A new developer cloned a repository and found it took 20 minutes because someone had committed node_modules with 150,000 files, prompting the team to fix their .gitignore.