// Git Interview Guide · DevOps

Git Interview Questions & Answers: Rebase, Merge, Reflog & GitOps

📅 Updated April 2026 · 📅 April 2026 ⏱ 10 min read 🏷 Git · DevOps · GitOps · Version Control

👨‍💻

master.devops

Practising DevOps Engineer with deep hands-on experience in Kubernetes, AWS, CI/CD, and SRE. Every guide is written from real production work.

Git is the foundation of every DevOps workflow. But "I know Git" for an interview means more than knowing git commit and git push. Interviewers at product companies test your understanding of branching strategies, history manipulation, internal data structures, and how Git integrates into CI/CD and GitOps workflows. This guide covers every question I have encountered or asked in real DevOps interviews.

How Git Stores Data — The Foundation

Understanding Git internals is what separates senior engineers from juniors in interviews. Git does not store differences (diffs). It stores snapshots. Every commit is a snapshot of the entire repository at that point in time. Git uses a Directed Acyclic Graph (DAG) where each commit points to its parent(s). A branch is simply a lightweight, movable pointer to a commit.

    Four Git object types: Blob (file content), Tree (directory structure), Commit (snapshot
    with metadata and parent pointer), Tag (named reference to a commit). All stored as compressed objects in
    .git/objects/, addressed by their SHA-1 hash.
  

Merge vs Rebase — The Most Asked Question

This is the most common Git interview question in DevOps and SRE roles. The answer requires understanding both the mechanics and the appropriate use case for each.

git merge

Merge combines two branches by creating a new merge commit that has two parents. The branch history is fully preserved — you can see exactly when the feature branch was created and when it was merged. The history is non-linear (has a branch topology in the graph). Use merge when you want to preserve the full history of what happened and when.

git rebase

Rebase replays commits from one branch on top of another, creating new commits with different SHAs but the same changes. The result is a perfectly linear history with no merge commits. Use rebase to keep a feature branch up-to-date with main before raising a PR, or to squash WIP commits before merging.

The golden rule of rebasing: Never rebase a branch that others are working on. Rebase rewrites history (creates new SHAs). If you force-push a rebased shared branch, every team member's local copy becomes incompatible. Only rebase your own private feature branches.

# Keep feature branch up-to-date with main (before PR)
git checkout feature/JIRA-123
git rebase main
# Resolve any conflicts, then:
git rebase --continue
# If it goes wrong:
git rebase --abort

# Squash last 3 commits before PR
git rebase -i HEAD~3
# In the editor: change 'pick' to 'squash' for commits to combine

# Merge feature branch (preserves topology)
git merge --no-ff feature/JIRA-123  # always create merge commit

Branching Strategies

GitFlow

GitFlow uses two permanent branches (main and develop) plus three supporting branch types (feature, release, hotfix). Features branch from develop and merge back. Releases branch from develop, get stabilised, and merge to both main and develop. Hotfixes branch from main directly.

Best for: Products with distinct release versions (mobile apps, desktop software, SaaS with versioned APIs). Not good for: Web services with continuous deployment — long-lived branches create merge conflicts and delay integration.

Trunk-Based Development

All developers commit to a single trunk branch (main) daily. Feature flags hide incomplete features from users without hiding them from deployment. Feature branches are very short-lived (hours, not days). This is the branching strategy used by Google, Facebook, and most DevOps-mature organisations.

Best for: Teams with CI/CD, high deployment frequency, strong test coverage. Requires feature flags and a mature CI pipeline to be safe.

Essential Git Commands for DevOps

# View history
git log --oneline --graph --all --decorate
git log --author="master.devops" --since="1 week ago"
git diff HEAD~3 HEAD -- src/api.py   # changes in specific file over 3 commits

# Undo mistakes
git revert HEAD                      # safe undo — creates a new commit
git reset --soft HEAD~1              # undo commit, keep staged
git reset --mixed HEAD~1             # undo commit, keep unstaged
git reset --hard HEAD~1              # ⚠️ undo commit AND discard changes

