git rebase -i can be a pain.
previously I could
git rebase -i HEAD~2
git rebase -i COMMITHASH
git rebase -i --root # never do this one it breaks stuff.
Well, they could all potentially break stuff.
Because for example, lets say HEAD~20 is greater than the changes you made on your branch. Well rebase writes a new commit each time. So when you go to merge the branches will say,
"hey these commits do not match", not good and wants to make a lot of changes.
To get around this you pay alot of attention to git log;
and git log --patch;
The main people should be using rebase is to squash commits and fix their branch to be aligned with dev branch or master branch.
Answering the question below. Because I figured this out today and it worked!
What you really want to do if say your aim is to squash commits:
git rebase -i dev
This will find the commit changes from your current branch that differ from dev and you can change them to "s" to squash the commits.
Squashing made simple.
This ensures that your rebase will not cause trouble; in this example dev branch you can git rebase -i dev as many times as you want and it will never break the branch. Finally the branch will not break when you merge it into dev later after squashing is complete.