Git Interview Questions 2026: Merge vs Rebase, Reset vs Revert, and the Scenarios That Actually Get Asked

Git is a distributed version control system. It records snapshots of your project as commits, and every clone contains the complete history, so you can commit, branch, diff, and inspect history entirely offline. GitHub is a hosting service built around Git: it stores remote copies of repositories and adds collaboration features — pull requests, code review, issues, access control, and CI integration. Nothing in Git requires GitHub; you could push to GitLab, Bitbucket, or a bare repository on your own server and Git behaves identically. Interviewers ask this to catch candidates who conflate the two, which suggests they have only clicked through a web UI. A crisp answer states the split in one line — Git is the tool, GitHub is a place to host Git repositories plus a collaboration layer — and adds that commits are local until you push.

git fetch downloads new commits, branches, and tags from the remote and updates your remote-tracking references, such as origin/main, without changing your current branch or working files. git pull is fetch plus integration: it fetches, then merges the remote branch into your current branch — or rebases onto it if you use pull --rebase or set pull.rebase in config. The practical difference is control. After a fetch you can inspect what arrived — git log main..origin/main shows incoming commits — and then integrate deliberately. Pull integrates immediately, which can produce surprise merge commits or conflicts mid-task. A good habit worth stating: fetch frequently, pull deliberately. Also note that pull only updates the branch you are currently on; your other local branches stay where they were until you update them separately.

git init creates a brand-new, empty repository by writing a .git directory into the current folder. There is no history, no remote, and no commits until you make the first one. git clone copies an existing repository: it downloads the full history from a source URL, creates the .git directory, sets up a remote named origin pointing back at the source, creates remote-tracking branches, and checks out the default branch into your working directory. So init starts a project from scratch, while clone gives you a complete local copy of an existing one. A detail that shows depth: because clones carry full history, every developer's machine is effectively a backup of the entire project — a core consequence of Git being distributed rather than centralised like older systems such as SVN.

.gitignore is a file of patterns telling Git which untracked files to ignore, so they never appear in git status or get swept into commits by git add . Typical entries: build outputs, dependency folders like node_modules or a Python venv, logs, IDE settings, OS junk like .DS_Store, and environment files such as .env that hold secrets. Two details separate strong answers. First, .gitignore only affects untracked files — if a file is already committed, adding it to .gitignore changes nothing; you must run git rm --cached on it to stop tracking while keeping it on disk. Second, a secret that was ever committed lives on in history even after removal, so the credential must be rotated. Mentioning a global ignore file via core.excludesFile for personal editor cruft is a nice extra.

Git has three zones: the working directory where you edit, the staging area (also called the index), and the repository of committed snapshots. git add copies the current state of a file into the index; git commit records exactly what the index contains as a new commit. The middle layer exists so you can compose commits deliberately. You might edit five files but stage and commit only two, or use git add -p to stage individual hunks within a file, producing small, reviewable commits instead of one tangled dump. It also explains commands that confuse beginners: git diff shows working directory versus index, while git diff --staged shows index versus the last commit. Tying the staging area to commit hygiene — small, focused commits reviewers can follow — shows you actually use it, not just know of it.

Merge joins two lines of history with a merge commit that has two parents. Nothing existing is rewritten, so it is always safe, and history honestly records that parallel work happened — at the cost of a busier graph. Rebase takes your branch's commits and replays them one by one on top of a new base, creating new commits with new SHAs; the originals are abandoned. You get clean, linear history, but it is history rewriting. Hence the golden rule: never rebase commits others may have already pulled, because their history no longer matches yours and everyone must recover manually. A common professional workflow: rebase your local, unpushed feature branch onto the latest main to stay current, then integrate into main through a pull request using a merge or squash-merge. Presenting this as a tradeoff, not a winner, is what interviewers want.

git reset moves the current branch pointer to another commit, rewriting history. Its modes control what happens to your files: --soft keeps changes staged, --mixed (the default) keeps them in the working directory but unstaged, and --hard discards them entirely. Because the abandoned commits become unreachable from the branch, reset belongs on local, unpushed work. git revert does the opposite of rewriting: it creates a new commit whose diff is the inverse of the target commit, so both the mistake and its correction remain in history. That makes revert the only safe way to undo something already pushed to a shared branch. A crisp summary: reset rewrites, revert appends. Bonus credit for noting that commits 'lost' to a reset are usually recoverable through git reflog for a while, since Git does not delete them immediately.

git stash shelves your uncommitted changes — staged and unstaged modifications to tracked files — onto a stack and restores a clean working directory. Classic uses: switching branches for an urgent fix, or pulling changes that would conflict with half-done work. git stash pop reapplies the latest stash and drops it; git stash apply reapplies but keeps the entry, which is safer when the reapply might conflict. Untracked files are not stashed unless you pass -u, a detail that catches people out. Also useful: git stash list shows the stack, and git stash branch creates a branch from a stash — handy when stashed work no longer applies cleanly to the current branch. The honest caveat interviewers like: stashes are invisible and easy to forget, so for anything beyond a quick interruption, a WIP commit on a branch is more recoverable.

git cherry-pick <sha> takes the change introduced by one specific commit and applies it to your current branch as a brand-new commit with a new SHA. It is the right tool when you need a single change without everything else on its branch — most commonly backporting a bug fix from main to a release branch, or rescuing one good commit from an abandoned branch. Using -x appends the original commit reference to the message, keeping backports traceable. The costs are worth stating: the same change now exists as two different commits, which can cause conflicts when the branches eventually merge, and cherry-picking a commit that depends on earlier commits you skipped will conflict or silently miss context. It is a precision tool, not a merging strategy — if you need many commits from a branch, merge or rebase instead.

A conflict occurs when two branches change the same lines, or one deletes a file the other modifies, so Git cannot pick a side automatically. The merge stops, git status lists unmerged paths, and each conflicted file contains markers: your side between <<<<<<< and =======, the incoming side between ======= and >>>>>>>. The process: open each file, decide what the combined code should actually be — one side, both, or something new — delete the markers, run tests if possible, then git add the resolved files and finish with git commit or git merge --continue. During a rebase you repeat this per conflicted commit with git rebase --continue. If things go sideways, git merge --abort or git rebase --abort restores the previous state. Mention prevention too: small pull requests and frequently syncing your branch with main shrink conflicts dramatically.

HEAD normally points at a branch name, and the branch points at a commit, so new commits advance the branch. When you check out a commit hash or tag directly, HEAD points straight at the commit with no branch attached — detached HEAD. It is not an error; it is how you inspect an old version, and how CI systems check out exact commits. The danger is committing there: those commits belong to no branch, and once you switch away they become unreachable and eventually eligible for garbage collection. Recovery is simple. If you are still on the commits, run git switch -c rescue-branch and the work is safe. If you already switched away, git reflog shows the commit you were on; create a branch from that SHA. Saying 'create a branch before leaving' is the line interviewers listen for.

Branch off the latest main with a descriptive name, make small focused commits, and push the branch. Open a pull request; CI runs tests and linting automatically. Reviewers comment; you push fixes, and when the branch falls behind you update it by merging main into it or rebasing onto main. Once approved and green, it merges using one of three strategies. A merge commit preserves every commit and the branch structure. Squash-merge collapses the PR into a single commit on main — popular because main stays readable and each commit maps to one reviewed change. Rebase-merge replays the PR's commits onto main individually, keeping detail with linear history. Afterwards, delete the branch. Strong answers add the habits that make this work: PRs small enough to review properly, a clear description, and never force-pushing the shared target branch.

Git is a content-addressed object database under .git/objects with four object types. Blobs hold file contents. Trees represent directories, mapping names to blobs and other trees. Commits point to one tree — the snapshot of the whole project — plus parent commit(s), author, and message. Annotated tags wrap another object with a name and message. Every object's ID is a hash of its content (SHA-1 historically; newer Git also supports SHA-256), so identical content is stored once and no object can change without changing its ID. Branches are not copies of anything — a branch is a file in .git/refs/heads containing one commit hash, and HEAD points to the current branch. This model explains everyday behaviour: branching is instant, commits are immutable, amending or rebasing actually creates new commits, and history rewrites are disruptive because they change hashes everything else references.

The reflog is a local journal of where HEAD and each branch tip have pointed, recorded every time they move — commits, checkouts, resets, rebases, merges. Its power is that commits abandoned by history rewrites remain reachable through it. After an accidental git reset --hard, git reflog shows entries like HEAD@{2} with the commit you were on; recover with git reset --hard HEAD@{2} or, more safely, git branch rescue <sha>. The same trick recovers a botched rebase or a deleted branch. Its limits matter in a strong answer: the reflog is purely local — never pushed, so it cannot help on another machine — and entries expire, by default after 90 days for reachable entries and 30 for unreachable ones, after which garbage collection can remove the commits. It also cannot restore work that was never committed or staged.

Default answer: git revert <sha>, which adds a new commit inverting the bad change. History is not rewritten, so nobody's clone breaks, and the fix goes through the normal push or PR flow. Reverting a merge commit needs -m 1 to specify the mainline parent. The alternative — reset and force-push — rewrites shared history and forces everyone who pulled the branch to recover, so it is reserved for branches only you use, or an explicitly coordinated team decision; when forcing, use --force-with-lease so you cannot overwrite commits you have not seen. The special case worth raising unprompted: if the commit exposed a secret, revert is insufficient because the value remains in history. Rotate the credential immediately; truly purging it requires a history rewrite with a tool like git filter-repo plus coordination with everyone who has a clone.

Git Flow uses long-lived main and develop branches plus feature, release, and hotfix branches. It gives explicit release staging and suits products with versioned, scheduled releases — but long-lived branches drift apart, merges get large, and integration problems surface late. Trunk-based development inverts this: everyone merges small changes into main within a day or two, incomplete features hide behind feature flags, and main stays releasable — which is what continuous deployment needs. Its prerequisite is discipline: strong automated tests, fast CI, and small PRs, because a broken main blocks everyone. Many teams actually run the lighter middle option, GitHub Flow: branch, PR, review, merge to main, deploy. The interview-winning move is choosing by context — release cadence, CI maturity, team size, and whether you ship versions or a continuously deployed service — then describing which model your team used and how it worked in practice.