Git Interview Questions: What Senior DevOps and SRE Roles Actually Ask

Q1: What is the difference between git merge and git rebase?

Both integrate changes from one branch into another. Merge creates a new merge commit with two parents, preserving the exact history of when branches diverged and reconnected. Rebase replays commits from one branch on top of another, producing a linear history without a merge commit.

Use merge when you want to preserve the branch topology (feature development visible in history). Use rebase to clean up a local feature branch before opening a PR. Never rebase commits that have been pushed to a shared branch — it rewrites hashes and causes conflicts for anyone who pulled the original commits.

---

Q2: What does `git reset` do? What are the three modes?

git reset <commit> moves the current branch pointer to a different commit.

--soft: moves the branch pointer; staged changes and working directory unchanged. Files appear as staged.
--mixed (default): moves the branch pointer; staged index reset to match the commit. Files appear as unstaged modifications.
--hard: moves the branch pointer AND resets the working directory. Discards all changes — use carefully.

git reset HEAD~1           # undo last commit, keep changes unstaged
git reset --soft HEAD~1    # undo last commit, keep changes staged
git reset --hard HEAD~1    # undo last commit, discard all changes

---

Q3: How do you undo a commit that has already been pushed?

git revert <commit>    # creates a new commit that undoes the changes
git push origin main

revert is safe for shared branches — it adds a commit rather than rewriting history. reset --hard + force push would rewrite history and break everyone who pulled the original commit.

---

Q4: What is the difference between `git fetch` and `git pull`?

git fetch downloads remote changes into remote-tracking branches (origin/main) without modifying your local branches. You can inspect what changed before merging.

git pull = git fetch + git merge (or git rebase if configured). It immediately integrates the changes.

Prefer fetch + explicit merge or rebase in automation and CI scripts — it is more explicit about what happens.

---

Q5: How do you find which commit introduced a specific string?

git log -S "function authenticateUser" --oneline    # commits that added/removed this string
git log -G "function auth.*" --oneline              # commits matching a regex
git log --all -p | grep -n "authenticateUser"       # search in diffs

---

Q6: Explain what `git reflog` is and when you use it.

git reflog records every position the HEAD has been at locally — including commits that are no longer reachable from any branch. It is your safety net for recovering from:

Accidental git reset --hard
Accidentally deleted branches
Botched rebases

git reflog             # see HEAD history
git checkout abc1234   # go back to a previous HEAD position
git branch recovered-branch abc1234  # create a branch from it

Reflog entries expire after 90 days (configurable). They are local — not shared via push/pull.

---

Q7: How do you squash multiple commits into one?

# Interactive rebase — squash last 4 commits
git rebase -i HEAD~4

In the editor, change pick to squash (or s) for commits you want to fold into the one above. Write a new commit message for the combined commit.

Alternatively, soft-reset and recommit:

git reset --soft HEAD~4
git commit -m "feat: complete auth refactor"

---

Q8: You accidentally committed a secret (API key) to a public repository. What do you do?

Immediate actions:

Revoke the key immediately — assume it is already compromised
Issue a new key
Remove from the repository history

Removing from history:

git filter-repo --path secrets.env --invert-paths
# or for a specific string:
git filter-repo --replace-text <(echo 'literal:AKIAIOSFODNN7EXAMPLE==>REMOVED')

Force-push all branches: git push --force --all
Ask GitHub support to clear caches

Even after this, treat the key as permanently compromised — GitHub may have cached it, and anyone who cloned the repo before has it.

---

Q9: What is `git stash` and when would you use it over a WIP commit?

git stash saves uncommitted changes to a stack so you can restore them later. It is useful for quick context switches (you need to pull latest, switch branches, or test something unrelated).

For longer interruptions (more than an hour), a WIP commit is safer — it cannot be accidentally dropped with git stash clear, it is easier to inspect with git log, and it can be pushed to back up your work.

---

Q10: How do you handle a merge conflict?

git merge feature/auth
# CONFLICT (content): src/auth.js

# Open the file, look for conflict markers
# <<<<<<< HEAD
# ... your changes ...
# =======
# ... their changes ...
# >>>>>>> feature/auth

# Resolve manually or with a merge tool
git mergetool      # opens configured diff tool

# After resolving
git add src/auth.js
git merge --continue

Abort if you need to start over:

git merge --abort

---

Q11: What is the difference between `origin` and `upstream`?

By convention: origin is your fork or personal copy of a repository. upstream is the original repository you forked from.

git remote -v    # see current remotes
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git merge upstream/main    # bring in changes from the original repo

---

Q12: How does git store data internally?

Git stores everything as objects: blob (file contents), tree (directory), commit (snapshot + metadata + parent pointer), tag (annotated tag). Each object is identified by its SHA-1 (now SHA-256 in newer Git) hash of its contents. This is why Git is content-addressed — the same content always has the same hash.

A commit points to a tree (root of the filesystem snapshot). The tree points to blobs (file contents) and other trees (subdirectories). This structure makes branching cheap — a branch is just a pointer to a commit, and creating a branch takes constant time regardless of repository size.

Practice Git in the ShellGenius Git Labs — 25 challenges covering branching, rebasing, and recovery scenarios.