How to manually edit Git history (rebase -i)

Editing Git history can be a powerful way to clean up your commit timeline, combine multiple commits into fewer ones, or even delete or amend past commits. In this tutorial, we’ll discuss how to manually edit Git history using the interactive rebase feature.

Understanding Rebase

Rebase is a Git command that allows you to modify your commit history. While the action this command performs can be complex, rebasing is most commonly used to move or copy a series of commits to a new base commit.

Interactive rebasing (rebase -i) gives you the opportunity to alter individual commits during the rebase process. This is especially useful when you want to curate your commit history by merging, rewriting, deleting, or reordering commits.

When to Use Rebase -i

Interactive rebase is best used when:

• You want to edit past commit messages.
• Multiple commits could be merged into a single cohesive commit.
• You need to delete or revert commits.
• You want to reorder the commit history.
• It’s necessary to fix mistakes before they are pushed to a remote repository.

Important: It’s not recommended to rebase commits that have already been shared with others as it can cause confusion and complicate the history for everyone else. Interactive rebasing should be done on commits that have only been pushed to remote branches that you’re solely working on or local branches that haven’t been pushed at all.

Starting an Interactive Rebase

To start an interactive rebase, use the following command:

git rebase -i HEAD~N

Replace N with the number of commits you wish to view in the rebase. Git will display a list of the last N commits in your default text editor.

Rebasing Options

When the list of commits appears, it will look something like this:

pick 12345a1 example commit message 1 pick b789ef2 Another commit message pick fabcd13 Fix for issue #10 ...

You can replace the word pick with commands to tell Git how to treat each commit:

• pick – use commit
• reword – use commit, but edit the commit message
• edit – use commit, but stop for amending
• squash – use commit, but meld into previous commit
• fixup – like squash, but discard this commit’s log message
• exec or x – run shell command (the rest of the line will be executed)
• drop – remove commit

Each of these commands allows you to manipulate how your Git history looks.

Editing Commit Messages

To change a commit message, replace the word pick with reword in front of the commit you want to alter.

reword 12345a1 example commit message 1 ...

Save and close the editor. Git will drop you into a new shell where it will allow you to change the commit message in your editor.

Squashing Commits

If you want to combine several commits into one, you can use squash. Change pick to squash or s next to the commits you want to merge:

pick 12345a1 example commit message 1 squash b789ef2 Another commit message ...

After you’ve modified the file, save and exit the editor. Git will merge the squashed commits into the one above it, and then it will offer you the chance to edit the new combined commit message.

Resolving Rebase Conflicts

Occasionally, you might encounter conflicts during a rebase. If this happens, Git will halt the rebase and allow you to resolve the conflicts manually. Once you’ve resolved the conflicts, continue the rebase with:

git add . git rebase --continue

If you decide you want to abort the rebase and return to the original state, you can do this with:

git rebase --abort

Finishing the Rebase

If everything has been resolved without issue, Git will rebase your commits onto the target branch. Be cautious: if these commits had previously been pushed and others may have pulled them, you’ll need to force push your changes, which can disrupt other’s work. Only force push if you are sure it is safe to do so:

git push origin your-branch-name --force

Conclusion

Interactive rebasing is a powerful tool, but with great power comes great responsibility. Use it wisely to keep your project’s history clean and understandable, and avoid using it on changes that have been pushed to shared repositories.

Remember to use these skills to improve your project’s history and not rewrite it in a way that could trouble you or your collaborators down the line.