Suggest an editImprove this articleRefine the answer for “Which is easier to roll back: merge or rebase?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**A merge** is usually easier to roll back, because it does not rewrite history and adds a separate merge commit that is easy to undo with `revert`. **Key point:** `rebase` rewrites history, so rolling it back after it is finished (especially after a push) is harder and may require reset/reflog and a force push.Shown above the full answer for quick recall.Answer (EN)ImageUsually it is **easier to roll back** a `merge`, because `merge` **does not rewrite history** and (often) adds **a single, separate merge commit** that is easy to "revert". `rebase`, on the other hand, **rewrites history**, and "rolling it back" more often means **returning the branch to an old state/commit**, which requires care (especially if it has already been pushed). --- ## Why a merge is easier to roll back ### If the merge has already been committed A separate merge commit `M` appears in the history. It can be safely undone with: ```bash git revert -m 1 <hash_merge_commit> ``` - Git will create a **new commit** that undoes the changes introduced by the merge. - The history stays intact. - This is safe for branches that are already in the shared repository. This is a favorite interview answer: "a merge is rolled back with revert". --- ## Why a rebase is harder to roll back ### While the rebase is in progress If the rebase stops on a conflict or you change your mind, it is easy: ```bash git rebase --abort ``` This really is simple. ### But once the rebase is finished You now have **new commits with new hashes**. "Rolling it back" usually means: - finding where the branch was before the rebase (often via `reflog`) - moving the branch back (for example, with `reset`) And here it matters: - locally this is fine - **if you have already pushed the rebase**, you will have to do a **force push**, which is a risk for the team --- ## Summary by situation - **A merge is easier to roll back**, especially on shared branches: `revert` is safe and clear. - **A rebase is easier to "undo" if it is not finished yet**: `rebase --abort`. - **The hardest case** is rolling back a rebase *after a push*, because the history has already been rewritten and you need to act carefully. --- ## Short phrasing for an interview > **A merge is easier to roll back: it preserves history and is usually undone with** `git revert` **(including the merge commit). A rebase rewrites history, so rolling it back after it is finished (and especially after a push) is harder and may require reset/reflog and a force push.**For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.