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.
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.
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.
I prefer to update my branch with rebase, and merge it with a squashed merge.
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.