I'm a squash and merge kind of troll, but I feel like I'm in a minority or should feel guilty or something. I mostly do it out of
- convenience
- the desire to have a simple commit history
I wonder if git has a solution for (2) that I'm not aware of. Ideally you could squash in the tip of the branch while maintaining the ref of the branch tip and all of its ancestor refs so that you could do something like git log --expand and it adds the squashed commits to the history where they might belong. Now that I think of it though, if the commits are squashed before merging that probably wouldn't work.
Okay, enough of thinking out loud. Change my mind maybe.
How do you prefer to merge PRs and why?
merge commit0.0%
squash and merge0.0%
rebase and merge100.0%
1 vote \ 9h left
Rebase and merge with merge commit. But that's also assuming the individual commits are worth saving. If they're a mess, then squashing them is better. But if they're interesting and useful to be separate, I like to keep them separate. But I also like the merge commit because it includes the PR in the commit chain, which I find helpful for tracing context as to which PR brought in certain commits.
Whichever one earns me more commits under contributor stats!
j/k
squash seems to be the cleanest when working in a decentralized manner. A lot of the commits on my branches are small changes like fixing linting errors. Do they really need to be kept in the history?
You should do another post about PR comment etiquette. That’s something else I see vary wildly