Table of Contents
This is a temporary holding space for common dev questions. Once we have a more fleshed out developer guide, we can move these there.
Why merge rather than squash and rebase PRs?
Answer is from https://discord.com/channels/1005603569187160125/1005603569711452192/threads/1157086915028340978.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context.
I prefer merge and creating a merge commit because I think it best represents true history. You can see the merge point, you can see all the WIP commits the developer went through. You can revert the whole merge easily (git revert -mN ).
I also believe having more commits makes git bisect better, as long as every commit builds. This strategy depends on good hygiene by the developer keeping every commit building. I follow this rule 99% of the time (I make mistakes, but I try very hard not to).
I hate hate hate when I bisect a project only to land on a single squashed commit from a single PR that is like +2000/-500. That is... not helpful at all. I want to bisect and land on a commit thats at worst like +500/-500. At worst. Ideally I land on a commit thats more like +50/-50. Then I can say "ah hah,the bug is there." Squashing destroys this information. I'll take a merge with 1000 +50/-50 commits over 1 squash every. single. day. (Assumption: each commit is buildable and makes sense as some atomic piece of work)
I do squash though when a PR has a bajillion tiny "WIP" "WIP" "WIP" commits but is really aiming towards one goal with a relatively small diff. That's my squash use case.
If you have a big diff AND a lot of "WIP", then I rebase (interactively), and selectively squash and reorder commits where it makes sense. I tend to expect developers to do this and care about their commit hygiene, but unfortunately a lot of developers aren't that comfortable with Git. In the OSS world, I do it for them. When I was an engineering manager back in the day, I'd expect engineers I worked with to have this knowledge.