# Reflog — the safety net
git reflog                           # history of ALL HEAD movements (90 days)
git checkout HEAD@{5}                # go back to 5 positions ago
# Even git reset --hard can be undone with reflog!

# Stash — temporary shelving
git stash push -m "WIP: user auth feature"
git stash list
git stash pop                        # apply and remove from stash
git stash apply stash@{0}            # apply without removing

# Cherry-pick — apply specific commits
git cherry-pick abc1234              # apply one commit to current branch
git cherry-pick abc1234..def5678     # apply a range of commits

# Bisect — binary search for bug-introducing commit
git bisect start
git bisect bad                       # current commit is broken
git bisect good v1.0.0               # this tag was working
# Git checks out midpoint — test it, then:
git bisect good / git bisect bad     # repeat until found
git bisect reset

Git in GitOps Workflows

In a GitOps workflow (ArgoCD, Flux), Git is not just version control — it is the control plane for all infrastructure and application deployments. The CI pipeline updates image tags in the GitOps repository by committing directly. ArgoCD detects the commit and applies the change to Kubernetes. Rollback = git revert. Audit trail = Git history.

Interview Q&A

Q1: What is a detached HEAD state?

HEAD normally points to a branch name, which in turn points to the latest commit. Detached HEAD means HEAD points directly to a commit SHA, not a branch. You are in detached HEAD when you run git checkout <sha> or git checkout v1.0.0. Any commits you make are not attached to any branch and will be garbage-collected eventually. To save your work: git checkout -b new-branch-name to create a branch at the current position.

Q2: How do you recover a deleted branch?

Use reflog: git reflog shows every HEAD position for the last 90 days. Find the SHA of the last commit on the deleted branch, then git checkout -b recovered-branch <sha>. If the branch was pushed to a remote before deletion, git checkout -b recovered-branch origin/deleted-branch may still work if the remote has not been pruned. Always push feature branches to remote before deleting locally — this is the real safety net.

Q3: What is git cherry-pick and when do you use it?

Cherry-pick applies the changes of a specific commit onto the current branch as a new commit. Use cases: a hotfix was committed to main and needs to be applied to a release branch, a useful refactor on a feature branch is needed in a different feature branch, or a commit was accidentally made to the wrong branch and needs to be moved. Avoid cherry-pick as a regular workflow — it creates duplicate commits with different SHAs, complicating history. It is a surgical tool, not a branching strategy.

// More Guides

📖 DevOps ☸️ Kubernetes 🐳 Docker ⚙️ CI/CD 🗂️ Terraform 🐧 Linux 🌿 Git ☁️ AWS 📊 Prometheus

🌿 Explore Git on the Interactive Mind Map

See how Git connects to GitHub Actions, Jenkins, ArgoCD, and SonarQube — the full DevOps toolchain.

Open Interactive Mind Map Next: CI/CD Guide →

🚀 Want the complete DevOps interview kit?

Full notes, Q&A cheat sheets, real commands — all tools covered.

💳 Get Complete DevOps Kit →

Git is where every CI/CD pipeline starts. Learn how code goes from a git push all the way to production with CI/CD →

📩 Get Free DevOps Interview Notes

Cheat sheets, real commands, interview Q&As — free.

No spam · Follow @master.devops for daily tips

// Continue Learning

⚙️CI/CD — Git triggers every pipeline run 📖DevOps — Git is the foundation of DevOps culture ☸️Kubernetes — GitOps: K8s state declared in Git

How Git Works Internally

Most engineers use Git every day without understanding what happens under the hood. Understanding Git's internal model — objects, references, and the index — makes you dramatically better at resolving complex situations like merge conflicts, accidental commits, and corrupted histories.

  Git's four object types: blob (file content), tree (directory listing), commit (snapshot + metadata),
  tag (pointer with message). Every object is content-addressed — its SHA-1 is a hash of its content.
  This is why Git history is immutable and tamper-evident by design.

