Getting Started Abort or Undo a Merge
Abort or Undo a Merge
Cancel an in-progress merge, undo a completed merge with reset, or create a branch from the commit before a merge in GitComet.
If you merged the wrong branch or changed your mind, the next step depends on whether the merge is still in progress. Use Abort merge while Git is waiting for the merge to finish. Once the merge has completed, use a reset or create a new branch from the earlier commit.
Abort an in-progress merge
- Open the affected repository in GitComet. The repository action bar shows MERGING while a merge is in progress, including when it has stopped on conflicts.
- Choose the red Abort merge button beside MERGING. In a compact layout, the button is labeled Abort.
- Review the confirmation and choose Abort merge to cancel the operation.
GitComet runs the equivalent of git merge --abort and refreshes the repository state. Any conflict-resolution work done during the merge is lost. If you need to keep those edits, copy them elsewhere before confirming.
Git tries to restore the state from before the merge. If you started the merge with uncommitted changes, it may be unable to reconstruct those changes completely; see Git's merge abort behavior.
Undo a completed local merge
A merge that completes without conflicts may immediately create a merge commit or fast-forward the branch. There is then no merge in progress to abort. To undo the last merge before pushing it:
- Check out the branch that received the merge. Reset acts on the current branch, even if you right-click a commit from another branch.
- In the history, find the commit that this branch pointed to before the merge. For a merge commit, this is its first parent, on the branch that received the merge. For a fast-forward, choose the branch's original tip; there is no merge commit.
- Right-click that earlier commit and choose a reset mode from the options below.
- Check the target and mode in the confirmation dialog, then choose Reset.
- Reset (--soft) to here moves the branch to the selected commit and keeps the staging area and files unchanged. With a clean working copy before resetting, the merge's changes remain staged.
- Reset (--mixed) to here moves the branch and resets the staging area to the selected commit. Files stay unchanged, so the merge's changes remain in the working copy for review.
- Reset (--hard) to here moves the branch and restores tracked files and the staging area to the selected commit, discarding local changes to tracked files. Untracked files that obstruct restoring tracked paths can also be removed.
Use hard when you want to discard the merge's file changes as well as move the branch back. Commit, stash, or copy any local work you need first. Reset also removes any later commits from the current branch's history, so check the target carefully. See Git's reset modes for the underlying behavior.
Continue from a new branch
To keep the original branch and its merge available while continuing from the earlier state:
- Right-click the commit that the branch pointed to before the merge.
- Choose Create branch from this commit.
- Enter a new branch name and enable Checkout to switch to it when it is created. You can also create it first, then right-click the new branch and choose Checkout.
The new branch starts before the merge. The original branch still contains the merge, so you can return to it or compare the two branches. Keep the original branch until you are sure you no longer need its work.
If the new branch should track the same remote branch, check it out, right-click that remote branch in the sidebar, and choose Set as tracking upstream. This sets the new branch's upstream; it does not change the remote branch's history.
Handle a merge that was already pushed
Reset changes your local branch. Creating a new branch also leaves the remote unchanged. Neither action by itself undoes a merge that was already pushed.
Replacing the remote history after a reset requires a Force Push, and branch protection or repository policy may forbid it. GitComet uses git push --force-with-lease, but the operation still rewrites published history. Agree on that rewrite with anyone sharing the branch before proceeding; see Git's force push behavior.
For a shared branch, consider reverting the merge with a new commit instead. A revert preserves the published history, although reverting a merge affects what future merges from the same branch bring in.
Related discussion: Abort merge and undoing a completed merge.