Hey team, I was wondering why "Squash & Merge" is the recommended merge strategy over "rebase and merge". We're using the CI optimization and merge queue, so we're not actually merging anything really. We're trying to get to a situation where the commit message is helpful documentation of what happened and why (linked to Linear via footers and whatnot) following the conventional commit style so that it's easy to quickly parse and scan in the terminal or wherever; and the pull request description is information that's necessary for a reviewer. They're related, but not necessarily the same thing. With our current setup, all our lovely written commit messages are thrown away and the squashed commit lands in

main

with the PR description as the message. It includes all kinds of markdown, links to pictures, summaries from various AI bots doing reviews. It's terrible for scanning quickly via a

git log

. Any recommendation on how to achieve what we're going for? PR description for reviewers, commit message for description of the change? The Github "default" merge strategy achieves this I think, but because we're using the graphite merge queue and CI optimizations we can't use this 😞. Thanks in advance!

Not from the graphite team, but have been using graphite for a couple years now We started off rebase + merge everything, but the problem is that as you have a bigger team, it’s common for people to accidentally have multi-commit PRs instead of using

gt modify

. When you’re merging 10-30 PRs a day and each PR has 3-10 commits, the merge conflicts slowed every engineer down by at least an hour everyday. This was with PRs that are relatively small by post-AI standards (<2k LOC). We adapted by switching to squash + merge and just making our PR descriptions really high quality so that our commit history doesn’t get wiped.

Thanks for the input!

Squash is the recommended queue option; it lands one commit from the PR title and description. To keep your conventional commit messages and leave the PR body for reviewers, set the queue default to Rebase and merge as fast-forward still works with that, merge commits are what block it. If a branch already has extra commits, gt squash before submit keeps history readable. https://graphite.com/docs/get-started-merge-queue

Thanks, @Chris Bowie! 🙇