git: How to rewrite history on commits that you already pushed to the remote/origin
Published 2017-02-14, 18:42
(Written October 2013)
Let’s phrase this another way:
How to rewrite commits that are already on Github?
Ho to clean up commits that I already synced?
How to rewrite public history on git?
As you probably know git is much more flexible with branches, commits and all that stuff than other CVSs like SVN were. Commits are done locally and more like local snapshots that still can be changed, where commits in SVN are directly on the server/repository and can’t be changed. So there are lot’s of tutorials that explain how all this works:
- http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
- http://git-scm.com/book/en/Git-Tools-Rewriting-History
- http://git-scm.com/book/en/Git-Branching-Rebasing
- https://www.atlassian.com/git/tutorial/rewriting-git-history#!rebase-i
- http://sethrobertson.github.io/GitPostProduction/gpp.html
But the one thing all these instructions don’t tell you, is what to do when you already synced (pushed) these commits to the remote origin. We only get quotes like these:
Once you have published/pushed your work to shared repositories, we very much recommend against going through post-production with it. That is known as rewriting public history and in general requires telling everyone of your failings as a developer so that they can do the necessary work to recover on their side.
A word of caution: Only do this on commits that haven’t been pushed an external repository. If others have based work off of the commits that you’re going to delete, plenty of conflicts can occur. Just don’t rewrite your history if it’s been shared with others.
Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.
or my favorite one from the GitHub documentation:
Warning: It is considered bad practice to rebase commits which you have already pushed to a remote repository. Doing so may invoke the wrath of the git gods.
There are good reasons for this if you work with other people.
Obviously this doesn’t help, when you want to rewrite public history. There are lots of cases where you want to do that, especially if you are the only committer to a project and there is noone else to consider.
Before you start playing around with rebase, it’s probably a good idea to make a backup of your current state to a branch:
$ git branch backup-branch
Then if something goes horribly wrong with you workign copy you can just get the old state back:
$ git reset --hard backup-branch
Then you can continue doing the rebase like it is described in one of these tutorials:
And after all that, the magic thing to do is this:
git push --force origin master
By the way, the sources I finally found for this, after fighting for several days, were these:
- http://stackoverflow.com/questions/10054611/how-to-push-new-rewritten-history-to-remote-repository
- http://stackoverflow.com/questions/495345/git-removing-selected-commit-log-entries-for-a-repository#comment10043427_495352
- http://stackoverflow.com/questions/6842627/how-to-clean-all-commits-from-remote-github-repo/6842936#6842936
Zum Artikel git: How to rewrite history on commits that you already pushed to the remote/origin sind noch keine Kommentare vorhanden. Deine Meinung wäre jedoch willkommen!