What is Git and how does it differ from centralized version control systems like SVN?

Start by saying Git is a distributed version control system that records snapshots of your project history and lets each clone act as a full repository. Explain that unlike centralized systems, every contributor has the full history locally and can commit, branch, and inspect history without network access. Give a concrete example: in Git you can make local commits, create a branch, and later push changes to a remote, while in SVN most actions require talking to the central server. That means operations like checking history, creating branches, and bisecting are faster and available offline. Tip the interviewer that teams often choose Git for its cheap branching and local workflows, but note that centralized tools have simpler access control models. Avoid saying one is always better; focus on tradeoffs and how you adapted to the team’s tooling.

Explain branching and merging in Git and when you would use feature branches.

Open with a clear approach: branching creates a pointer to a commit so you can develop isolated changes, and merging integrates those changes back into another branch. Describe that branches are lightweight in Git and encourage short-lived feature branches tied to a single change or story. Give a practical example: create a branch for a bugfix, commit multiple times, open a pull request, and merge into main after review. Explain that you rebase interactive to clean commits before merging when history clarity matters, or use merge commits when you want a clear record of branch integration. Add tips on collaboration: prefer small, focused branches and frequent pushes to a remote so others can review and run CI. Warn against extremely long-lived branches which increase merge conflicts and integration pain.

What is git rebase and how does it differ from git merge?

Start by describing the goal: rebase moves commits to a new base, rewriting history so it appears as if changes were made sequentially, while merge creates a new commit that joins histories. Explain that rebase produces a linear history, whereas merge preserves the true branching structure with merge commits. Give an example workflow: you might rebase a feature branch on top of updated main to apply your commits cleanly, then fast-forward or merge; conversely, you would merge when you want a record of the branch integration. Note that interactive rebase lets you squash, edit, or reorder commits to improve history readability before sharing. Offer a safety tip: never rebase public shared history because rewriting published commits breaks others’ clones. When in doubt, use merge for shared branches and rebase for private, local branches before pushing.

How do you resolve a merge conflict? Walk me through your steps.

Describe a calm, stepwise approach: identify conflicting files from Git’s output, open the conflicted files, and inspect the conflict markers to understand both sides. Explain you decide which changes to keep, possibly combine both, then remove conflict markers and run tests to verify behavior. Give a concrete technique: use git status to see files, open each file in an editor or use git mergetool to visualize differences, then git add the resolved files and git commit to finish the merge. If you made a mistake, you can always run git merge --abort or reset to the pre-merge commit to restart the process. Share collaboration tips: when conflicts are complex, talk to the author of the other changes to agree on the correct behavior before resolving. Avoid resolving conflicts by blindly choosing one side; always run tests and check the application behavior after resolving.

What is git stash and when should you use it?

Explain that git stash temporarily saves your uncommitted changes so you can switch branches or pull without committing unfinished work. Clarify that stashed changes are stored on a stack and can be reapplied later with git stash apply or popped with git stash pop. Give a practical example: if you need to fix a critical bug on main but have half-done work on your feature branch, stash your changes, switch to main, fix and push the hotfix, then return and reapply the stash. Mention named stashes with git stash save "message" to make identification easier. Warn about stash conflicts and lost context: stashes are not substitutes for small logical commits, so prefer committing to a work-in-progress branch if you want traceable history. Clean up your stash list periodically to avoid confusion.

How does Git store data internally, and what are blobs, trees, and commits?

Start with the object model: Git stores data as objects in the repository database, primarily blobs, trees, commits, and tags. Explain each briefly: blobs hold file content, trees record directory structure and links to blobs, commits point to a tree and contain metadata and parent commit references. Give an example of how a change maps to objects: when you commit, Git writes new blob objects for changed files and a new tree representing the project snapshot, then creates a commit object referencing that tree and previous commit. This content-addressable model makes history immutable and enables efficient operations like deduplication. Provide a troubleshooting tip: use git cat-file -p and git rev-list to inspect objects when diagnosing mysterious history issues. Remember that manipulating objects directly is advanced, so prefer porcelain commands unless you know the risks.

How would you revert a bad commit that has already been pushed to a shared remote?

Explain that to undo a pushed commit safely, you usually create a new commit that reverses the bad change using git revert, which preserves history and avoids rewriting shared commits. Clarify that resetting and force-pushing rewrites history and should be avoided on branches others use unless the team agrees. Give an example command: run git revert to generate a new commit that undoes the changes, then push the revert to the remote so collaborators receive the fix. If the bad commit is part of a series you want removed and everyone consents, you can use interactive rebase and force-push, but communicate clearly with the team first. Offer a communication tip: when a force-push is necessary, coordinate with the team, document the steps, and ensure everyone knows how to update their local branches to avoid confusion. Prioritize safe options like revert when working on shared branches.

What is git cherry-pick and when should you use it?

