I85PREP
⌘ K
DevOps Engineering study materials
DevOps Engineering study resources

DevOps Engineering: Version Control, Branching, and Release Engineering

DevOps Engineering · Work through your exam, one topic at a time.

All guide sections

Version Control, Branching, and Release Engineering

This domain tests Git mechanics and the release process built on them: what a commit actually is, which integration strategy keeps the mainline releasable, and how versions, tags and hotfixes are produced.

Core rules

  • Git's model: a commit is a snapshot of a tree plus parent pointers; a branch is a movable ref; a merge creates a commit with two parents; rebase replays commits onto a new base and rewrites their hashes.
  • Rebase your own feature branch before review for linear history; never rebase a shared branch. After rewriting, force-push with --force-with-lease so you cannot silently discard someone else's commits.
  • Trunk-based development: short-lived branches (hours to days), small pull requests, feature flags to hide incomplete work, mainline always releasable. Long-lived develop and release branches accumulate merge debt; GitFlow suits versioned shipped software with parallel supported versions, not continuous deployment.
  • Merge queue: tests each pull request against the post-merge result, so mainline is never red; a failing batch is bisected to find the culprit.
  • Release engineering: annotated tags for releases, semantic versioning, Conventional Commits driving version bumps and changelogs, immutable retained artifacts per release, and a documented hotfix path - branch from the release tag, fix, tag a patch, forward-port to mainline.
  • Monorepos need path filters and CODEOWNERS; polyrepos need coordinated version pinning.

Worked example

Last release was v2.3.4. Since then: feat: add CSV export, fix: null pointer on empty cart, and a commit whose footer reads BREAKING CHANGE: remove /v1/orders. Reasoning: a breaking change forces a major bump regardless of the others; the feature would force a minor and the fix a patch, and the highest wins → v3.0.0. The 0.y.z exception matters: before 1.0.0 the API is not declared stable, so a breaking change bumps the minor (0.4.2 → 0.5.0). Tag the commit, generate the changelog from the range v2.3.4..v3.0.0, and publish the artifact built from that exact commit.

Traps

  • Squash-merging and then expecting original commit hashes in mainline - they are new commits.
  • Deleting a branch while its merge-queue entry is still running against that ref.
  • Hotfixing only on mainline or only on the release branch, so the next release reintroduces the bug.
  • Lightweight tags moved or reused between releases, breaking artifact-to-source traceability.