Top 35 Git Interview Questions & Answers 2025

Merge: combines branches by creating a merge commit, preserves branch history, non-destructive. Rebase: moves commits on top of another branch, rewrites commit history (new commit SHAs), creates linear history. Use merge for: public branches, preserving context. Use rebase for: cleaning up local work before merging, keeping feature branches current with main. Golden rule: never rebase shared/public branches.

reset: moves HEAD (and branch) to a commit. --soft (keep changes staged), --mixed (default, unstage changes), --hard (discard changes). Destructive on shared branches. revert: creates new commit that undoes changes — safe for shared branches, preserves history. checkout: switches branches or restores files (now: git switch for branches, git restore for files). Use revert on main, reset on local branches.

git stash saves uncommitted changes (tracked files) and restores a clean working directory. Use when: switching branches without committing, pulling latest changes. Commands: stash, stash pop (apply + drop), stash apply (keep stash), stash list, stash drop. stash push -m "message" for named stashes. Include untracked: --include-untracked. Don't use stash as long-term storage — commit WIP branches instead.

GitFlow: main + develop + feature/release/hotfix branches — good for scheduled releases, complex. GitHub Flow: main + feature branches + PRs — simpler, continuous deployment friendly. Trunk-based development: commit directly to main (with feature flags), no long-lived branches — highest velocity, requires CI/CD. Choose based on release cadence and team size. Trunk-based is the modern preference with proper CI.

Conflict occurs when same lines changed in both branches. Git marks conflicts with <<<<<<, =======, >>>>>>>. Resolution: edit file to desired state, remove markers, git add, git commit (merge) or git rebase --continue (rebase). Tools: VS Code built-in diff, git mergetool. Prevention: small focused commits, frequent integration, clear ownership. After resolving: always test, never blindly accept either side.

git cherry-pick <commit-hash> applies a specific commit from another branch to current branch. Creates new commit with same changes but different SHA. Use for: hotfixes (apply to both main and release branch), moving specific commits, undoing a partial revert. Can cherry-pick range: git cherry-pick A..B. Can cause duplicate commits if branches later merge — use sparingly.

Interactive rebase lets you rewrite commit history before sharing. Actions per commit: pick (keep), reword (edit message), edit (stop to amend), squash (combine with previous, keep messages), fixup (combine, discard message), drop (remove). Use for: cleaning up messy local history, squashing WIP commits, reordering commits. Only rebase commits not yet pushed. git push --force-with-lease after rebasing shared work.

git bisect uses binary search to find the commit that introduced a bug. Process: git bisect start, mark current as bad (bisect bad), mark known good commit (bisect good <hash)). Git checks out midpoint; you test and mark good/bad. Repeats until offending commit found. git bisect run <script> automates testing. Efficient: finds bug in O(log n) steps through history.

Git hooks are scripts run automatically at git lifecycle events. Client-side: pre-commit (lint/test before commit), commit-msg (validate message format), pre-push (run tests before push). Server-side: pre-receive (access control), post-receive (deploy, notify). Store in .git/hooks/ (not versioned) or use Husky for team-shared hooks. Common: ESLint + Prettier on pre-commit, conventional commit validation.

fetch: downloads changes from remote but doesn't update working branch (safe, just updates remote-tracking refs). pull: fetch + merge (or rebase if pull.rebase=true) — updates your local branch. Best practice: prefer fetch then review (git log origin/main) then merge/rebase manually. git pull --rebase keeps history linear. git fetch is always safe; git pull changes your branch.

Conventional Commits (widely adopted): type(scope): description. Types: feat, fix, docs, style, refactor, test, chore, perf. Subject: 50 chars max, imperative mood ("add feature" not "added"). Body: wrap at 72 chars, explain what and why (not how). Footer: BREAKING CHANGE, Closes #issue. Example: "feat(auth): add OAuth2 login with Google". Good messages enable: changelog generation, semantic versioning, blame comprehension.

reflog records all HEAD movements (commits, checkouts, rebases, resets) — even for deleted branches. Kept for 90 days by default. Use to: recover lost commits after git reset --hard, find a deleted branch, recover from bad rebase. Commands: git reflog, git checkout HEAD@{3}. Git's safety net — "git reset --hard" is almost never truly permanent.