The OP's problem as I understand it
This answer applies if you don't actually want to rebase on top of master, but you'd rather just squash all commits into one, since diverging from master.
The problem with rebasing from a different branch
The problem with git rebase -i master
is that you may have merge conflicts that you don't necessarily want to deal with at the moment, or you may fix a conflict in one commit, only to fix it again in another commit during the course of the rebase.
The problem with rebasing from a known commit
The whole problem here is that you have to know which commit you have to refer to, either by its SHA, or HEAD~x, etc. This is only a minor annoyance but it is an annoyance.
The better way
If you instead want to rebase all the commits in your current branch, since the most recent commit it shared with its parent branch, you can add the following alias to .gitconfig:
rbi = !sh -c \"git rebase -i `git merge-base $1 HEAD`\" -
Usage
git rbi parentBranch
You can then use an interactive rebase to pick/reword/edit/squash/etc all commits in your branch, since it diverged from the parent branch. My typical flow is to pick the oldest commit (the one at the top), and set all other commits to f (or fixup).
How it works
This alias is just a shell script, that is using an argument which refers to the parent branch. That argument is passed into git merge-base
in order to determine the most recent shared commit between that branch, and the current branch.