If a Git rebase stopped while you were working on a Mac, first check whether it is still in progress with git status. To resume, resolve each conflict, stage only the files you resolved, and run git rebase --continue. To return to the branch state from before the rebase, run git rebase --abort. These choices do different things, so confirm which outcome you want before entering a command.

1. Reopen the repository and check its state

Open Terminal from Spotlight or Finder’s Applications > Utilities folder. In Terminal, go to the repository’s top-level directory, then inspect its state:

cd '/path/to/your/repository'
git status

Replace the example path with your repository’s path. If you type a path containing spaces or shell metacharacters, put it in single quotes, as shown. Terminal’s default shell is zsh, though an administrator or your settings may specify another shell. Apple’s Terminal guide

If Git reports that a rebase is in progress, read the status output for conflicted paths and the current step. If it does not report an active rebase, don’t run --continue or --abort speculatively; review the status and recent history before deciding what happened. git status reports working-tree and index changes, including untracked files, so read its full output rather than assuming every file belongs to the rebase. Git’s git status documentation

2. Resume by resolving conflicts carefully

Open each conflicted file in your editor. Git marks text conflicts with sections such as <<<<<<<, =======, and >>>>>>>. Decide what the final content should be, edit the file, and remove the conflict markers. Don’t accept one side automatically unless that matches the intended code or text. Git’s rebase guide describes the conflict-resolution sequence: edit the files, stage the resolutions, then continue. Git’s git rebase documentation

Return to Terminal and inspect the relevant changes before staging. For example:

git diff

Stage each resolved path by name, using the real path shown by git status:

git add 'path/to/resolved-file'
git status
git rebase --continue

The quotes protect paths with spaces or shell metacharacters; omit them if the path does not need quoting. git add stages the current contents of the named file, so inspect the diff first if it contains unrelated edits. Check status again to confirm the right resolution is staged. Git may stop again at another conflict or ask you to edit a commit message; follow the prompt, then repeat the resolve, stage, and continue steps. Git’s git add documentation

Use git rebase --skip only when you deliberately want to omit the commit currently being replayed. It advances past that patch; it is not another way to resume the same commit. If you are unsure whether skipping would discard needed work, don’t use it. Git’s git rebase options

3. Abort when you want to undo the rebase

If you want to stop the operation and return to the original branch state, run:

git rebase --abort
git status

Git documents --abort as resetting HEAD to the original branch position (or to the supplied branch, if one was specified when the rebase began). Then check status and verify that the result is what you expected. Git’s git rebase documentation

Avoid confusing --abort with --quit. git rebase --quit ends the rebase operation while leaving HEAD, the index, and working tree as they are at that moment. Choose it only if you specifically want to stop the rebase but retain the current in-progress state; it does not restore the pre-rebase branch position. If the rebase used --autostash, Git saves that temporary stash when quitting. Git’s git rebase options

4. If Terminal closed or the state is unclear

Closing a Terminal window does not, by itself, tell you whether Git completed the rebase. Reopen the repository and run git status; continue from the reported state. Don’t rerun the original git rebase command while an existing rebase is active.

If an interrupt left the repository in a state where Git no longer recognizes an active rebase, avoid manually deleting .git state files or using reset --hard as a guess. Git’s documentation notes that an ill-timed interrupt with the apply backend can leave a rebase that a later --abort cannot cleanly abort. First preserve any valuable uncommitted work, then inspect git status and git reflog to understand recent branch movement. The reflog records recent local updates to branch tips; it can help identify a previous commit, but restoring one should be deliberate. Git’s rebase interruptability notes, Git’s git reflog documentation

For the ordinary interrupted-conflict case, the safe decision is simple: resolve and stage the intended changes before --continue, or use --abort when you want to abandon the rebase and return to its starting point. Recheck git status after either action so you know what state your Mac’s working copy is actually in.

Sources