Commit the file your ecosystem uses to record exact dependency versions: package-lock.json for npm, Cargo.lock for Rust, and the pinned requirements file for Python. Go uses go.sum for hashes. Maven has no default lockfile and relies on declared versions. Check your team's convention for the details.
The lookup table
| Ecosystem | File | What the docs say |
|---|---|---|
| npm | package-lock.json | Intended to be committed to source repositories so teammates, deployments and CI install the same dependencies |
| Rust | Cargo.lock | Holds exact dependency information, maintained by Cargo, and "when in doubt, check Cargo.lock into version control" |
| Python (pip) | A requirements file | pip freeze outputs installed packages in requirements format, which you can review and pin |
| Go | go.sum | The go command checks downloaded module hashes against go.sum, and fetches from the checksum database if a hash is missing |
| Maven | None by default | You can guarantee a version by declaring it explicitly in your POM |
Why the lockfile belongs in git
A manifest says what you are willing to accept. A lockfile says what you actually got. Without the second file, two developers building a day apart can get different code, and a bad release published in between reaches you without a review.
The Cargo Book states the reasoning plainly: if you build today and send a copy to someone who builds tomorrow, new upstream commits could change the result, and reproducible builds are the goal. The lock records exact revisions so the same inputs produce the same build.
Python and Maven need a decision
Python has several workflows, and pip itself is described in its docs as not a workflow management tool, so your team has to choose how to pin. Many teams commit a fully pinned requirements file, sometimes with hashes. See pip require-hashes mode.
For Maven, the dependency mechanism picks the version of the nearest definition in the dependency tree. That can surprise you, so teams often declare versions in dependency management or a bill of materials. See how Maven picks a version.
New-hire checklist
- Identify your repo's ecosystem and its pinning file.
- Confirm that file is tracked in git and not in ignore rules.
- Commit lock changes in the same pull request as manifest changes.
- Use the frozen or locked install in CI.
- Review lockfile diffs, not just manifest diffs.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. See how exact resolved versions, not just ranges, show up in the inventory.
Quick check
Should a library commit its lockfile?
Practice differs by ecosystem and project type. Follow the docs for your tool and your team's convention.
Can I edit a lockfile by hand?
Avoid it. The Cargo Book says Cargo.lock should not be edited manually, and the same caution applies to other generated lock files.
Sources
- npm Docs: package-lock.json
- The Cargo Book: Cargo.toml vs Cargo.lock
- pip docs: pip freeze
- Go Modules Reference
- Apache Maven: Introduction to the Dependency Mechanism
Last reviewed: 19 October 2026.
