Summary

This goal is to reorganize all of your scattered commits into more meaningful commits for easier code reviews. If there are too many layers of changes across too many files at once, it is harder to do a code review. If you can reorganize your chronologically created commits into topical commits, then the code review process is easier (and possibly less bugs slip through the code review process).

This overly-simplified example is not the only strategy for using git to do better code reviews. It is the way I do it, and it’s something to inspire others to consider how to make code reviews and git history easier/better.

This also pedagogically demonstrates the power of rebase in general.

This example assumes you know about interactive rebasing.

Assuming:

• you’re working on a feature branch off of master
• your feature has three main layers: front-end, back-end, DB
• you have made a lot of commits while working on a feature branch. Each commit touches multiple layers at once
• you want (in the end) only three commits in your branch
• one containing all front end changes
• one containing all back end changes
• one containing all DB changes

Strategy:

• we are going to change our chronological commits into “topical” commits.
• first, split all commits into multiple, smaller commits – each containing only one topic at a time (in our example, the topics are front end, back end, DB changes)
• Then reorder our topical commits together and ‘squash’ them into single topical commits

Example:

$ git log --oneline master..
975430b db adding works: db.sql logic.rb
3702650 trying to allow adding todo items: page.html logic.rb
43b075a first draft: page.html and db.sql
$ git rebase -i master

This will be shown in text editor: