Git branches — rewriting history and avoiding nightmares (Part 2)

History is not written in stone: interactive rebase is your friend, learn to love it

Claudia Minardi
NEXT Engineering
3 min readJul 5, 2017

--

In Part 1 of this Git Branches story, we wanted to let you know how we have built a workflow around branches that makes them easy to use and lovable. Now, we’ll let you in in all of the secrets to interactive rebase that have made our life super easy.

1. Label your commits.

Make life easier for your future self by adding notes to your commits that will make interactive rebase short and painless. Here are the three kind of commits we usually have:

  • fixup: fix a typo, or something irrelevant in an earlier commit on the branch
  • squash: an important change which should be mentioned in the final commit messages, but whose code can be merged in another commit
  • regular commit, where change and commit message are self-standing.
    These labels will make it super easy to recognize what you need to do with each of these commits!
148e58d Add new button to home page
9eb7a3f Fixup: fix typo in button text
75449be Squash: add animation to the button

2. Birds of a feather flock together — so do commits

It’s easier to squash/fixup commits that involve the same file, so it’s a good idea to always start with those. They are less likely to create conflicts.

If you can’t remember all the commits that belong to the same file and don’t want to spend time looking it up, just use the labeling trick when you write the commit message:

148e58d index.js - Add new button to home page
9eb7a3f Fixup index.js: fix typo in button text

But remember: always remove the labels by editing the commit message before merging your branches into master!

3. Question your choices

If a commit involves multiple files, always stop and think if this should be a standalone change or if it goes side-by-side with something else. Also, are there any other fixups (typos, forgotten imports, renaming) that can be added to this commit?

4. Do it one by one

If you’re not sure whether an interactive rebase will create conflicts, always do it in multiple rounds (e.g. fixup one commit, complete rebase, check that everything is in order, then do git rebase -i origin/master again and repeat from the start).

5. Check the messages

Once you finish the interactive rebase, check the commit messages again. Do the commit messages still describe what the commit is doing? If not, change them — interactive rebase will help you do that as well.

148e58d Add new query to get user name
9eb7a3f Fixup: add also query to find user email

These two commits should not only be merged, but also renamed, by flagging the main commit with an edit tag during interactive rebase:

6698a1e Add queries to find details of the user profile

And that’s all for now! Use these to take your branches to the next level.

Happy coding!

Photo by: Ben Burton

--

--