Git Pocket Guide

Chapter 10. Editing History

In this chapter, we cover various techniques for editing repository history. Earlier chapters covered simple cases of this, focused on correcting individual commits; here, we’re concerned with larger changes: moving branches, merging or splitting repositories, systematically altering an entire history, and so on.

The caution given earlier bears repeating here: you should not generally use any of these techniques on history that has already been published to other people! It will break their ability to use the push/pull mechanism, which may be very difficult and awkward to recover from. Only use these on private repositories, or if you can coordinate the change with everyone involved. It’s easiest if all users of a shared repository commit and push all their outstanding changes, then simply reclone it after you make your edits. Or, they can use git rebase instead as we are about to describe, if they’re a bit more adventurous.

Rebasing

We have already covered special cases of rebasing, especially for editing a sequence of commits at a branch tip; here, we consider the general case. The general purpose of git rebase is to move a branch from one location to another. Since commits are immutable, they can’t actually be moved (their parent commits would change), so this entails making new commits with the same changesets and metadata: author, committer, timestamps, and so on. The steps Git follows during a rebase are as follows:

1. Identify the commits to be moved ...