Git Workflows, Rebase & Conflict Handling — Interview Questions

How to use this lesson

At 2–5 years, Git questions test judgement under pressure: rewriting history safely, resolving conflicts in critical code, and keeping a team's history useful. Give the commands, and the rule that keeps them safe.

Q1. What's your strategy for managing branches on a collaborative project?

Short answer: Keep main always releasable, and protected (required reviews, required CI checks, no direct pushes). Work on short-lived feature branches (days, not weeks), cut from the latest main. Merge through pull requests with automated tests, then delete the branch. Hide unfinished work behind feature flags, instead of long-lived branches. Use release branches only if you must support several versions.

Key points to cover:

• Name branches consistently (feature/ORD-123-export, fix/…), and use Conventional Commits for readable history and automated changelogs.
• Long-lived branches mean painful merges. Integrate early and often (trunk-based development).

Q2. A merge conflict hits a critical piece of code just before deployment. What do you do?

Short answer:

1. Don't rush it. Pause the release. A wrong resolution in critical code is worse than a delay.
2. Understand both changes. Read both sides and the commits' intent (git log -p), and bring in the authors.
3. Resolve it deliberately, then run the full test suite (and targeted manual checks if it's high-risk).
4. Get a second reviewer on the resolution.
5. If there isn't time, ship the last known-good version, and move the conflicting change to the next release.

Key points to cover:

• Prevention: frequent integration, small PRs, and ownership rules (CODEOWNERS) for critical modules.

Q3. How does git rebase work, and when should you use it instead of merge?

Short answer: git rebase main takes the commits that are on your branch but not on main, temporarily removes them, moves your branch to the tip of main, and replays each commit on top, creating new commits with new hashes. The result is linear history, as if you'd started from the latest main.

Use rebase to update your own feature branch, and to clean it up before merging (squash fixup commits, reword messages). Use merge for integrating shared branches, and whenever the branch has already been pulled by others.

git fetch origin
git rebase origin/main            # replay my commits on the newest main
git rebase -i origin/main         # optionally squash/reorder/reword before the PR
git push --force-with-lease       # the branch was already pushed: update it safely

Common trap: rebasing a shared branch, such as main or a branch teammates have based work on. Rewriting published history forces everyone to recover their clones.

Q4. How do you manage merge conflicts in Git?

Short answer:

1. git status lists the conflicted files.
2. Open each file, and resolve the <<<<<<< / ======= / >>>>>>> regions by intent, not by picking a side blindly.
3. Use git mergetool or your IDE's three-way merge view, which shows the base, ours and theirs.
4. Build and test.
5. git add the resolved files, then git commit (for a merge) or git rebase --continue (for a rebase).
6. Abort cleanly if needed: git merge --abort / git rebase --abort.

Key points to cover:

• git config merge.conflictStyle zdiff3 shows the base version inside the conflict markers, which makes intent clear.
• rerere.enabled=true remembers resolutions for repeated rebases.

Q5. Explain the rebase process, and its advantages over merging.

Short answer: Rebase rewrites your branch's commits onto a new base. Its advantages: a linear, readable history, no noisy "Merge main into feature" commits, easier git bisect and git log, and the chance to tidy commits before review.

Its costs:

• History is rewritten: new commit hashes, and force-pushes are needed.
• Conflicts may have to be resolved per commit.
• It loses the record of when integration actually happened.

Merge preserves the true history, at the cost of a more tangled graph.

Key points to cover:

• Many teams use a mix: rebase locally, and squash-merge or merge PRs into main through the platform.

Q6. How do you clone a repository from GitHub?

Short answer: git clone <url>. Use SSH (git@github.com:org/repo.git) for key-based authentication, or HTTPS with a token or credential manager. Useful options:

• --branch <name> to check out a specific branch;
• --depth 1 (a shallow clone for CI);
• --filter=blob:none (a partial clone for huge repositories);
• --recurse-submodules.

The GitHub CLI's gh repo clone org/repo also works.

Q7. What does git pull do?

Short answer: git pull = git fetch (download new commits into origin/<branch>) plus integrating them into your current branch. By default that's a merge, or with --rebase, a rebase. With --ff-only, it only fast-forwards.

git config --global pull.rebase true     # avoid needless merge commits on pull
git pull --ff-only                        # refuse anything but a clean fast-forward (good for main)

Key points to cover:

• When in doubt, git fetch first, and inspect with git log HEAD..origin/main, before integrating.

Q8. Scenario: you need changes a teammate is still working on in another branch. How do you integrate them?

Short answer: The options, in order of preference:

1. Wait for their PR to merge to main, then rebase onto main. This keeps both histories clean.
2. If you truly can't wait, base your work on their branch: git fetch origin && git rebase origin/their-feature (or git merge origin/their-feature). Coordinate, because their branch may be rebased under you.
3. If you only need one specific commit, git cherry-pick <sha>. Be aware that it duplicates the commit, and can cause conflicts later.

Key points to cover:

• Needing each other's unmerged work is often a sign the tasks should be split differently, or merged earlier behind a feature flag.

Q9. Scenario: after several commits, you find a mistake in an earlier one. How do you correct it?

Short answer:

• Not yet pushed (a private branch): fix it with an interactive rebase. Either mark the commit edit and amend it, or better, commit the fix as a fixup and let Git squash it in.

git commit --fixup=<sha-of-bad-commit>
git rebase -i --autosquash <sha-of-bad-commit>~1      # folds the fix into the original commit

• Already pushed to a shared branch: don't rewrite history. Add a new commit that fixes the problem, or git revert the bad commit.

Q10. How do you review a large number of pull requests effectively?

Short answer:

• Automate the mechanical checks (formatting, linting, tests, coverage, security and dependency scanning), so reviews focus on design and correctness.
• Keep PRs small, with clear descriptions: why, what changed, how it was tested.
• Prioritise by risk and urgency. Use CODEOWNERS to route reviews to the right people.
• Review in focused, time-boxed sessions, with a checklist: correctness, edge cases, error handling, security, performance, tests, readability.
• Use suggested changes, and label comments by severity ("blocking" vs "nit").
• Track review turnaround as a team metric. Encourage everyone to review, not just the seniors.

Learn it in depth → Volunteer for PR Reviews

Follow-up questions this topic invites — and their answers

Q: What's the difference between squash-merge and rebase-merge on a PR? A: Squash-merge collapses the whole PR into one commit on main: a clean history, one commit per feature. Rebase-merge replays each PR commit linearly, keeping individual commits. That's useful when the commits are meaningful, and already tidied.

Q: What does --force-with-lease protect against? A: It refuses to overwrite the remote branch if it has moved since your last fetch (for example, because a teammate pushed). Plain --force would silently discard their commits.

Q: How do you find which commit introduced a bug? A: git bisect start, then mark a bad and a good commit, and Git binary-searches the history. git bisect run ./test.sh automates the whole search.

Q: What is git reflog, and why is it a safety net? A: A local log of every position of HEAD and your branch tips. After a bad reset or rebase, you can find the lost commit there, and restore it with git reset --hard <sha> or git branch rescue <sha>.