Why Git Questions Reveal More Than Any Resume Line

Interview Insights · Git

Why Git Questions Reveal More Than Any Resume Line

SECTION 01What a Git question is really testing

When a resume says 'built an e-commerce app with a team of four', I cannot verify it by reading. So I ask a Git question about it. How did you divide the work? Did each person have a branch? Who merged into main? What happened when two people edited the same file?

These questions are hard to fake because the answers depend on lived moments: the day a conflict broke the build, the pull request that got rejected, the commit message someone complained about. A candidate who did the work answers with small, specific details. A candidate who did not usually answers with definitions.

Q: How did your team of four use Git on this project?

A: We used Git and GitHub for version control.
Everyone pushed their code and we merged it.
Git is very useful for collaboration.

What I hear: no branch names, no review,
no conflict, no single concrete moment.

Q: How did your team of four use Git on this project?

A: Each of us worked on a feature branch, like
feature/cart or feature/payment. We opened pull
requests into main and one other person had to
approve. Once, my cart branch and my friend's
coupon branch both changed cartTotal(), so we
had a conflict. We sat together, kept his discount
logic, and I rewrote my rounding on top of it.

The second answer is not more technical. It is more specific. Branch names, a function name and a decision about whose code to keep are all details that are easy to remember if you lived them and hard to invent on the spot.

SECTION 02Merge vs rebase: the answer that shows judgement

'What is the difference between merge and rebase?' is one of the most common Git questions. Most candidates give a definition. That is fine, but it does not reveal much. What I really want is your judgement: when would you use each, and why?

A merge joins two branches with a merge commit and keeps the true history of when work happened. A rebase replays your commits on top of another branch, which makes history linear but rewrites your commit IDs. Because rebase rewrites history, the usual team rule is simple: rebase your own local or feature branch to keep it up to date, but never rebase a branch others are already building on.

# Bring main's latest changes into my feature branch
git checkout feature/payment
git fetch origin
git merge origin/main
# resolve conflicts if any, then
git add .
git commit            # completes the merge commit
git push origin feature/payment

# History now shows exactly when main was merged in.

# Same goal, linear history, on MY branch only
git checkout feature/payment
git fetch origin
git rebase origin/main
# if a conflict stops the rebase:
#   fix the file, then
git add src/payment.js
git rebase --continue
# or give up safely:
# git rebase --abort

# The branch was pushed before, so its IDs changed:
git push --force-with-lease origin feature/payment

A strong spoken answer sounds like this: 'On my project we merged pull requests into main, because main was shared. Before opening a PR, I rebased my feature branch on main so reviewers saw a clean set of commits.' One sentence of choice and one of reason.

SECTION 03Your commit history speaks before you do

Many interviewers open your GitHub link before the round. Within a minute they can see how you work. Are commits small and frequent, or is there one upload called 'final project'? Do messages explain what changed and why? Is there a .gitignore, or are node_modules and passwords in the repository?

None of this needs a long review. A short scan of the history is enough to form a first impression, and then the interview questions follow from what they saw. If your history has gaps, you can still fix the habits now and explain honestly in the interview.

# See your history the way an interviewer does
git log --oneline --graph --all -20

# How many commits did each author make?
git shortlog -sn

# Which files changed the most?
git log --name-only --pretty=format: | sort | uniq -c | sort -rn | head

# Did secrets ever get committed?
git log -p -S "API_KEY" --all

# .gitignore for a typical Node project
node_modules/
dist/
.env
*.log

# If .env was committed by mistake:
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "stop tracking .env file"

# Then rotate any key that was in it.
# Removing the file does not remove it from old commits.

Do not rewrite an old project's whole history just to look better. If someone asks why the early commits are messy, say so plainly: 'That was before I learned to commit in small steps. You can see the newer project is different.' Growth is a good story.

SECTION 04Prepare your Git evidence before the interview

Use these worksheets to turn each project on your resume into ready Git stories. Fill them in from memory first, then check your repository to confirm the details are correct.

PROJECT: ______________________

Team size and my role: ______________________
Branching approach we used: __________________
Who reviewed and merged PRs: _________________

One merge conflict I resolved:
  File / function: ___________________________
  Why it clashed: ____________________________
  How we decided: ____________________________

One thing I would change in our Git workflow:
______________________________________________

MY ONE-MINUTE ANSWER

Definition (one line each):
  merge  -> joins branches with a merge commit
  rebase -> replays my commits on top of another

What we used on my project: __________________
Why: _________________________________________

My safety rule:
  Never rebase a branch others have pulled.
  After rebasing my own pushed branch,
  push with --force-with-lease.

BEFORE SHARING A GITHUB LINK

[ ] README says what it does and how to run it
[ ] .gitignore exists, no node_modules or build
[ ] No .env, keys or passwords in history
[ ] Recent commits have clear messages
[ ] At least one feature branch merged by PR
[ ] I can explain the last five commits
[ ] Repo name and description match the resume

Any box unchecked? Fix it or prepare
an honest one-line explanation.

SECTION 05Small habits that make your Git answers believable

Believable answers come from real habits. These are easy to start this week, even on solo projects.

• Use branches even alone — Create a branch for each feature and merge it with a pull request to yourself. You will have real branch and PR stories to tell.
• Write messages for a stranger — A commit message should tell someone who never saw the code what changed and why. Interviewers read them as a sample of your communication.
• Remember your conflicts — When you resolve a conflict, write one line about it in your notes. These small stories are gold in interviews and easy to forget.
• Review a friend's PR — Leave real review comments on a classmate's pull request. Then you can honestly answer questions about code reviews.
• Say 'I' for your part — In team stories, be clear about which branch, commit or decision was yours. 'We did everything' hides your contribution.

SECTION 06Interview Q&A — Git as evidence

SECTION 07Test yourself — Git as evidence quiz

SECTION 08Frequently asked questions

SECTION 09Related reads