You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge but also be responsible for your code. Take major refactoring as an example - don't create a patch which is partially implemented with breakage. You can ask for review but don't request a merge knowing it will break - actually your tests should tell you that. Finally, it is important to communicate changes regularly. Developers shouldn't be suprised to see their changes broken because someone else decised to refactor all the sudden.

Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology.

With that said, I've been doing this for over ten years and haven't come across that scenario. You can easily figure out all kinds of tricks to break things down, but usually only after you believe in the value of it.