All jobs / DevOps / SRE / cloud

Git interview questions

Git questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. When do you rebase, and when must you never?

   The strongest answer: Rebase my own unpushed or personal branch onto main to keep history linear; never rebase a branch others have pulled or built on — rewriting shared history forces everyone to reconcile

   Why it works: Exactly — rebase rewrites commits, which is fine for history only you hold and harmful for history others hold.

   • Rebase private history only.
   • Shared branches get merges.
   • Rewriting is rewriting for everyone.
   • Force-push is not a fix.

2. A commit on main broke the build; three teammates have already pulled it.

   How do you undo it?

   The strongest answer: `git revert` the commit — a new commit that inverts it — push, and fix forward afterwards; history stays intact for everyone who already pulled

   Why it works: Right — revert is the safe undo on shared history: it is additive, instant and reviewable.

   • Revert, do not rewrite.
   • Restore green first.
   • Then fix forward.
   • Never force-push main.

3. What is a git tag for in a release pipeline?

   The strongest answer: An immutable name — an annotated semver tag such as v2.3.1 — on the exact commit the release was built from; the pipeline builds from the tag and stamps the artifact with it; tags never move

   Why it works: Exactly — the tag is the contract between “what we shipped” and “what is in git”. Immutable and annotated, or it is not a release.

   • Tag equals shipped commit.
   • Annotated, semver, immutable.
   • Build and stamp from the tag.
   • Never move a tag.

4. Production runs v2.3.0. main has two weeks of unreleased work. A critical bug must ship today.

   What is your release workflow for this?

   The strongest answer: Branch from the v2.3.0 tag, fix and test there, tag v2.3.1 and deploy it; then merge or cherry-pick the fix into main so the next release does not regress

   Why it works: Right — ship only the fix, on top of what is actually running, and close the loop with main. Both halves matter.

   • Branch from what is running.
   • Ship only the fix.
   • Tag the patch release.
   • Merge the fix back to main.

5. p95 latency doubled somewhere in the 60 commits between last week’s release and today’s. Nothing in the diffs jumps out.

   How do you find the commit?

   The strongest answer: `git bisect` between the good and bad tags with a script that reproduces the measurement — each step halves the range, so about six builds instead of sixty

   Why it works: Exactly — bisect turns a linear hunt into a binary search, and a reproducible check makes it mechanical.

   • Binary search, not linear reading.
   • Fix a good and a bad commit.
   • Script the reproduction.
   • Let bisect drive the checkout.

6. Twenty teams. Half deploy from main daily; the rest run Gitflow with release branches that live for weeks and merge back painfully.

   What do you standardise, and where do you allow a difference?

   The strongest answer: Trunk-based as the default — short-lived branches, feature flags, releases tagged from main — with release branches allowed only where the cadence truly differs, such as app-store or on-premises releases

   Why it works: Right — one default that matches daily delivery, and a named, justified exception for cadences that cannot follow it.

   • Trunk-based by default.
   • Short branches, flags, tags from main.
   • Exceptions for real cadence differences.
   • Never per-customer branches.