Git Interview Questions & Answers

A remote is just a nickname (usually 'origin') that Git uses to remember where another copy of your repository lives, typically on a server like GitHub, so commands like push and pull know where to send or fetch changes.

Interactive rebase opens up your recent commits as an editable list before replaying them, so instead of just moving them as-is, you can reorder them, squash several messy ones into a single clean commit, tweak a commit message, or drop a commit entirely.

`git stash pop` applies the stashed changes and then deletes the stash entry, but only if the apply succeeds cleanly; if a conflict occurs, Git leaves the entry in the stash list as a safety net rather than risk losing it. You resolve the conflict exactly as you would in a merge, stage the result, and then explicitly run `git stash drop` once you're satisfied nothing was lost. Running `git stash clear` would wipe out every stashed entry in the whole list, not just the one that failed, which is far more destructive than intended.

`.gitignore` only tells Git which untracked files to skip when staging; it has no effect on files that are already being tracked. To stop tracking the file you have to explicitly run `git rm --cached config.local.yml` and commit that removal, after which the ignore rule takes over. This is one of the most common `.gitignore` gotchas, since people expect the rule alone to be enough.

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.

Git quietly keeps a local log of every place HEAD has pointed to, even after something like a reset or rebase moves it elsewhere. That log (the reflog) is often your only way back if you accidentally lose commits, since it remembers where you WERE, not just where you are now.

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.

git blame goes line by line through a file and tells you exactly which commit (and which author) last touched each one, which is exactly what you want when you're trying to figure out who wrote a weird line of code and why.

A shallow clone truncates history at the requested depth, so any operation needing to walk further back, like finding a common ancestor between two far-apart branches, or attributing very old lines of code, simply doesn't have the data to do so and will error out or give incomplete answers. The fix is `git fetch --unshallow` to backfill the full history, or to avoid `--depth` entirely for jobs that need it.

The pre-commit hook runs right before Git finalizes a commit, letting a script inspect the staged content and abort the commit, by exiting non-zero, if something's wrong, such as a failing linter. A post-merge hook only fires after a merge has already completed, so it can't block anything, and an alias is just a shortcut for typing commands, not an enforcement mechanism.