Git Rebase — how to use interactive rebase properly

Fred Wong
fredwong-it
Published in
4 min readOct 7, 2019

--

I seldom use interactive rebase in the git but recently I learn a best practice from co-worker and I would like to share my experience in here.

old approach (bad practice)

  • make changes on local develop branch
  • never commit
  • git pull from develop after complete a feature
  • branch off from develop branch to a feature branch
  • commit, push to origin in feature branch
  • create pull request

(since the feature branch had the latest from develop branch so there weren’t any conflicts most of the time)

However, there will be a chance of conflicts if the pr don’t not merge back to develop soon enough

new approach (best practice)

  • create feature branch from develop when you start on a ticket
  • rebase the feature branch against develop everyday (to keep your feature branch updated with develop branch)

Git Rebase

Git rebase is confusing to people who never use it and things will be messed up easily if you don’t do it properly (just like me)

I messed things up and the commits in rebase getting more and more. I original had 10 commits and there were 38 commits at the end after I did the rebase incorrectly after a few times repeatedly.

There were a few duplicated commits like the following

pick 50560612 A20-3308: first commit
pick 0371a340 A20-3308: update failed test
pick b0e46622 A20-3308: add test cases
pick 19b093b9 first commit
pick 1f68040d update failed test

It was because after I finish the rebase, git told me that my local feature branch diverge from remote feature branch and it asked me to merge from remote feature by git pull (Please do not do this).

Therefore, every time I concatenated my previous commits on top of my latest rebase commits, and the commits were getting more and more.

Here is the correct way to do the git interactive rebase

In the global .gitconfig (under the mac home directory, hidden file), setup the following and it will help your interactive rebase. It will open the editor for you to edit in the VS Code

[core]
editor = code — wait # default editor will be VS Code
[rebase]
instructionFormat = %s [%an] # add the commit author to the end of each line

If you didn’t install code, go to VS Code, CMD + SHIFT + P and search install, and select the option Shell Command: Install 'code' command in PATH

Steps

  • go to your feature branch
  • git fetch
  • git rebase -i origin/develop
  • it will open the editor and remove all commits that are NOT yours
  • then close the editor
  • if there are conflicts, fix it manually, save and commit it
  • git rebase — continue
  • #important, don’t do any git pull to merge from remote
  • git push — force-with-lease (overwrite the remote even there is divergent)
- git fetch
- git rebase -i origin/develop
- git rebase --continue
- git push --force-with-lease

You can review the commits history after

git log — oneline — decorate — graph

Ideally, all of your commits should be in a row after origin/develop

Extra steps (squash and edit commit message)

You can squash all your commits into one commit and then give it a meaning commit message, and then create a pull request

You can squash all your commits into one during the interactive rebase by changing all pick to either f or s except the first commit, and close the editor. Then all the commits will squash to the first commit.

f will keep the change but get rid of the commit message

s will squash the message into the message above

If you forgot to do it during your rebase against develop, you can try to rebase against you feature branch with this command (a tricky way)

git rebase -i HEAD~10(10 will be the number of your last commits in a row)

This is a tricky command because it won’t work if there are other commits in between, so only use it when you see all your commits are in a row.

Then it will open a editor again and allow you to change the latter commits to fors

After that, your amend your commit message by this command

git commit --amend

It will open an editor and allow you to edit your commit message.

I will structure my commit message like this.

T10–1234: rebase testing (Main message)
- test rebase (detail message)
- squash commit
- amend commit

I hope that it will help some developers who were struggling with using git interactive rebase like me before. Once you understand how it works, it will definitely help you a lot in your life.

Reference

--

--