Rebase your own feature branch onto the main branch to keep history linear and resolve conflicts in small doses before review. Merge when integrating that branch into a shared branch, and never rebase a branch other people have already pulled, because rewriting shared history forces everyone into a recovery. In short: rebase private work, merge public work, and squash when the commit history adds nothing for future readers.
Why interviewers ask this
Git usage tells the interviewer how you work with other people. They want the private versus shared history rule, an understanding that rebase rewrites commits rather than moving them, and pragmatism about team convention. Someone who insists on one strategy everywhere, or who cannot explain why force pushing a shared branch causes damage, tends to create friction on a team.
How to structure your answer
- State the private versus shared branch rule.
- Explain what rebase actually does to commit ids.
- Say when you would squash instead.
- Defer to team convention where one exists.
Example answer
My rule is rebase private history, merge shared history. While a feature branch is mine, I rebase it onto main regularly, because it keeps the diff honest and I would rather hit conflicts in three small doses than one enormous one at the end. When it goes into main I merge, usually squashed, because nobody reading the log in six months wants my fix typo commits. What I will not do is rebase a branch somebody else has pulled, since rebase does not move commits, it creates new ones with new hashes, and everyone else's copy of the originals is now orphaned. That means a force push and somebody losing work. I have had to walk a colleague through the reflog to recover from exactly that. Beyond the rule, I follow whatever the team already does, because a consistent history everybody understands beats my personal preference, and this is not a hill worth dying on in code review.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you recover a commit lost after a bad rebase?
- What does an interactive rebase let you clean up?
- How do you handle a long lived branch that has drifted badly?
Related software engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions