Git Interview Questions for Experienced (3, 5 and 10+ Years) with Answers

Experienced Git interviews test judgement, not just commands. This guide covers the questions asked of developers, SDETs and DevOps engineers with several years of experience, with model answers and real-world scenarios.

---

🎯 What Experienced Git Interviews Test

For freshers, interviewers ask “what does git pull do?”. For experienced candidates (3, 5 or 10 years; developers, SDETs and DevOps engineers), they ask why and what would you do: how you keep history clean, recover from mistakes, structure branches for a team and integrate Git with CI/CD. Answer with the concept, a command, and a real situation where you used it.

For basics, start with GitHub interview questions and answers.

---

🧠 Concepts and Internals

🤔 What actually happens when you run git commit?

Git writes blob objects for staged file contents (via the index), tree objects for directories, and a commit object that points to the root tree, the parent commit(s), author, committer and message. It then moves the current branch reference to the new commit. See Git internals.

🤔 What is the difference between HEAD, the working tree and the index?

HEAD points to the current commit (usually through a branch), the index (staging area) holds the snapshot for the next commit, and the working tree is the files on disk. Commands like reset --soft/--mixed/--hard differ exactly in which of these three they change.

🤔 What is detached HEAD and how do you get out of it safely?

HEAD points directly to a commit instead of a branch, for example after checking out a tag or during bisect. To keep work done there, create a branch: git switch -c rescue-branch; otherwise git switch main.

🤔 Why does rebasing change commit hashes?

A commit’s hash covers its content, metadata and parent. Rebasing gives commits new parents, so Git creates new commits with new hashes; the originals remain reachable via the reflog for a while.

---

🔀 Branching, Merging and Rebasing

🤔 Merge vs rebase: what do you use, and when?

I rebase my own feature branch on main to keep it current and linear, and integrate into main through a pull request, usually with squash or merge commits depending on team policy. I never rebase shared branches. See rebase vs merge.

🤔 What is the golden rule of rebasing?

Do not rebase commits that others have based work on. If I rebase my pushed feature branch, I update it with --force-with-lease, never plain --force.

🤔 Explain fast-forward vs three-way merge and –no-ff.

Fast-forward just moves the branch pointer when the target has no new commits. A three-way merge creates a merge commit using the common ancestor. --no-ff forces a merge commit to keep the feature visible in history (merge).

🤔 How do you handle a large merge conflict in a critical file?

Abort if unprepared (git merge --abort), understand both sides with git log --merge and the PRs, resolve in a 3-way merge tool, involve the other author, run the tests, then commit. To reduce future conflicts: smaller PRs and frequent integration (conflicts).

🤔 How would you squash 10 commits before merging a PR?

git rebase -i main (or HEAD~10), mark later commits as fixup or squash, then git push --force-with-lease; or use “Squash and merge” on GitHub (interactive rebase).

🤔 When do you use cherry-pick?

To backport a specific fix to a release branch without bringing other changes, using -x for traceability (cherry-pick).

---

🛟 Recovery and Undo

🤔 A teammate ran git reset –hard and lost a day of work. Can you help?

If the work was committed, yes: git reflog shows previous HEAD positions; create a branch at the lost commit. Uncommitted changes cannot be recovered this way (reflog).

🤔 How do you undo a bad commit that is already on main and deployed?

git revert <hash> (or git revert -m 1 <merge-commit> for a merge), through a PR, then deploy. Revert keeps history intact; reset plus force push on main is not acceptable (undo changes).

🤔 Someone committed an API key and pushed it. What do you do?

First revoke and rotate the key. Then remove it from the code, and if required by policy, rewrite history with a tool such as git filter-repo and coordinate a re-clone with the team. Prevent recurrence with .gitignore, secret scanning and push protection (security).

🤔 How do you find which commit introduced a regression in a 500-commit range?

git bisect with a known good tag and the bad HEAD, ideally automated with git bisect run and a reproducing test: about nine steps for 500 commits (bisect).

---

🌳 Workflows and Team Practices

🤔 Which branching strategy have you used and why?

Example answer: “GitHub Flow with short-lived branches and squash merges, because we deploy several times a week and our automated tests run on every PR. For our mobile app we used a lighter Git Flow with release branches for app-store releases.” (branching strategies)

🤔 How do you protect the main branch?

Rulesets requiring a PR, at least one approval, Code Owner review for critical paths, required status checks, conversation resolution, and no force pushes or deletions (branch protection).

🤔 How do you keep commit history useful in a large team?

Conventional Commits enforced by commitlint and Husky, small PRs, squash merges, linked issues and tags for releases, which also enables automated changelogs (commit messages, hooks).

🤔 How do you share code between repositories?

Prefer versioned packages; use submodules when you need another repository’s exact source at a pinned commit; consider a monorepo when projects change together (submodules).

---

🚀 Git in CI/CD (SDET and DevOps Focus)

🤔 How is Git connected to your CI/CD pipeline?

Pushes and pull requests trigger workflows; branch names, tags and paths control which jobs run; required checks gate merges; tags trigger releases and deployments (GitHub Actions workflow syntax).

🤔 Why use a shallow clone in CI, and when is it a problem?

--depth 1 (the default in actions/checkout) is faster. It breaks tools that need history, such as changelog generators, git describe or diffing against main; then use fetch-depth: 0.

🤔 How do you run only tests affected by a change?

Use path filters on workflow triggers, or compare changed files with git diff --name-only origin/main...HEAD and map them to test suites or tags.

---

🧩 Scenario Round

🤔 You pushed to the wrong branch. What do you do?

If it is a shared branch, revert the commit there and cherry-pick it to the right branch. If it is your own branch, reset it and force-push with lease after cherry-picking to the correct branch.

🤔 Two teams need the same hotfix in release/2.3 and main. How?

Fix on main through a PR, then cherry-pick with -x into release/2.3 through a second PR; tag the patch release.

🤔 Your PR shows hundreds of unrelated changes. Why?

Usually the branch was based on the wrong branch or main was merged in with different line endings. Check git merge-base, rebase onto the correct base, and fix line-ending settings (core.autocrlf or .gitattributes).

---

💡 Interview Tips

• Prepare two real stories: recovering lost work and fixing a painful conflict or broken pipeline.
• Show your public projects: the team workflow and CI/CD pipeline projects make excellent talking points.
• Be ready to type commands live without an IDE; keep the cheat sheet in your revision notes.

---

❓ FAQ

🤔 What Git questions are asked for 5 years of experience?

Merge vs rebase decisions, interactive rebase, reflog recovery, revert vs reset on shared branches, bisect, branching strategies, branch protection, leaked secrets and Git in CI/CD.

🤔 How should I prepare for a Git interview as an SDET?

Practise the commands hands-on, prepare stories about collaboration and recovery, and be ready to explain how tests are triggered and gated in CI on pull requests.

🤔 Which Git topics do DevOps interviews focus on?

Branching strategies, tags and releases, hooks, protected branches, CI triggers, shallow clones and history rewriting policies.

---

🎯 Next Steps

• ⚙️ GitHub Actions Interview Questions
• 💼 GitHub Interview Questions and Answers
• 📘 Git and GitHub Tutorial: full course