[throwbadubadu]

> Do people not merge master into their branch before pushing?

No, they rebase! (Sorry, couldn't resist, yeah the other half does this (!attention, opinion!) ugly cross merges that make the commit graph look like my cables under the desk...

> Merge queues are the only way to ensure that main does not break from conflicts that arise "in between" commits.

Not the only one (though you may argue this is a degenerated queue): use merge locks! Yeah, we really use git svn style, the locking is done via a chat channel. No, please don't laugh. Acquire the lock, merge develop or rebase, check everything again, release lock :D :D (No again: I am not suggesting this to anyone!! :D )

[zizee]

The point the GP was making is that if merging to main is frequent (bigger team) and build times are long (bigger projects), catching your branch up to master before merging can be hard, as master is moving ahead faster than you rebase+build.

[throwbadubadu]

Fully understood.. we also have a big team, a too slow CI, and much too many LOCs. The "merge lock" will ensure you catch up, you keep the lock as long as it takes (or until others get too annoyed and urge you to step back) - as long as you have it nothing comes between you and main at the point you claimed it.

[Thorentis]

That sounds like an awful dev loop.