> I’m curious how people would suggest dealing with large self-contained features that can’t be merged to main until they are production-ready

Are you hiding them from CIA or Al-Qaeda?

Feature toggles, or just plain Boolean flag are not rocket science.

Not rocket science, but I think there are also some tradeoffs with feature flags?

People could build on top of half-baked stuff because it’s in main. Or you might interact with main in ways that aren’t ready for production and aren’t trivial to toggle… or you just forget a flag check somewhere important.

I could also see schema/type decisions getting locked in too early while the feature is still in flux, and then people don’t want to change after it’s already reviewed since it seems like thrashing.

But yeah, definitely it’s one option. How do you consider those tradeoffs?

The way we do it where I work (large company in the cloud/cybersecurity/cdn space):

- Chains of manageable, self-contained PRs each implementing a limited scope of functionality. “Manageable” in this context means at most a handful of commits, and probably no more than a few hundred lines of code (probably less than a hundred tbh).

- The main branch holds the latest version of the code, but that doesn’t mean it’s deployed to production as-is. Releases are regularly cut from stable points of this branch.

- The full “product” or feature is disabled by a false-by-default flag until it’s ready for production.

- Enablement in production is performed in small batches, rolling back to disabled if anything breaks.

They come from people who have established that their work is worth the time to review and that they'll have put it together competently.

If it's a newcomer to the project, a large self contained review is more likely to contain malware than benefits. View with suspicion.

The partial implementation could be turned off with a feature flag until it's complete.

you line up 10-20 PRs and merge them in a temporary integration branch that gets tested/demoed. The PRs still have to be reviewed/accepted and merged into main separately. You can say 'the purpose of this pr is to do x for blah, see top level ticket'. often there will be more than one ticket based on how self-contained the PRs are.

In our case, if such a thing happens (a few times per year across hundreds of people), a separate branch is created and a team working on that feature is completely autonomous for a while, while there is constant normal work in trunk by everyone else. Team tests their feature and adjacent code to an acceptable beta state but doesn't do any extensive or full coverage because it is impossible. Their code may be reviewed at that point if they request it, but it done as an extra activity, with meetings and stuff. Then they optionally give this build to the general QA to run full suite on it. This may be done in several cycles if fatal issues are found. Then they announce that they will do merge into trunk on days A to B and ask everyone to please hold off on committing into trunk in that time. Around that time they send a mail outlining changes and new functionality and potential or actual unfixed issues. QA teams runs as full cover of tests as possible. Merge may be reverted at this point if it is truly bad. Or if it good, team announces success and proceeds with normal work mode.

I will schedule review time with coworkers I trust to go over it with them.

It is about ownership to me. I own my PRs. If I throw garbage out and expect you to fix it I am making you own my PRs. No one wants to be forced to own other peoples work.