Source Control & Git8 min read•October 2026•Kernelry Staff

Git Branching, Merge Conflicts & Version Control Scenarios

In modern DevOps pipelines, Git serves as the single source of truth for application code and infrastructure manifests. Technical interviewers evaluate whether candidates deeply understand Git internals (trees, blobs, commits, refs), how to cleanly resolve complex merge conflicts, when to rebase versus merge, and how to rescue accidentally deleted branches using the reflog.

Architecture Blueprint

Git Commit Graph: Merge vs Rebase Topology

Visual comparison of a three-way merge commit preserving branch history versus replaying commits sequentially via rebase for linear history.

The Core Concept

Git is a distributed version control system that records changes to code as a directed acyclic graph of immutable snapshots. Every developer checkout contains the entire repository history, enabling fast branching, offline commits, and distributed collaboration across teams.

Key Rules of Thumb for Production Systems

•Git stores commits as snapshots in a content-addressable object database keyed by SHA hashes.

•Rebase rewrites commit history onto a new base commit for linear history; merge preserves chronological branching topology.

•The git reflog records every local HEAD movement, allowing recovery of deleted commits and aborted rebases.

•Use git bisect to perform a binary search across commit history to pinpoint the exact commit that introduced a production regression.

Why Production Systems Demand This Depth

A mishandled force push or corrupt rebase can erase days of team work, block production CI/CD deployments, and break GitOps synchronization loops. Knowing how to navigate commit histories, bisect regressions, and maintain linear commit hygiene is fundamental for infrastructure engineers.

Common Diagnostic Pitfalls

•Force pushing (git push -f) to shared collaboration branches like main without using --force-with-lease.
•Rebasing public shared branches, causing divergent history conflicts for other team members.
•Committing secret credentials (.env files, private keys) into Git history without proper BFG/filter-repo purging.
•Creating massive merge conflicts by neglecting to regularly pull and integrate upstream changes.

Best Practices for Scenario Drills

•Clearly articulate the difference between git reset --soft, --mixed, and --hard.
•Explain how git reflog acts as a safety net because Git does not garbage collect unreachable commits immediately.
•Discuss how trunk-based development compares to Gitflow for accelerating high-velocity CI/CD delivery pipelines.

Worked Production Scenarios

Study real-world outage patterns, diagnostic trees, and clarifying questions.

Recovering an Accidentally Deleted Feature Branch

Difficulty: junior

Scenario Prompt:

“A developer ran git branch -D feature-billing after believing it was merged into main. It was not merged, and the remote branch was also pruned. The branch held two days of commits that were never pushed. How do you recover the branch?”

Substantive Technical Concepts to Hit:

Inspect Local Reflog

Run git reflog to inspect recent HEAD movements and identify the SHA hash of the last commit made on the deleted branch.

Recreate Branch from Commit Hash

Execute git checkout -b feature-billing <commit-sha> to restore the branch pointing to the recovered commit.

Dangling Commit Verification

If the commit does not appear in reflog, use git fsck --lost-found to search the object database for unreferenced dangling commits.

Branch Protection Policies

Configure remote branch protection and deletion restrictions on production repositories to prevent accidental remote branch loss.

Senior Clarifying Questions to Investigate:

Was the branch deleted locally on the developer workstation where commits were originally created?
Has git gc --prune=now been executed since the deletion occurred?
Do we need to back up the current .git directory before attempting object surgery?

An API Key Was Pushed to a Public Repository

Difficulty: mid

Scenario Prompt:

“A developer committed a cloud API key in a config file and pushed it to a public GitHub repository an hour ago. They deleted the file in a new commit. Is the problem solved, and what do you do?”

Substantive Technical Concepts to Hit:

Revoke First

Deleting the file in a new commit leaves the key in history, and public repositories are scanned for secrets within minutes. Treat the key as compromised: revoke or rotate it before touching history, then check the provider audit logs for use since the push.

Rewriting History

git filter-repo (or BFG Repo-Cleaner) removes the file from every commit. Every branch and tag that contained it must then be force-pushed, which changes commit hashes for everyone.

Copies Outside the Repository

Existing clones, forks, open pull requests and CI caches still hold the old commits. Collaborators need to re-clone, and the hosting provider may need a support request to purge cached views of the old commits.

Preventing a Repeat

Add secret scanning before code leaves the laptop (a pre-commit hook running gitleaks or similar) and turn on server-side push protection so a push containing a known key format is rejected.

Senior Clarifying Questions to Investigate:

How narrowly was the key scoped, and what could it reach in the hour it was public?
Which open branches or pull requests are based on the commits that will be rewritten?
Are there build artifacts or container images that baked the config file in?

Interactive Scenario Drills

That's where we come in.

Explaining architectural trade-offs under time constraints is very different from reading about them.

Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.

Start Today's Free Drill

Back to All Blog Posts