Merge or squash
I've wondered for the longest time, "should I squash my PRs or make a merge commit?"
My old thinking was "who needs all of the tiny commits from a PR?". That nice linear history looks great.
But then I started really working on atomic commits, small, logical chunks of work in a single commit instead of mammoth commits with a huge range of changes included. And then I changed my mind.
If you make small commits, write descriptive commit messages, and want to use git as a real historical log of how a codebase changes with all of the knowledge sharing that comes with it, merge commits are you friend.
If you write bad messages, want a really clean history, and just want to focus on larger chunks of work, then squashing is for you.
Merge commits are also easier to revert (the smaller chunks especially) and search later.
Squashing on the other hand rewrites history and replaces all of your smaller commits with 1 single commit. You can search inside those squashed commits with some git reflog magic, but that takes time and gets pretty complex.
I also used to think "but now my production branch is messy with all these smaller commits". Seriously, who cares. You have the history, you can see the changes, and when was the last time you ran git log over the production branch? You have the version control you need on your staging/dev branch, and I'm of the opinion that your staging and production branches should be as identical as possible. That's where feature branches and release management come into the picture. That's a story for another day.
How can I write good commit messages?
- Make small, logical commits
- Follow the Conventional Commits guidelines for writing commit messages
- Explain what you did in your commit and why, as well as any background info on the issue/change
- Take the extra few seconds it takes to follow steps and 1 & 2 for a few weeks, and make it work with your dev workflow.
What about rebasing?
Not for PRs, please. But yes for merging staging into your feature branch, and yes for rewriting your feature branch history if you need to edit/drop/squash/whatever your commits.
How can I cleanup my branch history before opening a PR?
Kick off an interactive rebase with:
git rebase -i $(git merge-base HEAD staging) (if staging is the branch you will be merging into)
And then follow the prompts to walk through your history and cleanup any mess you might have left behind.