I'd like to know what's your preferred way of merging branches and PRs/MRs.
Ask HN: Git Rebase and Merge or Squash and Merge?
1–7 of 7 posts
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#2I prefer to update my branch with rebase, and merge it with a squashed merge.
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#3A 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.
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#4Squash.
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.
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#5Squash. 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.
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#6A 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 c…
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.
Re: Ask HN: Git Rebase and Merge or Squash and Merge?
#7A 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 c…
In this scenario I prefer to do an interactive rebase (with -i flag) and drop all of the commits that were on branch A.
This is basically exactly the same as checking out a fresh branch from main and cherry picking the commits from branch B.