Source Code Management and Version Control
What this domain tests
Source Code Management and Version Control tests Git mechanics and the branching and review policies that make delivery safe: the commit graph, merge versus rebase, trunk-based development, release tagging, monorepo versus polyrepo, and keeping secrets out of history.
Core rules and concepts
- Git stores snapshots: a commit points to a tree of blobs and parent commits. Branches are movable pointers; tags are labels, and annotated tags carry metadata.
- Trunk-based development keeps branches short-lived, from hours to a day or two, and integrates frequently. Long-lived feature branches increase merge risk and delay feedback.
- Merge preserves history and can create a merge commit; rebase rewrites commits onto a new base and must not be used on shared public history.
- Semantic Versioning uses MAJOR.MINOR.PATCH for breaking, additive, and fix changes respectively.
- Protect the main branch with required reviews, status checks, and signed commits where policy demands, and block direct pushes.
- Never commit credentials. If a secret enters history, rotate it first; rewriting history does not un-expose it.
Worked example
A production bug needs a one-line fix while main contains unreleased work. Reasoning: creating a long-lived hotfix branch from an old tag and merging it back weeks later invites drift. Better: branch from the release tag, fix, run CI, tag a patch release such as v1.4.2, deploy, then merge or cherry-pick the commit back to main immediately. The tag gives traceability; the immediate back-merge prevents regression in the next release.
Traps that cost marks
- Force-pushing to a shared branch and erasing colleagues' commits.
- Using mutable tags or reusing a release tag for a different commit.
- Believing .gitignore removes a secret that was already committed.
- Confusing "merged" with "released" or "deployed."
- Keeping a release branch alive indefinitely without a back-merge policy.