4 ms·
Squash and rebase. Linear commit histories.
by John23832 3y ago
Squash and rebase. Linear commit histories.
- yohannparis 3y agoI 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 3y agoIt’s irrelevant, merge queues are orthogonal to the actual merge method.
- jakub_g 3y agoNot 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 3y agoNo 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 3y agoNah 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 3y agoIrrelevant. 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.