Git rewriting git history
- 1. Git – Rewriting Git History Bryan Lin 20131230
- 2. Agenda Overview git commit --amend git rebase git rebase -i git reflog
- 3. Overview Git provides its history-rewriting commands under the disclaimer that using them may result in lost content. Discusses some of the most common reasons for overwriting committed snapshots and shows you how to avoid the pitfalls of doing so
- 4. git commit --amend The git commit --amend command is a convenient way to fix up the most recent commit
- 5. git commit --amend Usage git commit –amend Combine the staged changes with the previous commit and replace the previous commit with the resulting snapshot
- 6. git commit --amend Discussion Don’t Amend Public Commits Amended commits are actually entirely new commits, and the previous commit is removed from the project history. This has the same consequences as resetting a public snapshot.
- 7. git rebase Rebasing is the process of moving a branch to a new base commit. The general process can be visualized as the following:
- 8. git rebase From a content perspective, rebasing really is just moving a branch from one commit to another But internally, Git accomplishes this by creating new commits and applying them to the specified base—it’s literally rewriting your project history
- 9. git rebase Usage git rebase <base> Rebase the current branch onto <base>, which can be any kind of commit reference (an ID, a branch name, a tag, or a relative reference to HEAD)
- 10. git rebase Discussion The primary reason for rebasing is to maintain a linear project history
- 11. git rebase Discussion Two options for integrating your feature into the master branch: merging directly rebasing and then merging
- 12. git rebase Discussion Don’t Rebase Public History The rebase would replace the old commits with new ones, and it would look like that part of your project history abruptly vanished
- 13. git rebase -i Running git rebase with the -i flag begins an interactive rebasing session Instead of blindly moving all of the commits to the new base, interactive rebasing gives you the opportunity to alter individual commits in the process
- 14. git rebase -i Usage git rebase -i <base> Rebase the current branch onto <base>, but use an interactive rebasing session. This opens an editor where you can enter commands (described below) for each commit to be rebased. These commands determine how individual commits will be transferred to the new base. You can also reorder the commit listing to change the order of the commits themselves
- 15. git reflog Git keeps track of updates to the tip of branches using a mechanism called reflog This allows you to go back to changesets even though they are not referenced by any branch or tag After rewriting history, the reflog contains information about the old state of branches and allows you to go back to that state if necessary
- 16. git reflog Usage git reflog Show the reflog for the local repository. git reflog --relative-date Show the reflog with relative date information (e.g. 2 weeks ago).
- 17. git reflog Discussion Every time the current HEAD gets updated (by switching branches, pulling in new changes, rewriting history or simply by adding new commits) a new entry will be added to the reflog
- 18. git reflog Example To understand git reflog, let's run through an example The reflog above shows a checkout from master to the 2.2 branch and back The latest activity is represented at the top labeled HEAD@{0}
- 19. git reflog Example If it turns out that you accidentially moved back, the reflog will contain the commit master pointed to (0254ea7) before you accidentially dropped 2 commits. Using git reset it is then possible to change master back to the commit it was before
- 20. FAQ