Ask HN: Git Rebase and Merge or Squash and Merge?

7 pointsfloriangosse11mo ago6 comments

I'd like to know what's your preferred way of merging branches and PRs/MRs.

6 comments

I prefer to update my branch with rebase, and merge it with a squashed merge.

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.

lostdog11mo ago

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.

kcrwfrd_11mo ago

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.

ecesena11mo ago

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.

skydhash11mo ago

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.

j / k navigate · click thread line to collapse

6 comments

kcrwfrd_11mo ago

I prefer to update my branch with rebase, and merge it with a squashed merge.

jeremy_k11mo ago

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.

lostdog11mo ago

It takes some git gymnastics to transplant the merge back onto main cleanly.

kcrwfrd_11mo ago

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.

ecesena11mo ago

skydhash11mo ago

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.

j / k navigate · click thread line to collapse