How to use Git rebase to change commit history

I had to change some of my Git history because I had used the wrong Github user to push some changes to personal projects.

I just needed to change the user that committed the code without changing any of the other history. I don’t use rebase very often so here are my notes on this.

It’s ok to make changes like this to master/main branch on personal projects because you’re the only person using the repository.

But you probably don’t want to do this on anything other than a feature branch when you’re working in repo with many other users. You could really mess up some of your colleagues work. It’s most likely that your master branch is locked against making destructive changes anyway.

Superpower tip - First create a restore marker or tag if you’re unsure of rebasing

Rebase changes your Git history. This is destructive and you want to be able to revert it if you’re not happy at the end.

I highly recommend creating a “restore point” tag to go back to if you need it. You wont need this for every rebase but it’s really handy for tricky ones.

git tag REBASERESTORE_20210320_DARRAGH

Now you can undo the rebase later with

git reset --hard REBASERESTORE_20210320_DARRAGH

There is a default tag called ORIG_HEAD that points to the tag before you started a destructive action but it is controlled by Git. You can use this to reset to the current state of your repo but I prefer to have a tag that I know will not change before I need it.

## Find the last commit that was good

Find the hash of the commit that was ok. This is the commit just before the one(s) you need to change.

If you need to rebase from the first commit use `git rebase -i --root`

## Start the rebase by using interactive

```shell
git rebase -i f56f4c6c370d6c80ce35d1300fb8fde7b7a442f1

Output from Git interactive below. Using the defaults Git will open a text editor in the console showing you the commits that can be changed.

You will edit the lines in the file describing the changes you want to make and then save the file.

  GNU nano 2.0.6 File: ...ordan-com/.git/rebase-merge/git-rebase-todo

pick d6a295d change date
pick 1464991 migrate to gatsby v3

# Rebase 17c9b0e..1464991 onto 17c9b0e (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]

Deleting commits in Git rebase interactive

To delete a commit completely just comment out the line with #. e.g.

  GNU nano 2.0.6 File: ...ordan-com/.git/rebase-merge/git-rebase-todo

# pick d6a295d change date
pick 1464991 migrate to gatsby v3

Git will delete this commit. Make sure you really want this. The code is gone.

Changing the author of commits in Git rebase interactive

To change the author you must set the commit to edit (or e)

  GNU nano 2.0.6 File: ...ordan-com/.git/rebase-merge/git-rebase-todo

e d6a295d change date
pick 1464991 migrate to gatsby v3

Rebasing the commits to the previous commit in Git rebase interactive

To combine the commit with the previous commit you use rebase (or r). This can be useful if you need to edit the name on many commits because you can just combine them into one first. Then do another rebase afterwards to change the author of one commit.

  GNU nano 2.0.6 File: ...ordan-com/.git/rebase-merge/git-rebase-todo

r d6a295d change date
r 1464991 migrate to gatsby v3

Save rebase configuration

You need to save the file. In nano use ctrl-o and use the name Git suggests by just pressing enter. Then press ctrl-x to exit the editor. This might be different for you depending on operating system or your settings.

Rebase interactive will start running through each of your requests one-by-one.

Working through interactive edits

For each commit that you chose to edit (e) Git will ask you what changes you want to make. To change the author use

git commit --amend --author="Darragh O'Riordan <darragh.oriordan@gmail.com>" --no-edit

Note the --no-edit here. This is important. If you don’t use --no-edit then Git will create a NEW commit with your changes. We don’t want this. We just want to edit the existing commit.

Now Git will suggest you move on to the next commit you asked to edit so we ask it to continue

git rebase --continue

Keep going until the rebase command finishes. Git will print a message when it’s done.

Successfully rebased and updated refs/heads/master.

Pushing the changes

So you’re all done. Now you might need to update the origin.

Make sure you know that it’s safe to push these changes to your origin.

It’s probably safe if you’re on a feature branch only you have worked on or if it’s a personal project that only you commit to. Just push with —force.

git push --force

Aborting a rebase

You can abort in the interactive stage with

git rebase --abort

Undoing or reverting a messed up Git rebase

OK so this will vary depending on what you’ve done.

If you have created a restore point you can go back to that

git reset --hard REBASERESTORE_20210320_DARRAGH

If you just realized you did something wrong right after seeing Successfully rebased and updated refs/heads/master then you can probably use a restore point that Git automatically creates for us at ORIG_HEAD.

git reset --hard ORIG_HEAD

Please note that running this again will go back to the next ORIG_HEAD before the last reset, rebase or merge so be careful.

If you don’t have either of those available then you might be in trouble.

If you get an error like

warning: could not read '.git/rebase-merge/head-name': No such file or directory

Then you can completely quit the messed up rebase with

rebase --quit
Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨ https://devshell.darraghoriordan.com


Read more articles like this one...

List of article summaries

#developer-experience

Start tracking DORA metrics for your team in just 15 minutes with Apache Dev Lake

DORA (DevOps Research and Assessment) metrics are an excellent way for engineering organisations to measure and improve their performance.

Up until now, monitoring the DORA metrics across Github, Jira, Azure Devops etc required custom tooling or a tedious manual process.

With Apache Dev Lake you can get beautiful reporting for DORA metrics on your local machine in as little as 15 minutes (honestly!).

From Google Sheets to Grafana
From Google Sheets to Grafana

#developer-experience

How to use SSH with Git and ssh-agent on Windows

I needed to run git natively in windows (no wsl) for a recent project. I use ssh certificates with passphrases to authenticate with my git provider.

Ssh requires the certificate passphrase every time you use a connection. It’s annoying typing this passphrase in to terminal when using a git command.

#developer-experience

How to fix custom type definitions not being type checked

If you have a custom types file (e.g. myTypes.d.ts) but you get no errors from the type checker and compiler in typescript even though you know there are issues in the file you might have skipLibCheck turned on.

#developer-experience

Consistent modern shell tooling on MacOS and Windows WSL for developers

I regularly code on both MacOS and Windows machines and I was always annoyed how different the default experiences are on each. I need to use the same tools and the same experience on both.

Windows “WSL” (Windows Subsystem for Linux) is a great tool for this you can use on Windows 10 and newer. The latest version lets you run a full Ubuntu instance that integrates seamlessly with the underlying windows instance.

By using WSL2 you can have a (mostly) identical developer experience jumping between MacOS and Windows.

Better tooling for Developers

Many of the terminal tools that come with unix environments are functionally similar to how they were 20 years ago. But other developer tooling has advanced quite a bit since then.

You can replace tools like ls or cat with modern equivalents that support full colour, unicode icons, git state and more. Terminal prompts can be made git aware and use colour to indicate state so you don’t have to query git so often.

Keeping developer experience consistent across machines

Keeping any shell changes you make on one machine up to date on all the machines you code on is a nightmare without the right tooling.

This article also explains all the tools I use and how I keep the same terminal setup consistent on MacOS and Windows!

Let’s go!

Comments