Git Basics for Go Projects

10 examples to get you started with Git & GitHub - 7 basic and 3 intermediate.

Prerequisites

• Install Git 2.40+ and Go 1.26.x from go.dev/dl.
• Configure identity: git config --global user.name "You" and git config --global user.email "you@example.com".
• Have SSH or HTTPS access to your module host (GitHub, GitLab, etc.).
• For private modules, set GOPRIVATE to your org prefix, for example export GOPRIVATE=github.com/myorg/*.

Basic Examples

1. Clone a Go module repository

Start from the remote that matches your go.mod module path.

git clone git@github.com:myorg/widget.git
cd widget
go test ./...

• Clone URL should match where go get resolves the module.
• Run tests immediately to verify toolchain and module cache access.
• go.mod at the repo root defines the module path for imports.

Related: Git for Go Teams - why Git and modules share a release story

2. Check status before touching go.mod

See tracked changes and whether dependency files drifted.

git status
git diff go.mod go.sum

• go.mod / go.sum diffs often mean dependency or tidy changes.
• Untracked binaries usually mean .gitignore needs /bin/ or *.exe.
• Commit dependency file changes in the same PR as code that caused them.

Related: go.mod, go.sum & Minimal Version Selection - what those files mean

3. Create a feature branch

Keep main releasable; branch per change.

git switch -c feat/add-metrics

• Use short, descriptive branch names (fix/nil-panic, feat/grpc-health).
• One logical change per branch keeps PR review and bisect simple.
• Rebase or merge from main frequently to avoid go.sum conflicts.

Related: Branching Strategies & Trunk-Based Flow - trunk-based habits

4. Stage and commit Go sources

Commit compilable units with clear messages.

git add internal/metrics/collector.go internal/metrics/collector_test.go
git commit -m "metrics: add process collector"

• Include _test.go files with the code they cover.
• Avoid committing go test binaries or profile outputs.
• Message style package: verb matches many Go project conventions.

5. Record dependency changes

After go get or import edits, tidy and commit module files.

go get golang.org/x/sync@v0.10.0
go mod tidy
git add go.mod go.sum
git commit -m "go.mod: bump golang.org/x/sync"

• go mod tidy drops unused requires and adds missing indirects.
• Review go.sum growth for unexpected transitive modules.
• CI should fail if tidy would change files post-merge.

6. Push branch and open a PR

Publish work for review without tagging a release yet.

git push -u origin feat/add-metrics

• -u sets upstream so later git push / git pull work without extra args.
• Open a pull request against main with test plan and module impact noted.
• Wait for go test ./... CI before merging.

Related: Code Review with GitHub PRs - PR size and module-aware review

7. Pull latest trunk before merge

Integrate others' changes and re-run tests.

git switch main
git pull --ff-only
git switch feat/add-metrics
git merge main
go test ./...

• --ff-only on main avoids accidental merge commits when updating local trunk.
• Resolve go.sum conflicts carefully; re-run go mod tidy after resolution.
• Never merge with failing tests or uncommitted tidy diffs.

Intermediate Examples

8. Inspect history for a regression

Use Git history with Go's fast bisect workflow.

git log --oneline -n 10
git bisect start
git bisect bad
git bisect good v1.3.0
go test ./internal/parse -run TestDecode

• git bisect pairs well with focused go test package flags.
• Tag names like v1.3.0 are valid bisect boundaries for released modules.
• Document bisect result in the fix PR for future readers.

Related: Rebasing, Cherry-Pick & Worktrees - history hygiene tools

9. Create a semver release tag

Tag the commit you want module consumers to resolve.

git switch main
git pull --ff-only
go test ./...
git tag -a v1.4.0 -m "v1.4.0: metrics collector"
git push origin v1.4.0

• Use annotated tags (-a) for releases; they carry message and tagger metadata.
• Tag only after CI green on the exact commit.
• Consumers run go get github.com/myorg/widget@v1.4.0 after the proxy indexes the tag.

Related: Signed Tags & Go Module Releases - signing and proxy behavior

10. Stash WIP and use a worktree

Parallel work without clashing go build outputs.

git stash push -m "wip metrics" -- internal/metrics
git worktree add ../widget-hotfix main
cd ../widget-hotfix
go test ./...

• Stash paths to avoid sweeping unrelated go.mod experiments.
• Worktrees give a second checkout sharing one .git database.
• Each worktree needs its own go test run; module cache is shared.

Related: Monorepo Git Patterns with go work - multiple modules, one repo

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).