Git & Version Control

Version control questions in frontend interviews test day-to-day Git fluency, collaboration workflow understanding, and the ability to recover from mistakes safely. Knowing the commands is table stakes — understanding when and why to use them is what interviewers look for.

Core Git Concepts

• Working tree: your local files
• Index (staging area): what will go into the next commit
• HEAD: pointer to the current commit (usually the tip of a branch)
• Origin: the default remote repository

Everyday Commands

# Status and diff
git status                          # what's changed
git diff                            # unstaged changes
git diff --staged                   # staged changes (what will be committed)
git log --oneline --graph --all     # visual branch history

# Staging and committing
git add -p                          # interactively stage hunks (not whole files)
git commit -m "feat: add dark mode" # conventional commit message
git commit --amend --no-edit        # add staged changes to the last commit (before push)

# Branching
git switch -c feature/dark-mode     # create and switch (preferred over checkout)
git switch main                     # switch to main
git branch -d feature/dark-mode     # delete merged branch

Merge vs Rebase

Both integrate changes from one branch into another. Use merge to preserve history and show when branches diverged; use rebase to create a linear history before merging.

# Merge — creates a merge commit, preserves full history
git switch main && git merge feature/auth

# Rebase — replays feature commits on top of main, linear history
git switch feature/auth && git rebase main
# then: git switch main && git merge --ff-only feature/auth

# Interactive rebase — clean up commits before PR
git rebase -i HEAD~3       # squash, reword, reorder last 3 commits

Recovering from Mistakes

# Undo last commit but keep changes staged
git reset --soft HEAD~1

# Undo last commit and unstage changes (keep files)
git reset HEAD~1

# Undo changes to a file (discard working tree changes)
git restore filename.ts

# Find and restore a dropped commit
git reflog                  # shows all recent HEAD movements
git checkout -b recovery abc1234  # restore from reflog hash

# Stash work in progress
git stash push -m "WIP: form validation"
git stash pop

Pull Request Workflow

# Start a feature
git switch -c feat/user-auth

# Sync with main before opening a PR
git fetch origin
git rebase origin/main   # or: git merge origin/main

# Push and open PR
git push -u origin feat/user-auth

# After PR is merged — clean up
git switch main && git pull
git branch -d feat/user-auth

Conventional Commits

Format: <type>(<scope>): <description>

Types:
  feat:     new feature
  fix:      bug fix
  docs:     documentation change
  style:    formatting (no logic change)
  refactor: neither fix nor feature
  test:     adding tests
  chore:    build, config, dependencies

Examples:
  feat(auth): add OAuth2 Google login
  fix(cart): correct quantity update on re-render
  refactor(api): extract fetchUser into shared hook

Common Interview Questions

• What is the difference between git merge and git rebase?
• How do you resolve a merge conflict?
• What does git cherry-pick do?
• When would you use git bisect?
• What is a detached HEAD state?