Squash and rebase. Linear commit histories.

yohannparis · on July 13, 2023

I don't understand how this is a relevant alternative? We are doing squash in our team, but merge queue seems to solve another problem. Could you explain, I'm really curious?

masklinn · on July 13, 2023

It’s irrelevant, merge queues are orthogonal to the actual merge method.

jakub_g · on July 13, 2023

Not feasible if CI time > time diff between two merges (e.g. CI time is 15m but there's a PR merged every 5 min).

alkonaut · on July 13, 2023

No problem unless it’s common for say 1 in 100 PRs to conflict at any point in their changes. If (say) one in 3 have conflicts, then it’s an obvious problem. So number of PRs alone shouldn’t be the limiting factor.

masklinn · on July 13, 2023

Nah it's very much a problem then as well, because while not integrating a broken change is easy, fixing it once it's there can take a while as you try to disentangle what's what under pressure because at best other colleagues are hampered in their ability to work or worse use that as an opportunity to just merge their change in a hurry compounding the issue. If your integration branch is broken for half a day every week it gets old quick.

paulddraper · on July 13, 2023

Irrelevant.

Regardless of the merge strategy (merge vs rebase), you will face the same problem with high-volume development relative to CI times.

Merge vs rebase just affects how it appears in Git, not anything about breakage guarantees.