Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by sopooneo | Hacker News Reader

Parent Full thread

sopooneo·

Sincere question: does a “squash merge” implicitly include a rebase as well when the merge target has diverged?

View on HN

It's equivalent to rebasing, and squashing into a single commit.

It's also equivalent to a merge commit, and then only keeping the diff from the merging in branch.

So it's sort of a half way house, and sort of the worse of the both worlds.

Yes it has it up and downs. But it also helps me and my team to enforce smaller patches since they land as one anyways. And other teams in my company follow the open PR and develop the next 2 weeks on it and merge in full. There is so much garbage in all these commits no one ever wants to get back to. Good luck bisecting on of these histories.

How independent are those commits? If I'm developing a feature that has distinct but dependent changes, then the rebased/squash pattern doesn't work as well. Submitting in a single PR means that those distinct changes all get squashed away. Submitting in a series of PRs keeps the history, but means that the have commits on main have different ids, and so I need to keep using `git rebase -i` to remove the corresponding commit from my dev branch whenever one gets merged in.

GitHub is pretty smart nowadays. If you propose a series of PR on top of each other, GitHub will change the base when it the base of the second PR got merged and so on. There is sometimes the need to rebase but I have generally no problem with it. Mind that I don’t propose this workflow with teams that also have non tech members like artists because these Workflows bring too much friction. But I keep my changes as independent as possible. All running with tests to cover the added/changed code.

It means using `git merge --squash` which performs a normal merge but then instead of adding a merge commit, it just makes a single regular commit with the changes.

Reply on news.ycombinator.com