* 080dc7a (HEAD, origin/master, origin/HEAD, master)
*   bfeee2f
|\  
| * 16e94ff (origin/McLongNumber, McLongNumber)
| *   f50319b
| |\  

These are the last 4 commits of my working tree. I would like to rebase so that my working tree looks like the following example by squashing the last commit to the merge, preserving the rest of the tree exactly the way it is:

*   bfeee2f (HEAD, origin/master, origin/HEAD, master)
|\  
| * 16e94ff (origin/McLongNumber, McLongNumber)
| *   f50319b
| |\  

I already tried using --onto -p and -i without any success. Even by using the -p option when I managed to successfully squash the last commit, the tree line that showed the merge of 开发者_C百科McLongNumber to the master branch was lost from the log. So I guess someone who is more familiar with the rebase command can help me out on this.

---

You can do it like this:

# make 'master' point to it's parent commit,
# but don't modify the index or working directory
git reset --soft HEAD^

# rewrite the commit using the stuff in the index
git commit --amend

# publish the modified commit (see WARNING below)
git push -f

Note that the SHA1 will change; it will no longer be bfeee2f.

WARNING

It's almost always a VERY BAD idea to rewrite history that has already been published to a shared repository. Most shared repositories are configured to reject history modifications, even if the -f option to git push is used. Thus, you might not be able to do what you want anyway.

The only times it is acceptable to rewrite published history are:

• You are the only person using the upstream repository and you know how to recover from a history rewrite in your other clones.
• The other users of the shared repository know how to recover from rewritten history AND you've warned them that you've rewritten the history AND you've taken care to make sure important changes won't be discarded when you force push. Even so, rewriting history is highly disruptive to others; it's a great way to seriously annoy your co-workers/collaborators/contributors.