# Explore Git internals
git cat-file -t HEAD          # type of HEAD object (commit)
git cat-file -p HEAD          # contents of HEAD commit
git cat-file -p HEAD^{tree}   # the root tree object
git ls-files --stage          # show the index (staged files)
ls .git/                      # HEAD, config, objects/, refs/

Rebase vs Merge — When to Use Each

This is one of the most common Git questions in DevOps interviews. The answer is not "always rebase" or "always merge" — it depends on context. Understanding the trade-offs is what interviewers test for.

Scenario	Merge	Rebase
Integrating completed feature → main	✅ Preserves audit trail	Loses branch context
Syncing local feature with latest main	Creates noisy merge commits	✅ Keeps linear history
Shared/public branch (main)	✅ Safe	❌ Never rebase shared branches
Local WIP commits before PR	Unnecessary	✅ Squash with interactive rebase

# Interactive rebase — clean up commits before PR
git rebase -i HEAD~4          # reword/squash/drop last 4 commits

# Sync feature branch with main (preferred over merge for local branches)
git fetch origin
git rebase origin/main
# If conflicts: fix → git add → git rebase --continue

git reflog — Your Safety Net

git reflog records every HEAD movement for 90 days, regardless of whether the commit is reachable from any branch. This is the most important command for recovering from disasters.

# Scenario: accidentally ran git reset --hard
git reflog                    # find the SHA before the reset
git checkout -b recovery abc1234  # restore to new branch

# Scenario: deleted a branch by accident
git reflog | grep "branch-name"
git checkout -b branch-name SHA_FROM_REFLOG

Production rule: Before any destructive operation, write down the current SHA: git rev-parse HEAD. If anything breaks, git reset --hard <that-sha> will restore you.

Branching Strategies in DevOps Teams

Strategy	Best For	Trade-off
Trunk-Based	Teams deploying multiple times/day	Requires feature flags and strong test coverage
GitFlow	Scheduled releases, multiple versions in prod	Overhead of develop/release/hotfix branches
GitHub Flow	Continuous deployment, single prod version	Less structure around releases

Git Interview Questions & Answers

Q: What is a detached HEAD state and how do you fix it?

A detached HEAD means HEAD points directly to a commit SHA instead of a branch name. This happens when you git checkout <sha> or checkout a tag. Any commits made in this state are not tracked by any branch and will be lost after switching away. Fix: git checkout -b new-branch to capture your work, or git checkout main to discard. Work can always be recovered from reflog.

Q: What is the difference between git reset and git revert?

git reset moves HEAD backwards — it rewrites history. --soft keeps staged changes, --mixed unstages, --hard discards everything. Never use reset on shared branches. git revert <sha> creates a new commit that undoes the target — history is preserved. The rule: reset for local/private branches only, revert for anything pushed to shared remotes.

Q: How do you squash commits before a pull request?

git rebase -i HEAD~N where N is the number of commits to squash. In the interactive editor, change pick to squash on commits to combine into the previous one. After saving, Git opens another editor to write the combined commit message. GitHub/GitLab also offer a "Squash and merge" button on pull requests.

Q: How do you cherry-pick a commit from one branch to another?

git cherry-pick <sha> applies a specific commit to the current branch. Useful for backporting a bug fix from main to a release branch without merging everything else. git cherry-pick A..B applies a range. If conflicts arise: resolve → git cherry-pick --continue. Cherry-picking creates a new commit with a new SHA — the original commit remains unchanged on its source branch.

🔗 Related DevOps Topics

🐳 Docker ☸️ Kubernetes 🗂️ Terraform 🐧 Linux ☁️ AWS ⚙️ CI/CD 📊 Prometheus 🌿 Git 📖 DevOps 🗺️ Mind Map