TL;DR: Fetch normally updates remote-tracking refs without integrating into your checked-out branch. Pull fetches and then integrates according to its selected policy. Rebase can recreate commits on a new base, changing their identities. Use it for private work or a coordinated rewrite; preserve published shared history by default.
How to approach it
Draw the divergence and name who has based work on each commit. That explains the collaboration risk more clearly than arguing that one history looks cleaner. Separate the local operation from publishing its result: a local rebase becomes a shared-history problem when the rewritten branch replaces a ref other people use.
A strong answer
With a normal remote configuration, git fetch origin updates refs such as origin/main. Your checked-out files and local branch remain unchanged. Inspect the incoming commits before integrating them. Pull combines fetching with an integration policy: --ff-only refuses divergence, --rebase selects rebasing, and --no-rebase selects merging. Specify the policy explicitly in automation so configuration changes do not change its behaviour unexpectedly.
Imagine main advanced from A to B while a feature branch added C and D after A:
Before: After rebasing the feature onto B:
A---B main A---B main
\ \
C---D feature C'---D' feature
C' and D' carry the replayed changes with new ancestry. They have different commit identities even when the resulting file changes are equivalent. Rebase can also skip already-applied patches or stop on conflicts; it does not promise a one-to-one copy of every original commit. A rebase that has nothing to do may leave history unchanged.
I would rebase my private feature branch when I want to resolve its changes against current main before review. On a shared integration branch, I would merge by default so colleagues retain the ancestry they already have. A team can agree to rewrite a shared feature branch, but that requires coordination with its consumers and a recovery plan. Branch protection should encode the team's publication policy.
Worked recovery: replay only the collaborator's new work
In this fictional example, another developer added E after the old D. The feature owner then published C' and D'. The collaborator must place E on top of D', while avoiding replaying the obsolete C and D. First pause further updates to the affected branch and save any uncommitted work. A backup branch preserves committed history only.
Suppose the collaborator's branch is named my-work, the rewritten upstream is origin/feature, and they have identified the exact old D commit. Create a local old-feature-tip ref at that verified commit before running this example:
git switch my-work
git status --short
# Continue only after saving any uncommitted work.
git branch backup-before-recovery
git fetch origin
git log --oneline old-feature-tip..my-work
git rebase --onto origin/feature old-feature-tip my-work
The log should show only the commits to carry forward, E in this example. --onto names the new base; old-feature-tip establishes the selection boundary. After resolving any conflicts, compare the patch series and run the relevant tests. If the boundary is uncertain or the branch contains merges, inspect the graph and choose a recovery procedure for that history instead of applying these commands blindly. Git documents recovery after an upstream rebase.
The backup keeps the original committed work available while checking the result. git rebase --abort returns from an in-progress rebase; after a completed rebase, use saved refs or the reflog to locate earlier commits. Create a recovery branch before attempting a destructive reset.
What interviewers probe next
"Does force-with-lease make publishing a rewrite safe?" It protects against replacing a remote ref whose value differs from the expected value. The shorthand often relies on a remote-tracking ref that a background fetch can advance. An explicit expected SHA ties the lease to the tip you reviewed. Neither form proves that colleagues have no unpublished work based on that tip, so coordination is still required. See Git's lease semantics.
"Why retain a merge commit?" It records which histories were integrated. Reverting its changes requires choosing the appropriate mainline parent, for example git revert -m 1 <merge-sha> when parent 1 is the branch whose perspective you intend to retain. Verify parent order rather than copying that number by habit. Reverting a merge also affects what later merges bring back; the original commits remain in ancestry.
"Would squash merging simplify recovery?" It gives main one commit for a change, which can simplify locating and reverting the code patch. Later commits may depend on it, and external side effects remain. Database writes and deployed configuration require their own recovery checks even when the Git revert is conflict-free. The same distinction appears in deploying versus releasing.
Common mistakes
Saying that rebase simply moves existing commits. Trace the parent relationship and resulting identity change when commits are replayed.
Running a blind pull after an upstream rewrite. Identify the old upstream boundary and preserve local work first.
Assuming a successful revert restores the running service. Git changes source history; deployment, compatibility and data recovery determine production behaviour.