A problem I just ran into with this is that squash and merge obviously loses all the history of the merged branch. If you branched off that branch, when attempting to rebase main, there are a lot of conflicts because all that history is gone. A co-worker suggested cherry-picking commits from the second branch off a clean main as an approach to not dealing with all the conflicts.
Example:
main -> Branch A -> Lots of commits on A -> Branch B -> Lots of commits on B
Now we squash and merge A into main. B now has all of A's commit history, plus some of its own, instead of just it's own. Rebasing main in causes a lot of conflicts.
IMO the best is to merge main into your branch. Then squash the result into a single change and rebase onto main. This way you can merge in a "normal" way, removing the conflicts with main, but then your own change goes in cleanly on top of main.
It takes some git gymnastics to transplant the merge back onto main cleanly.
Squash.
PR is a github thing, not a git thing (and it’s good imo).
In a PR you have description, history, and you accumulate commits as you get review(s).
When a PR is ready, all you need is a single commit to main, because the PR itself has the rest of the historic documentation.
This. PR is just one of many methodologies with Git and has its own pros and cons. But as you said, the history is no longer so important as you have the PR reference (and can export the data). So squash it is.
But for true decentralized developments, when the developer is not really part of the same organigram, I'd prefer the remote branch to be cleaned up with clear commits. in this case, I will merge.
Example: main -> Branch A -> Lots of commits on A -> Branch B -> Lots of commits on B
Now we squash and merge A into main. B now has all of A's commit history, plus some of its own, instead of just it's own. Rebasing main in causes a lot of conflicts.
It takes some git gymnastics to transplant the merge back onto main cleanly.
But for true decentralized developments, when the developer is not really part of the same organigram, I'd prefer the remote branch to be cleaned up with clear commits. in this case, I will merge.