Usually no. The Go modules reference says it is generally inadvisable to commit go.work files to version control. A checked in file can override a developer's own workspace file and can make CI test the wrong dependency versions. The exception is a repository whose modules are developed only with each other.
What go.work does
A Go workspace is a collection of modules on disk used as the main modules when Go runs minimal version selection. The go.work file lists them with use lines:
go 1.23.0
use ./my/first/thing
use ./my/second/thing
Each use line is a relative path to a directory containing a go.mod. Go finds the file by searching the current and parent directories. Running go env GOWORK shows which file is in use, and setting GOWORK to off returns you to single module mode.
Why committing it causes trouble
The modules reference gives two reasons. A checked in go.work might override a developer's own go.work in a parent directory. And it may cause a CI system to select, and therefore test, the wrong versions of a module's dependencies.
The second is the one with supply chain impact. With a workspace active, local folders replace the versions your go.mod files name. A green build then proves less about what customers will get, because they build from the published go.mod, not your workspace.
The case where committing is fine
The docs say there are cases where committing makes sense, such as when the modules in a repository are developed exclusively with each other but not together with external modules. A repository of several modules that always move together is the typical example.
What to do in CI
- Set GOWORK=off in a CI job that must prove each module builds on its own published dependencies.
- Run a second job with the workspace on if you also want to test the modules together.
- Keep go.sum files committed for every module. See Go checksum and proxy settings explained.
A simple rule
If a file exists only to make one developer's laptop convenient, add it to .gitignore. If the repository truly is a family of modules released together, commit it and test both ways.
Safeguard dependency and SBOM scanning can list the modules a repository resolves and flag known vulnerabilities. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How do I turn the workspace off for one command?
Set the GOWORK environment variable to off for that command, for example GOWORK=off go build ./....
How do I see which go.work is active?
Run go env GOWORK.
Sources
Last reviewed: 19 October 2026.