Define cherry-pick as a command that applies the changes introduced by a specific commit onto your current branch, creating a new commit with the same changes. Explain that it is useful for picking bugfixes or small, isolated changes from one branch into another without merging entire history. Provide a usage example: if a hotfix was committed to main and you need that fix on a release branch, you can checkout the release branch and run git cherry-pick to copy the change. Mention that cherry-pick can create duplicate commits across branches, so track origin carefully to avoid confusion. Warn about conflicts and history complexity: cherry-picking often leads to conflicts if the context differs, and heavy use can make it harder to trace where changes originated. Prefer backport strategies that fit your release workflow, and document cherry-picked commits with clear messages.

How do you handle large binary files in Git repositories?

Start by explaining that Git is optimized for text and storing many large binaries in the main repo can bloat the repository and slow down clones. Recommend using an extension like Git Large File Storage (Git LFS) to store pointers in the repo while keeping actual binary content in a separate store. Give a step-by-step example: install Git LFS, run git lfs track "*.psd" to add patterns, commit the .gitattributes file, and push; Git LFS will then manage the large files outside the primary object store. For already bloated repos, use git lfs migrate to move large files into LFS and reduce repo size. Advise planning file handling early and adding large file rules to project onboarding to prevent history bloat. Avoid committing large binaries directly and educate contributors on the chosen approach.

What are some common Git workflows teams use and how do you choose one?

Outline a few standard workflows: GitFlow uses long-lived develop and release branches with explicit release steps, GitHub Flow favors small feature branches merged into main with continuous deployment, and trunk-based development encourages very short-lived branches or direct commits to main. Explain that the choice depends on release cadence, team size, and risk tolerance. Give a decision technique: for small teams shipping often, prefer trunk-based or GitHub Flow to reduce merge complexity, while regulated or large teams may adopt GitFlow for clearer release separation. Consider CI requirements, code review practices, and deployment strategies when selecting the workflow. Recommend documenting the chosen workflow in a CONTRIBUTING guide and running a short onboarding session so everyone follows the same process. Revisit the workflow periodically and adjust when the team’s needs change.

Tell me about a time you resolved a critical merge conflict under time pressure.

Situation and Task: Our team had a blocker one hour before a release because two developers had conflicting changes to a core module, and CI was failing. You needed to resolve the conflict quickly and ensure the release could proceed without introducing regressions. Action: You inspected the conflict markers, ran the failing tests locally to reproduce the issue, and identified the intended behavior by checking the pull request descriptions and talking to both authors. You implemented a combined resolution that preserved the required API behavior, updated tests to cover the merged case, and pushed the fix with a clear commit message. Result: The CI pipeline passed and the release went out on time, and the added tests prevented the same conflict from regressing in future merges. The team adopted a small pre-merge checklist to avoid similar last-minute conflicts.

Describe a time you introduced or improved a branching strategy across a team.

Situation and Task: The team had inconsistent branching, causing delayed reviews and frequent integration issues, so you were asked to propose a clearer branching strategy. Your goal was to reduce merge conflicts and speed up reviews while fitting the release cadence. Action: You audited recent branches and release issues, then proposed a lightweight GitHub Flow with protected main, short-lived feature branches, and a rule that every branch must have an associated ticket and a passing CI build. You ran a half-day workshop demonstrating the workflow, created templates for PR descriptions, and added branch protection rules to enforce checks. Result: Review times dropped and the number of integration conflicts decreased by a measurable margin within two months, and the team felt more confident merging small changes frequently. The documented workflow became part of onboarding for new hires.

Give an example when you had to recover from an accidental deletion or repository issue.

Situation and Task: A junior engineer accidentally force-pushed and removed recent commits from a shared branch, and the team needed to recover lost work without impacting other contributors. You were tasked with restoring the important commits and communicating next steps. Action: You used the reflog and the remote’s object database to identify the commit hashes that contained the lost work, created a recovery branch pointing to the correct commit, and reviewed those commits to ensure they were complete. You then coordinated with the team to reset the shared branch to the recovery branch, after notifying everyone and instructing them how to update their local branches. Result: The lost work was restored with minimal disruption and no data loss, and you documented the recovery steps and best practices to prevent future force-push mistakes. The team agreed on protected branch policies to reduce the risk of accidental deletions.

git Interview Questions: Complete Guide

Git interviews often test both concepts and practical workflows, so expect a mix of conceptual questions, live problem solving, and scenario-based discussion. You will be asked to explain how Git stores history, demonstrate common commands, and show how you handle merge conflicts and collaboration in a team. Stay calm, speak through your steps, and show you can apply Git to real development workflows.

Common Interview Questions

Behavioral Questions (STAR Method)

STAR Method: Structure your answers using Situation, Task, Action, and Result to tell compelling stories about your experience.

Questions to Ask the Interviewer

Show your interest by asking thoughtful questions

•How does the team handle branching and release management for this codebase?
•What continuous integration and deployment checks run on pull requests, and who owns those pipelines?
•Can you describe a recent Git-related incident the team faced and how you resolved it?
•How do you handle hotfixes and backports across multiple release branches?
•What conventions do you expect for commit messages, pull request descriptions, and changelog generation?

Interview Preparation Tips

