Modules and Packages

# Add a dependency, or upgrade it to the newest release
go get github.com/google/uuid@latest

# Pin a specific version (downgrading works the same way)
go get github.com/google/uuid@v1.6.0

# Make go.mod and go.sum match the imports in your code
go mod tidy

# Inspect the dependency graph and available upgrades
go list -m all
go list -m -u all

# Remove a dependency
go get github.com/google/uuid@none

Modules follow semantic versioning. Starting at major version 2, the major version becomes part of the import path, as in example.com/lib/v2, so incompatible majors are treated as entirely separate packages. When several dependencies require different versions of the same module, Go uses minimal version selection: it picks the highest version that anyone explicitly requires, never something newer. Nothing upgrades behind your back.

go install

go install builds a package and places the binary in GOBIN, or in GOPATH/bin when GOBIN is unset. Adding a version suffix installs a tool in isolation, without touching the go.mod of whatever directory you happen to be in.

# Install a tool globally, independent of the current module
go install golang.org/x/tools/cmd/goimports@latest

# Install a main package from the module you are working on
go install ./cmd/server

# See where binaries end up
go env GOBIN GOPATH

Working on several modules at once

Sometimes you need to change a library and the application that uses it together, before the library is published. Two tools help. A replace directive in go.mod swaps a module for a local directory. A workspace, created with go work, groups several modules so they build together without editing any go.mod at all.

# replace: recorded in go.mod
go mod edit -replace example.com/lib=../lib

# workspace: creates go.work (usually kept out of version control)
go work init . ../lib

Vendoring basics

go mod vendor copies the source of every dependency needed for the build into a vendor directory at the module root. That helps when builds must run offline or dependency code must be reviewed in-repo. When a vendor directory exists and the module's go version is recent enough, go build uses it automatically.

go mod vendor          # writes vendor/ and vendor/modules.txt
go build -mod=vendor   # use vendor explicitly
go build -mod=mod      # ignore vendor and use the module cache

After changing dependencies, rerun go mod vendor to keep the directory in sync. Most projects never need vendoring; the module cache plus a module proxy (GOPROXY) is enough. For private repositories, list their paths in GOPRIVATE so the go command fetches them directly and skips the public proxy and checksum database.

Summary

• go.mod records the module path and requirements, go.sum records checksums, and both are committed.
• Capitalized names are exported; internal narrows visibility further.
• Use go get module@version to add or change dependencies and go mod tidy to clean up.
• go install path@version installs tools without touching your module.
• go mod vendor copies dependencies into the repository; reach for it only when you need it.