TL/DR If you want your pull requests to be taken seriously you probably need to learn some more advanced git features like interactive rebase and squash.

First I wanted to share an article I found when helping folks that struggle with code review/pull request comments like “Can you rebase that” or “I don’t want to see all your workings – please squash your commits”.

If that applies to you, I suggest you have a read of Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History.

You can also find more detailed information in the excellent git book, Ch7.6 Rewriting history and Ch3 - Rebasing.

Why are rebase and squash useful?

Because you really should present your code in such a way that it was easy to review if you want a swift and successful review.

If your review has more than 5 or 6 commits then

  • Either you have included lots of junk commits like “Teamcity build fix #7” and you should squash those commits and hide them, reviewers don’t care to see those.
  • Or the feature might be too big to easily review. Would an in-person code walkthrough be better?

If your commits have rubbish commit titles like “file update”

  • Use interactive rebase to change the commit message. The commits should explain the implementation of the feature to the reviewer, not detail the life story of your dev process.
  • Use interactive rebase to reorder or squash the commits so they make more sense

Have you actually ever tried to review your own code? Do you think it is really ready and ‘Easy to review’?

  • Try and create the pull request but assign it to yourself. Have a look – could you review that? When you think it is really ready for review, edit the request and assign it to the reviewer.

And lastly make sure your code is up to date before sending for review

  • Rebase your feature branch above master/latest release branch regularly – probably daily is best
  • If you cannot rebase because of conflict ensure you have merged master (or the release branch) into your branch before you request a merge back into master so it is clear it it current and will merge back cleanly.

Hope that helps you craft a lovely pull requests.

git rebase –interactive - made it look like I wrote those unit tests before the code