Git Interview Questions & Answers

A Git repository isn't just your current files, it's your files PLUS the entire history of every change ever made to them, all stored together in the hidden .git folder.

In an interactive rebase, `squash` combines a commit's changes into the one above it and opens an editor so you can merge both commit messages together, while `fixup` does the same merge but silently discards the later message. `drop` would throw away the actual code changes, which isn't what's wanted here, and `reword` only edits a message without touching content at all. Knowing the distinct rebase todo verbs (pick, reword, edit, squash, fixup, drop) is what separates a clean PR history from an accidental loss of work.

Git doesn't delete commit data the instant nothing points to it anymore, it just becomes 'dangling', still sitting in Git's storage but orphaned from any branch or tag. Since it's not actually gone yet, tools like git reflog or git fsck can often help you find and recover it before it eventually gets cleaned up.

git log is your project's diary: it lists every commit in order, newest first, along with who made it, when, and what message they left, so you can trace exactly how the project got to where it is.

Cherry-pick lets you grab just the changes from ONE specific commit somewhere else and replay them onto your current branch as a brand-new commit, without dragging along everything else that commit's original branch has done.

A normal commit has exactly one parent, so Git always knows what changed. A merge commit has two or more parents (since it combined two branches), so when you cherry-pick it, Git has no way to know which parent's changes you actually want, unless you tell it with -m which parent to compare against.

git add doesn't save anything permanently yet, it just marks changes as 'include this in the next commit' by moving them into the staging area. The actual permanent save happens with git commit.

All reset modes move HEAD and the branch pointer, but differ in how far they reach: `--soft` leaves the index and working directory untouched, `--mixed` (the default) also resets the index but leaves your working directory files modified, and `--hard` additionally overwrites the working directory to match the new HEAD, discarding those changes completely. That's why `--hard` is the dangerous one: uncommitted work in your files is gone, not just unstaged.

Before Git lets a risky operation (like reset or rebase) move HEAD somewhere new, it quietly saves where HEAD WAS into ORIG_HEAD. So if that operation turns out to be a mistake, you can jump straight back with `git reset --hard ORIG_HEAD` instead of hunting through history.

A signed commit carries a cryptographic signature made with the author's GPG or SSH key, and GitHub shows 'Verified' once it can confirm that signature against a key registered to that account, proving the commit genuinely came from that person and wasn't altered afterward. It says nothing about CI status or code review, those are tracked separately through checks and pull request approvals.