Currently, the parse-server GitHub account is configured to not allow merge commits into master.
This means that if there is a pull request with dozens of commits, the commits will be squashed into a single commit.
On my own stuff, I don’t do this. I commit very frequently with a message for each thing I do. When I want what’s in master I create a merge commit instead of rebasing.
When I merge into master I do not squash.
I like this because:
If I am searching for how something is done by grepping the commit history, and I get a hit, it’ll generally be a small commit for just what or nearly just what I am looking for instead of a large commit with lots of mostly unrelated changes.
If I am trying to locate a regression I can use the amazingly awesome
git bisectto pin down the change, if I have small discreet commits, it is easier to locate.
I can keep track of my local branches more easily using:
git-clean='git branch --merged | egrep -v "(^\*|master|dev)" | xargs git branch -d'
this to me is a big advantage. I still manage my local branches, but it is more labor-intensive and accident-prone.
- it’s mind-numbingly easy and easy to reason about. For example, what even happens when you squash when there are commits from multiple authors in a pr. I know it is handled but I have no idea how.
What are the counter-arguments?
One that I can recall is that it makes it easier to read history cause PR’s are clumped together. Maybe, but I have never looked at history that way for that purpose…maybe others do?