git: Always squash

Following up on a previous git post, where it’s always smarter to fork a repository.

This post, I talk about why you should always squash your commits when making a pull request.

• show your best work
• make rebasing easier

Show your Best Work

When you submitted essays for grading, did you include all of your notes, intermediate drafts, and doodles on the side?

If you did, what kind of reaction did you get? Did the grader ask for it? Did they prune through every step of your work?

If you did not submit rough drafts, why would you do that to your teammates when they have to review your work?

Yes, git is powerful enough that one can save every draft of their work. Does that mean you should submit every draft for your peers to review?

I say: No. Just show your best work to your peers. They will appreciate your effort and in turn, also work better to match your effort.

Pull Request Reviews??

What about when making changes in response to comments to a pull request?

Make the changes, keep everything as a single commit.

Show your best work!

Integration?

If you use a git workflow like skullcandy, if there are changes after the code is on an integration environment, just make sure the commit to the production branch is a single commit.

Rebase with Ease

When your work is a single commit, you can perform rebases against the main branches with a single round of conflict resolution than doing conflict resolution for every commit where the change overlaps.

Do yourself a favor and have a single commit to make rebasing easier. Deciding which code change to take can have unintended consequences later on if you chose poorly.

Conclusion

Squash your commits when submitting for review to show your peers your best work and to make rebasing easier whenever there’s a conflict.