Git („source code version control system“), SCRUM („(self-)organisation of development teams and their member roles“), agile development…
All those thing are just tools to get your software engineering job done.
But the essential - and price-winning - question of the OP remains: „How do you master the complexity of a complex topic like flight simulation, weather simulation, graphics/effects, AI traffic, multiplayer, development SDK, … - and make all this stuff - and in the end the teams & people - work together?“
And the answer to that is at least 2000 years old and so was already known to the Romans (*):
„DIVIDE ET IMPERA!“ - „Divide & Conquer“.
Applied to software engineering this means that you cut the problem at hand into finer-granular pieces - e.g. „weather“, „aircraft“, „airports“, „grapics“ - and rinse and repeat („clouds“, „rain“, „online weather“, „cockpit“, „ILS“, …), until each problem description can be explained and understood by a single person (that doesn‘t necessarily have to be a software engineer herself, but rather a „subject matter expert“).
Once such a „work item“ is understood (understandable) by a team and an „overall architecture“ has been laid out (which - most importantly - also defines the „hierarchy“ of those „items“ and how they interact with each other) those items are then essentially translated into a technical specification - or „code“ in the end.
Another important principle is „keep it as simple as possible, but not simpler“. But this principle is most often forgotten in software engineering and shall be a topic for another time
(*) As I had later learned after my studies „divide & impera“ actually meant - historically - that the Romans tried to split their enemies (mostly in the north) into smaller territories, in the hope to accelerate/spread rivalries among those people, such that they would be busy fighting each other instead of trying a „collective uprise“ against the Romans themselves.