git reflog
git stash
git reset --hard HEAD@{N}
git rebase -i HEAD~N
git log --oneline -N
git stash pop
git push --force-with-lease origin <main>

Previous

I was convinced I did it well, but I actually messed with my rebase operation. The main concern is to identify at which point I want to rewind the HEAD back with the reflog command and, as it has now become usual, stash the changes away.

Reach

This method can be applied right after a poorly done rebase, so basically moving back the HEAD before the rebase started with the reset command and the --hard flag.

Rebase again

git stash -u
git rebase -i HEAD 2
git log --oneline -2
git push force-with-lease origin main
git stash pop

I use this workflow, when I notice that the message I used in the last couple of commits are not describing well enought the changes and perhaps conflicting with each other. In the case my repository already has been pushed remotely, I take even more in consideration the warnings around rebasing in git. It changes the previous commits hashes, which will cause issues with cloned repositories. That is still a fair method to use in an early stage project which is not yet involved in collaborative work. It is not the first time that figure out I want to rebase after I have moved along in the development of the project, even though I try my best to be as meticulous as I can when organizing the commits. Yet these changes made from where the HEAD currently is, have to be set aside using the stash command with the -u flag to also include untracked files.

git stash -u

This makes a clean working directory for git to be happy enought so it let me rebase, and the changes can be poped out anytime the procedure is done.