By Kedar Salunkhe  · Updated March 2026 Â
Git shows up in almost every developer and DevOps interview. Not because interviewers love Git, but because Git knowledge is a reliable signal. A candidate who understands Git well enough to explain it clearly — not just use it — has usually put in serious time on real projects.
The problem is that most Git interview questions prep resources are either too shallow (just listing commands with one-line definitions) or too advanced for freshers who are still building a foundation. This guide tries to do something different. Each question has an answer that’s accurate, goes a level deeper than the surface definition, and sounds like something a human being would actually say in an interview — not a copied paragraph from the documentation.
I have organized the questions from basic to advanced so you can gauge where you are and focus your preparation. Read through all of them at least once. The basic ones catch more people than you’d expect.
Table of Contents
Basic Git Questions (Q1–Q15)
These are the questions that appear in almost every Git interview, regardless of role or experience level. Get these clean and confident before moving to anything else.
Q1. What is Git and why is it used?
Git is a distributed version control system. It tracks changes to files over time so you can recall specific versions later, collaborate with other developers without overwriting each other’s work, and maintain a complete history of every change made to a project.
It’s used because software development without version control is essentially unmanageable once a project reaches any meaningful size or involves more than one person. Git solves problems that every developer hits within weeks of their first real project: needing to undo a change, needing to work on two things at once, and needing to combine work done by multiple people on the same codebase.
Q2. What is the difference between Git and GitHub?
Git is the tool — free, open-source software that you install on your computer to track changes locally. GitHub is a cloud hosting platform for Git repositories. GitHub adds features on top of Git: Pull Requests for code review, Issues for bug tracking, Actions for CI/CD automation, and a web interface for browsing code.
You can use Git without GitHub. GitHub without Git doesn’t make sense — it hosts Git repositories. Think of Git as Microsoft Word and GitHub as Google Drive. One is the tool, the other is where you store and share what you create with it.
Q3. What is a repository in Git?
A repository is a project folder that Git is tracking. It contains all the project files and the entire history of every change ever made to those files. Technically, the repository is the hidden .git folder inside your project directory — that’s where Git stores everything. The files you edit are just a working copy checked out from the repository.
A local repository lives on your machine. A remote repository lives on a server like GitHub. Most workflows use both — you work locally and push to the remote to share and back up your work.
Q4. What are the three states of a file in Git?
Every file in a Git project exists in one of three states:
- Modified — you’ve changed the file in your working directory but haven’t told Git about it yet
- Staged — you’ve marked the change to be included in the next commit, using
git add - Committed — the change has been permanently saved in the Git database as part of a commit
Understanding these three states is the foundation of understanding why Git commands work the way they do. Most beginner confusion with Git traces back to not being clear on which state a file is in.
Q5. What is a commit in Git?
A commit is a saved snapshot of all staged changes at a specific point in time. Every commit contains a unique SHA-1 hash that identifies it, the author’s name and email, a timestamp, a commit message describing what changed and why, and a pointer to the previous commit that creates the chain of history.
An important thing that interviewers sometimes ask as a follow-up: a commit stores a complete snapshot of the project, not a diff. When Git shows you “what changed in this commit,” it’s computing the difference between this commit’s snapshot and the parent commit’s snapshot on the fly.
Q6. What is the staging area in Git?
The staging area — also called the index — is an intermediate zone between your working directory and your commit history. When you run git add, changes move from your working directory into the staging area. When you run git commit, everything in the staging area becomes the new commit.
The staging area exists so you have precise control over what goes into each commit. You might have changed ten files, but only want to commit three of them as one logical unit. Stage those three, commit, then stage the rest separately. This produces clean, readable commit history instead of messy everything-at-once commits.
Q7. What is the difference between git pull and git fetch?
git fetch downloads changes from the remote repository and updates your remote-tracking branches, but does not touch your local branches or working directory. It’s a safe read operation — you can see what’s on the remote without any risk of overwriting local work.
git pull does a git fetch followed immediately by a git merge into your current local branch. It’s the combination of downloading and integrating in one step. If there are conflicts between remote changes and your local commits, git pull will surface them.
In practice, many experienced developers prefer git fetch followed by inspecting the changes before deciding how to integrate, rather than the automatic behavior of git pull.
Q8. What does git init do?
git init initializes a new Git repository in the current directory. It creates a hidden .git folder containing all the data structures Git needs: the object database, references, configuration, and hooks. Before running git init, the folder is just a regular directory. After, it’s a Git repository and every file inside it can be tracked.
Q9. What is git clone?
git clone creates a local copy of a remote repository. It downloads the entire repository — all commits, all branches, all history — to your machine and sets up the remote as origin automatically. After cloning, you have a complete local copy and can work on it without a network connection, pushing your changes to the remote when you’re ready.
Q10. What is a branch in Git?
A branch is a lightweight, movable pointer to a specific commit. The default branch is usually called main. When you create a new branch, Git creates a new pointer that starts at the same commit as your current branch. As you make commits on the new branch, that pointer advances while the original branch stays where it was.
The key thing to understand — and something interviewers appreciate hearing — is that a branch is just a text file containing a commit hash. It’s not a copy of the codebase. Creating a branch is nearly instant because it’s just creating a small file.
Q11. What is the difference between git merge and git rebase?
Both commands integrate changes from one branch into another but in different ways.
git merge combines the histories of two branches and creates a new merge commit that has two parents. The full history of how both branches developed is preserved, including when they diverged and when they were reunited.
git rebase takes the commits from one branch and replays them on top of another branch as if you had started your branch from a different point. The result is a linear history with no merge commits. The trade-off is that rebase rewrites commit history — the commits get new SHA-1 hashes — which causes problems if those commits were already shared with others.
The general rule: merge for integrating shared branches, rebase for cleaning up local personal branches before sharing.
Q12. What is HEAD in Git?
HEAD is a special pointer that tells Git where you currently are. In normal usage, HEAD points to a branch, which in turn points to the most recent commit on that branch. When you make a new commit, HEAD moves forward through the branch pointer. When you switch branches, HEAD updates to point to the new branch.
When HEAD points directly to a commit instead of through a branch, you’re in “detached HEAD” state. This typically happens when you check out a specific commit hash or tag directly.
Q13. What is .gitignore and why do you need it?
A .gitignore file tells Git which files and directories to completely ignore — never track them, never include them in commits, never show them in git status. You need it because every project has files that shouldn’t be in version control: installed dependencies like node_modules, build output, editor configuration files, and critically, environment files containing secrets like API keys and passwords.
A common interview follow-up: what happens if you add a file to .gitignore that Git is already tracking? The file stays tracked — .gitignore only affects untracked files. You need to run git rm --cached filename to stop tracking it.
Q14. What is the difference between git reset and git revert?
git revert creates a new commit that undoes the changes from a previous commit. It’s safe for shared branches because it doesn’t rewrite history — it adds to it. The original commit stays in the history, and so does the revert commit that cancels it out.
git reset moves the branch pointer backwards to an earlier commit, effectively removing commits from the history. It comes in three modes — soft (keep changes staged), mixed (keep changes unstaged), and hard (discard all changes). Never use git reset on commits that have already been pushed to a shared branch.
Q15. What is git stash?
git stash temporarily saves your uncommitted changes — both staged and unstaged — to a stack and reverts your working directory to the last committed state. This lets you switch context cleanly without committing incomplete work.
Use git stash pop to restore the stashed changes when you’re ready to continue. You can have multiple stashes and apply them selectively. A common real-world scenario: you’re mid-feature when an urgent bug comes in. Stash your work, fix the bug, push it, then pop the stash and pick up where you left off.
Intermediate Git Questions (Q16–Q30)
These questions require a deeper understanding of how Git works and are common for developer and DevOps roles at most companies.
Q16. What is a merge conflict and how do you resolve one?
A merge conflict happens when two branches have both modified the same part of the same file in different ways and Git cannot automatically determine which version to keep. Git marks the conflicted sections in the file with conflict markers and halts the merge.
To resolve: open each conflicted file, read both versions separated by =======, edit the file to its correct final state, remove all conflict markers, stage the resolved file with git add, and complete the merge with git commit. The key is understanding both sides’ intent before choosing how to combine them — not just picking whichever version looks familiar.
Q17. What is a remote in Git?
A remote is a version of the repository hosted somewhere other than your local machine — typically on GitHub, GitLab, or a company’s own server. The default remote is named origin by convention. You push commits to the remote to share them with teammates and back them up. You fetch or pull from the remote to get changes others have pushed.
A single local repository can have multiple remotes. This is common when you’ve forked a repository — you’ll have origin pointing to your fork and upstream pointing to the original.
Q18. What is git cherry-pick?
git cherry-pick applies the changes introduced by a specific commit onto your current branch, creating a new commit with the same changes but a different hash. It lets you pick individual commits from one branch and apply them to another without merging the entire branch.
A common real-world use case: a bug fix was committed to a feature branch before the feature was ready to merge. You can cherry-pick just the bug fix commit onto main to deploy the fix without waiting for the entire feature to be complete.
$ git cherry-pick a3f9c12Q19. What is the difference between a fast-forward merge and a three-way merge?
A fast-forward merge happens when the current branch hasn’t received any new commits since the feature branch was created. Git can simply move the current branch pointer forward to point at the tip of the feature branch. No new merge commit is created. The history stays perfectly linear.
A three-way merge happens when both branches have new commits since they diverged. Git finds the common ancestor of both branches, compares both tips against that ancestor, and creates a new merge commit that has two parents. The branching and merging is visible in the history.
Q20. What is git log and what are its useful options?
git log shows the commit history. By default it’s verbose — full commit hash, author, date, and message for every commit. Some genuinely useful options:
git log --oneline— one line per commit, shortened hash and messagegit log --oneline --graph --all— visual branch graph, excellent for understanding branching historygit log --author="Name"— filter by authorgit log --since="2 weeks ago"— filter by dategit log -- filename.js— show commits that touched a specific filegit log -p— show the actual diff for each commit
Q21. What is git diff?
git diff shows the differences between file versions. Without arguments it shows unstaged changes — the difference between your working directory and the staging area. git diff --staged shows staged changes — what’s in the staging area compared to the last commit. git diff branch1 branch2 shows the difference between two branches. git diff commit1 commit2 shows the difference between two commits.
Q22. What is a tag in Git?
A tag is a named reference to a specific commit, used to mark important points in history — most commonly release versions. Unlike branches, tags don’t move when new commits are made. There are two types: lightweight tags, which are just a pointer to a commit, and annotated tags, which are full objects in the Git database containing a message, tagger identity, and timestamp. Annotated tags are the right choice for public releases.
# Create an annotated tag
$ git tag -a v2.0.0 -m "Release version 2.0.0"
# Push tags to remote
$ git push origin --tagsQ23. What is git bisect?
git bisect is a debugging tool that uses binary search to find the commit that introduced a bug. You tell Git a commit where the bug exists (bad) and a commit where it didn’t exist yet (good), and Git checks out the midpoint of that range for you to test. You mark it good or bad, and Git narrows the range in half each time. It finds the exact commit that introduced the bug in O(log n) steps regardless of how many commits are in the range.
$ git bisect start
$ git bisect bad HEAD
$ git bisect good v1.8.0
# Git checks out midpoint — you test, then:
$ git bisect good # or git bisect bad
# Repeat until Git identifies the first bad commit
$ git bisect reset # when doneQ24. What is git blame?
git blame filename shows every line of a file annotated with the last commit that modified it — who changed it, when, and in what commit. Despite the name, it’s not about assigning fault. It’s about tracing context: why was this line written this way, and where can I find the full conversation about it? Finding the commit hash from git blame and then running git show on it often answers questions faster than any documentation.
Q25. What is the difference between git reset –soft, –mixed, and –hard?
All three move the branch pointer to a previous commit. The difference is what happens to your changes after the reset:
- –soft — moves the branch pointer back but keeps changes staged in the index. Your changes are still ready to commit — useful when you want to re-commit with a different message or combine commits.
- –mixed (default) — moves the pointer and unstages the changes, but keeps them in your working directory. You can review and selectively re-stage.
- –hard — moves the pointer and discards all changes completely. Working directory matches the target commit exactly. This is the dangerous one — changes are gone and not easily recoverable unless you find the commit in the reflog.
Q26. What are Git hooks?
Git hooks are scripts that Git runs automatically at specific points in its workflow. They live in .git/hooks/ and are named for when they execute: pre-commit runs before a commit is created, commit-msg runs after you write the commit message, pre-push runs before a push, post-merge runs after a merge completes.
If a hook script exits with a non-zero status, Git aborts the operation. This makes them powerful enforcement tools: running tests before a commit, validating that commit messages follow a format, preventing pushes of large files, sending notifications after a deployment. Hooks are not committed to the repository by default — tools like Husky are commonly used to share hooks across a team.
Q27. What is git reflog?
The reflog is a local log of every position HEAD has been in, kept for 90 days by default. It records every checkout, commit, reset, and merge — even operations that “removed” commits from the visible history. When you accidentally delete a branch, do a hard reset you regret, or lose commits during a rebase, the reflog is usually how you get them back.
$ git reflog
f4d8a1b HEAD@{0}: merge feature/login: Merge made by 'recursive'
a3f9c12 HEAD@{1}: checkout: moving from feature/login to main
b4e8d23 HEAD@{2}: commit: Add session managementThe reflog is local only — it doesn’t get pushed to remotes and isn’t available after a fresh clone.
Q28. What is a Pull Request?
A Pull Request (PR), called a Merge Request in GitLab, is a feature of hosting platforms like GitHub — not Git itself. It’s a formal proposal to merge changes from one branch into another, typically from a feature branch into main. It provides a structured place for code review: teammates can see exactly what changed, leave comments on specific lines, ask questions, and request changes before the code is merged. Pull Requests are how professional teams maintain code quality and create a permanent record of why decisions were made.
Q29. What is the difference between git fetch and git pull (in detail)?
When you run git fetch origin, Git contacts the remote server, downloads any new objects (commits, trees, blobs) that exist on the remote but not locally, and updates your remote-tracking branches (like origin/main). Your local branches and working directory are completely untouched.
When you run git pull, it first does exactly what git fetch does, then runs git merge origin/current-branch to integrate the fetched changes into your local branch. If there are commits on both sides since they last shared a common ancestor, this merge can produce conflicts.
The practical difference: git fetch lets you look before you leap. You can run git log origin/main after fetching to see what changed before deciding how to integrate it.
Q30. What is forking a repository?
Forking creates your own personal copy of someone else’s repository under your GitHub account. It’s the standard way to contribute to open-source projects where you don’t have write access to the original repository. You fork the repo, clone your fork locally, make changes on a branch, push to your fork, and then open a Pull Request from your fork’s branch to the original repository’s main branch.
Forking is a GitHub concept, not a Git concept. Git itself doesn’t know anything about forks — it just sees remotes. When you fork a repo, you typically set up two remotes: origin pointing to your fork and upstream pointing to the original.
Advanced Git Questions (Q31–Q45)
These questions separate candidates who have used Git seriously from those who know the basics. Even as a fresher, being able to answer five or six of these confidently makes a strong impression.
Q31. What are Git objects and what types exist?
Git’s entire data model is built on four object types stored in .git/objects/:
- Blob — stores raw file content. No filename, no permissions — just content. Two files with identical content share one blob.
- Tree — stores a directory structure. Lists filenames, permissions, and pointers to blobs or other trees.
- Commit — stores a pointer to a root tree, parent commit pointers, author and committer info, timestamp, and message.
- Tag — an annotated tag object pointing to another object, usually a commit, with its own metadata and message.
Every object is identified by the SHA-1 hash of its content. Change one byte and you get a completely different hash. This is how Git guarantees data integrity — corruption is mathematically detectable.
Q32. What is interactive rebase and when would you use it?
Interactive rebase — git rebase -i — lets you edit your commit history before sharing it. You can squash multiple commits into one, reorder commits, edit commit messages, and drop commits entirely.
The typical use case: you’ve been working on a feature for a few days and your commit history has become a mess of “WIP”, “fix typo”, “actually fix typo”, and “remove console.log” commits. Before opening a Pull Request, you run git rebase -i HEAD~8, squash the noise into clean logical commits with meaningful messages, and the reviewer sees a coherent story instead of your development process.
Only use interactive rebase on commits that haven’t been pushed to a shared remote — it rewrites history and creates new commit objects with different hashes.
Q33. What is git squash?
Squashing combines multiple commits into a single commit. It’s done through interactive rebase — you mark commits as squash or s in the rebase editor and they get folded into the previous commit. The result is one clean commit instead of several messy ones.
Many teams configure their GitHub repository to “squash and merge” Pull Requests by default. This means no matter how many commits are in the PR branch, the merge to main produces exactly one commit. Clean main branch history, development freedom on feature branches.
Q34. What is the difference between a lightweight tag and an annotated tag?
A lightweight tag is just a file containing a commit hash — essentially a branch that never moves. It has no metadata of its own.
An annotated tag is a full Git object stored in the database. It has its own SHA-1 hash, the tagger’s identity, a timestamp, and a message. Annotated tags can also be GPG signed. They’re the correct choice for public releases because they carry their own metadata and can be verified.
# Lightweight tag
$ git tag v2.0.0
# Annotated tag (correct for releases)
$ git tag -a v2.0.0 -m "Release 2.0.0: adds OAuth support"Q35. What is git submodule?
A Git submodule lets you embed one Git repository inside another as a subdirectory. The parent repository records a pointer to a specific commit in the submodule repository rather than copying the submodule’s files. This is useful when you want to include an external library or shared component in your project while keeping it as its own independently versioned repository.
Submodules have a reputation for being tricky to work with. The main gotcha for freshers: cloning a repository with submodules doesn’t automatically clone the submodules. You need git clone --recurse-submodules or run git submodule update --init after cloning.
Q36. What is git worktree?
git worktree lets you check out multiple branches simultaneously in different directories, all sharing the same .git repository. Instead of stashing your work, switching branches, doing something, and switching back — you can have two working directories open at the same time, each on a different branch.
# Check out a branch in a separate directory
$ git worktree add ../project-hotfix hotfix/payment-bugThis is useful for long-running comparisons, running both versions simultaneously, or working on an urgent fix without disturbing your current work at all.
Q37. What is the .git/config file?
The .git/config file is the repository-level configuration. It overrides the global ~/.gitconfig for this specific repository. It stores the remote URLs, branch tracking configuration, and any per-project settings. You can view and edit it with git config --local --list or directly in a text editor. Git configuration has three levels: system (whole machine), global (current user), and local (current repository) — local settings take the highest priority.
Q38. What is the difference between git restore and git checkout for discarding changes?
In older versions of Git, git checkout -- filename was the way to discard changes to a file. This was confusing because git checkout also switches branches — two very different operations using the same command.
Git 2.23 introduced git restore and git switch to separate these concerns. git restore filename discards changes to a file in the working directory. git restore --staged filename unstages a file. git switch branch-name switches branches. Both old and new syntax still work, but the new commands are cleaner and less confusing for beginners.
Q39. What is git gc?
git gc (garbage collection) cleans up and optimizes the repository. It packs loose objects into packfiles for efficient storage, removes objects that are no longer reachable from any reference and have passed the grace period, prunes stale remote-tracking references, and repacks existing packfiles for better compression.
Git runs gc automatically in the background under certain conditions. You rarely need to run it manually, but doing so periodically on large repositories can meaningfully reduce their disk footprint.
Q40. What are packfiles in Git?
Initially, Git stores each object (blob, tree, commit) as an individual compressed file in .git/objects/. These are called loose objects. As the number of objects grows, Git periodically runs garbage collection and packs them into a packfile — a single binary file containing many objects stored with delta compression.
Delta compression means Git stores the full content of some objects and only the differences (deltas) for similar objects, rather than storing each version fully. This is why Git repositories stay small even with long histories full of similar files. The Linux kernel repository, with decades of history and millions of commits, is only around 5GB on disk.
Q41. What is git archive?
git archive creates a zip or tar archive of a specific tree — a branch, tag, or commit — without including the .git directory. It’s used to create clean distribution packages of a release, deployable artifacts without version control metadata, or snapshots of a project at a specific point.
$ git archive --format=zip --output=release-v2.0.zip v2.0.0Q42. What is the significance of SHA-1 in Git?
Every object in Git’s database is identified by a SHA-1 hash — a 40-character hexadecimal string computed from the object’s content. The same content always produces the same hash. Changing even one character produces a completely different hash. This makes Git’s content addressing reliable and its data integrity guarantees mathematical — corruption is detectable because a corrupt object won’t match its hash.
SHA-1 is considered cryptographically weak for security purposes, but Git doesn’t use it for security — it uses it for integrity and addressing. The Git team has been adding SHA-256 support as a migration path for new repositories in Git 2.29+.
Q43. What are the main branching strategies used by teams?
The three most common strategies in production teams:
Feature Branch Workflow — every feature or fix gets its own branch, nothing goes directly to main, changes come in through Pull Requests with code review. Works well for most teams.
Git Flow — uses two permanent branches (main for production, develop for integration) plus temporary feature, release, and hotfix branches. Works well for software with defined release cycles and versioning requirements. Overkill for continuously deployed web apps.
Trunk-Based Development — all developers commit to main frequently (daily or more). Short-lived branches, feature flags for incomplete work, strong CI/CD. High velocity but requires mature engineering infrastructure to avoid breaking production constantly.
Q44. What is git rerere?
rerere stands for “reuse recorded resolution.” When enabled, Git records how you resolve merge conflicts. If the same conflict appears again — which can happen when doing repeated rebases or cherry-picks — Git automatically applies your previous resolution instead of making you resolve it again.
$ git config --global rerere.enabled trueThis is particularly useful if you regularly rebase a long-running branch against main and hit the same conflicts repeatedly. Once resolved the first time, subsequent rebases handle those conflicts automatically.
Q45. What is detached HEAD state and how do you fix it?
Detached HEAD means HEAD is pointing directly to a commit hash rather than to a branch name. This happens when you check out a specific commit, a tag, or certain remote references. You can look around and even make commits, but those commits aren’t on any branch. If you switch away without creating a branch pointing to them, they become orphaned and will be garbage collected eventually.
To fix it: if you just want to go back to where you were, check out your branch — git checkout main. If you made commits in detached HEAD state that you want to keep, create a branch pointing to your work before switching — git checkout -b my-new-branch.
Scenario-Based Questions (Q46–Q50)
These are the questions that trip up candidates who’ve memorized definitions but haven’t worked through real Git situations. Interviewers love these because they reveal whether you actually understand what’s happening or just know the vocabulary.
Q46. You accidentally committed sensitive data (an API key) to a public repository. What do you do?
First and immediately: treat the secret as compromised and rotate it. Generate a new API key, revoke the old one, update all systems that used it. Do this before anything else — assume the key was seen the moment it was pushed.
Then remove it from the repository. If the commit is the most recent one and hasn’t been pushed:
$ git reset --soft HEAD~1
# Remove the sensitive data from the file
$ git add .
$ git commit -m "Remove API key, add to .gitignore"If it’s already been pushed, use git filter-repo (the modern replacement for git filter-branch) to rewrite history and remove the file or value completely, then force-push. Note that force-pushing rewrites history — you’ll need to coordinate with everyone who has cloned the repository. Also contact GitHub/GitLab support as they can sometimes purge cached versions.
Add the secret file or pattern to .gitignore to prevent it from being committed again. The critical lesson: rotate first, remove second, prevent third.
Q47. You made commits on the wrong branch. How do you move them to the correct branch?
The scenario: you committed two new commits to main when they should have gone on feature/new-dashboard. The fix:
# Note the hashes of the commits you want to move
$ git log --oneline -5
# Create the correct branch at the current position (captures the commits)
$ git branch feature/new-dashboard
# Move main back to where it was before your commits
$ git reset --hard HEAD~2
# Switch to the correct branch — your commits are there
$ git checkout feature/new-dashboardIf the commits are already pushed to main, this is more involved — you’d need to coordinate with the team, revert the commits on main, and cherry-pick them onto the correct branch. Prevention: always check which branch you’re on before committing.
Q48. A junior developer has force-pushed to main and broken the team’s history. What do you do?
Don’t panic and don’t force-push again immediately — that makes it worse.
The goal is to restore main to the state it was in before the force-push. Find someone on the team whose local repository has the correct history — their local main should still point to the correct commit before the force-push happened. Use their repository to restore the remote:
# On the developer with the correct history
$ git push origin main --force-with-leaseAfter restoring, anyone whose local repository is now diverged from the restored remote will need to reset their local branch to match the remote. Then immediately add a branch protection rule to main that prevents force-pushes, so this can’t happen again.
Q49. You need to deploy a hotfix to production, but main has commits that aren’t ready to ship yet. How do you handle it?
This is exactly the scenario that release tags and hotfix branches are designed for. Find the last production release tag and branch off from it — not from the current main:
# Branch off the last production tag
$ git checkout -b hotfix/critical-bug v2.3.0
# Fix the bug
$ git add auth/session.js
$ git commit -m "Fix null pointer crash on expired sessions"
# Merge the fix to main so it's included in future releases
$ git checkout main
$ git merge hotfix/critical-bug
# Tag the hotfix as a release
$ git tag -a v2.3.1 -m "Hotfix: fix session expiry crash"
# Deploy from the tag, not from main
$ git push origin main --tags
$ git branch -d hotfix/critical-bugThe key insight: by branching off the production tag instead of current main, you deploy only the fix without dragging in unfinished work. You also merge back to main so the fix isn’t lost when the next full release happens.
Q50. How do you find which commit introduced a bug that appeared somewhere in the last 200 commits?
This is git bisect‘s exact purpose. Binary search through the commit history to find the first bad commit:
# Start bisect
$ git bisect start
# Mark the current state as bad (bug exists)
$ git bisect bad HEAD
# Mark a known good state (bug didn't exist)
$ git bisect good v2.0.0
# Git checks out the midpoint (~commit 100)
# Test the application — does the bug exist?
$ git bisect good # no bug at this commit
# or
$ git bisect bad # bug exists at this commit
# Git narrows the range by half each round
# After ~8 rounds (log2 of 200), Git identifies:
# "a3f9c12 is the first bad commit"
# Clean up
$ git bisect resetFinding the responsible commit in eight steps out of 200 candidates is the kind of thing that takes hours without git bisect and minutes with it. You can also automate the testing step — if you have a script that exits 0 for good and non-zero for bad, run git bisect run ./test-script.sh and Git will do the entire search automatically.
Interview Tips for Git Questions
Go One Level Deeper Than the Definition
When an interviewer asks “what is a branch,” they already know the textbook answer. What they’re listening for is whether you understand the implication — that it’s just a pointer, that it’s cheap to create, that switching is fast because of how Git stores data. The extra layer of understanding is what signals real experience.
Use Concrete Examples from Real Work
If you’ve resolved merge conflicts, used git stash in a real situation, or debugged something with git log, mention it. A concrete example from actual work is worth more than a technically perfect abstract answer. If you haven’t had much real-world experience yet, describe how you would handle a hypothetical — interviewers understand that freshers are building that experience.
Understand the Commands You’ve Used
Many freshers have used git push and git pull hundreds of times without being able to explain what they actually do. If a command is in your resume or your daily workflow, you should be able to explain it clearly and describe what it does internally. Interviewers will probe exactly this.
Be Honest About What You Don’t Know
If you haven’t used git bisect or git submodule, say so — but follow up with what you do know about it conceptually and how you’d learn it if needed. Saying “I haven’t used it in practice but I understand it does X” is significantly better than guessing and getting it wrong, which interviewers can usually tell immediately.
Practice the Commands in a Real Terminal
Reading this guide once is not enough preparation. Create a test repository, try every command in these answers, deliberately create conflicts and resolve them, force a detached HEAD state and fix it. Muscle memory from doing the actual operations is what makes answers feel natural in an interview rather than recited.
Related Resources
For strengthening your Git knowledge before interviews:
- Pro Git (Free Book) — The definitive reference. Read Chapters 1–3 for the fundamentals, Chapter 7 for the advanced tools covered in this guide.
- Learn Git Branching — Interactive visual exercises. The best way to build intuition for branching and rebasing.
- Oh Shit, Git! — Practical recovery guide for common mistakes. Worth knowing before your interview in case they throw a scenario question.
- What is Git? Complete Beginner Guide with Real Examples
- Git Internals Explained: How Git Works Behind the Scenes
Final Thoughts
Git interviews reward genuine understanding over memorized answers. An interviewer who asks “what is a branch” isn’t looking for the definition — they’re starting a conversation to see how deep your understanding goes. The candidates who answer well aren’t the ones who studied harder. They’re the ones who used Git on real projects and actually thought about what the commands were doing.
If you’re a fresher preparing for your first developer or DevOps role, the most valuable thing you can do alongside reading this guide is build something. Create a GitHub repository, work on it consistently, use branches properly, create pull requests even if it’s just you reviewing them, make deliberate mistakes and fix them. The experience of actually solving a detached HEAD problem or resolving a real merge conflict sticks in a way that reading about it doesn’t.
Focus your preparation on the basic questions first — questions 1 through 15. These catch more candidates than the advanced ones. Once those feel natural, work through the intermediate section. Get to the advanced topics and scenario questions before your interview but don’t panic if you haven’t used every command — honest acknowledgment combined with conceptual understanding is a perfectly acceptable answer for tools you haven’t used yet.
Good luck with the interview. Git knowledge is genuinely one of the easier things to build if you’re willing to spend the time with a real terminal and a real project.
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.