Git rewriting git history

Git rewriting git history

• 1.
  Git – RewritingGit History Bryan Lin 20131230
• 2.
  Agenda  Overview  gitcommit --amend  git rebase  git rebase -i  git reflog
• 3.
  Overview  Git providesits 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  Rebasingis the process of moving a branch to a new base commit. The general process can be visualized as the following:
• 8.
  git rebase  Froma 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  Gitkeeps 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