git rebase --continue and --stepback?

Yes there is. How to step back during an interactive rebase:

1. Get the commit hash of your current HEAD, for example with git rev-parse HEAD
2. run git rebase --edit-todo
3. insert a pick with that hash to the top of that file pick <hash from step 1>
4. run git reset --hard HEAD^ (this is a hard reset so if you have done anything you want to keep make sure to store it somewhere e.g. git stash before you run the command)

Now you are still in the rebase but one commit back and you are free to continue rebasing with

5. git rebase --continue.

If you don't want the undone commit to be picked straight up without edits you can add edit <HASH> instead of pick <HASH> to the todo list (step 3).

Addendum: You can remember more hashes, reset to an even earlier point and add multiple picks to redo more than one commit.

Idea from: http://arigrant.com/blog/2014/5/4/git-rebase-stepping-forward-and-back

Actually you can even if you're not doing interactive rebase.

As johnb003 mentioned in his comment, when rebasing, you're really making a series of new commits. By doing something such as git log --pretty=oneline --abbrev-commit, you can easily see all the commits you've already made through the rebase. Simply copy their hashes for easy reference later.

Then git rebase --abort, git rebase -i <base_branch>, copy the hashes you want to preserve, possibly change them to edit if you want to modify any of them, and continue

Nope, as Magnus said.

However,

• git-rerere could come close to what you want in a way: if there were previous manual conflict resolutions that you didn't want to loose, you can enable rerere (prerecorded conflict resolutions) so that they will automatically be resolved in the same way on subsequent merges. Note that this means that you'll have to remember what part you want to resolve differently next time (presumably the goal of having a step-back in the first place?) because - well, rerere assumes you want to applies the same resolution again.

If you look at the implementation of rebase, you might be able to figure out alternative settings for GIT_WORK_TREE/GIT_DIR/GIT_INDEX; You could then perhaps use plumbing commands with a reflog for the rebase-in-progress branch?

• this takes you deep into undocumented internals (beyond the plumbing)
• you might just as well propose a patch to rebase that implements --step-back