Practice common commands in a disposable repo so you can run through branching, merging, rebasing, and recoveries without fear.

When answering, narrate your steps out loud so interviewers can follow your reasoning and spot gaps, especially during live problem solving.

Prepare a short script for how you explain Git concepts, then practice it so explanations are concise and clear under pressure.

Bring examples from your experience: mention specific commands and outcomes, and explain tradeoffs instead of saying one approach is always right.

Overview

This guide prepares you for Git interview questions across three tiers: basic, intermediate, and advanced. Expect about 40% basic questions (commands and concepts), 35% intermediate (branching strategies, conflict resolution), and 25% advanced (history rewriting, repository performance, CI/CD integration).

In many developer interviews—roughly 60–75%—interviewers include at least one Git scenario or whiteboard exercise that asks you to resolve a conflict, re-create missing commits, or explain branching decisions.

Practical examples to study now:

•Clone and inspect history: `git clone <repo>`; `git log –oneline –graph –decorate –all`.
•Create and merge a feature branch: `git checkout -b feature/my-feature`; `git merge –no-ff feature/my-feature`.
•Interactive rebase to squash commits: `git rebase -i HEAD~4`.
•Find regression: `git bisect start`; `git bisect good <commit>`; `git bisect bad <commit>`.

Interviewers value concise, testable answers: show the exact command, explain the flags (e. g.

, why `–no-ff`), and state safety steps like creating a backup branch (`git branch backup`) before history-rewriting operations. Also prepare short stories: quantify impact (for example, reduced release conflicts by X%) or outline time saved when you fixed a broken build.

Actionable takeaway: practice five timed tasks (branch, merge, rebase, bisect, revert) under 15 minutes each and be ready to explain trade-offs.

Key Subtopics to Master

Focus on these specific subtopics; each item includes concrete practice examples and real-world uses.

•Commands: `clone`, `add`, `commit`, `push`, `pull`, `fetch`, `status`, `log`.
•Practice: create a repo, make 10 commits, then use `git log –oneline –graph` to narrate the timeline.

•Strategies: Git Flow, trunk-based. Teams commonly maintain 3–10 active branches per repo.
•Practice: create feature branches, merge with `–no-ff`, and compare resulting history.

•Example: `git rebase –interactive` to squash 3 commits into 1.
•Real-world: rebase cleans history for pull requests; merging retains explicit merge commits.

•Practice: simulate conflicts by editing the same file on two branches; resolve in under 15 minutes and run tests.

•Commands: `git reset`, `git revert`, `git rebase -i`.
•Rule of thumb: never force-push rewritten shared history without coordinating the team.

•Tools: Git LFS, `git gc`, `git repack`.

Actionable takeaway: pick 6 exercises—one per weekday—and time yourself to complete each within 20 minutes.

Resources and Study Plan

Use a mix of documentation, interactive practice, and timed drills. Below is a compact, actionable list with time estimates.

Authoritative docs (2–4 hours)

•Pro Git (book): read chapters on branching and rebasing (2 hours).
•Official Git documentation: reference specific commands when answering technical questions.

Interactive tutorials (4–6 hours)

•Learn Git Branching: do 15 scenario puzzles to master rebase and merge.
•GitHub Learning Lab: complete 3 practical modules (pull requests, collaboration).

Practice repos and challenges (6–8 hours)

•Create a repo with 20 commits and practice `rebase -i`, `bisect`, and `revert` steps.
•Simulate a CI fail: create a broken test, fix it, and show how to revert and patch.

Tools and analytics (1–2 hours)

•Git LFS for large assets; `gitstats` or GitHub Insights to analyze contribution patterns.

Recommended 2-week plan

•Week 1: 60–90 minutes/day on fundamentals and branching exercises (total ~8–10 hours).
•Week 2: 60–90 minutes/day on advanced topics, timed scenarios, and mock interviews (total ~8–10 hours).

Actionable takeaway: complete 30 practice scenarios over 2 weeks, track time per task, and record short explanations (30–60 seconds) for each command you use.

git Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Behavioral Questions (STAR Method)

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics to Master

Resources and Study Plan

Common Interview Questions

Build your job search toolkit

git Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Q1What is Git and how does it differ from centralized version control systems like SVN?

Q2Explain branching and merging in Git and when you would use feature branches.

Q3What is git rebase and how does it differ from git merge?

Q4How do you resolve a merge conflict? Walk me through your steps.

Q5What is git stash and when should you use it?

Q6How does Git store data internally, and what are blobs, trees, and commits?

Q7How would you revert a bad commit that has already been pushed to a shared remote?

Q8What is git cherry-pick and when should you use it?

Q9How do you handle large binary files in Git repositories?

Q10What are some common Git workflows teams use and how do you choose one?

Behavioral Questions (STAR Method)

B1Tell me about a time you resolved a critical merge conflict under time pressure.

B2Describe a time you introduced or improved a branching strategy across a team.

B3Give an example when you had to recover from an accidental deletion or repository issue.

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics to Master

Resources and Study Plan

Common Interview Questions

Build your job search toolkit