The idea is that you have a core structure that is used in both local/dev environment and the prod environment, with just the override applying changes. For example, your local override might have the "build" configuration, whereas the dev environment or production environment docker-compose should not have that configuration (assuming you are pulling from a private registry). That single core docker-compose.yml can be copied to any environment it needs and it should just run the app, but if you really, really need to override something for a specific reason, it's not hard to do it without modifying the core docker-compose.yml.

Hi,

It's mentioned on video and briefly in the blog post. It's so you don't have to duplicate a bunch of services between 2 files while you slightly change a bit of configuring for those services depending on the environment you're in, or even running different containers all together (which is the problem the override file solves).

Probably so you don't have duplicate settings in docker-compose.prod.yml and docker-compose.dev.yml when the only difference is probably just 1 line specifying NODE_ENV etc.