Docker multiple environments

Docker Compose will read docker-compose.yml and docker-compose.override.yml by default. Understanding-Multiple-Compose-Files

You can set a default docker-compose.yml and different overwrite compose file. For example, docker-compose.prod.yml docker-compose.test.yml. Keep them in the same place.

Then create a symbolic link named docker-compose.override.yml for each env.
Track docker-compose.{env}.yml files and add docker-compose.override.yml to .gitignore.
In prod env: ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
In test env: ln -s ./docker-compose.test.yml ./docker-compose.override.yml
The project structure will then look like this:

project\
  - docker-compose.yml       # tracked
  - docker-compose.prod.yml  # tracked
  - docker-compose.test.yml  # tracked
  - docker-compose.override.yml # ignored & linked to override composefile for current env 
  - src/
  - ...

Then you have done. In each environment, you can use the compose-file with the same command docker-compose up

If you are not sure, use docker-compose config to check if it's been override properly.

You could take some clues from "Using Compose in production"

You’ll almost certainly want to make changes to your app configuration that are more appropriate to a live environment. These changes may include:

• Removing any volume bindings for application code, so that code stays inside the container and can’t be changed from outside
• Binding to different ports on the host
• Setting environment variables differently (e.g., to decrease the verbosity of logging, or to enable email sending)
• Specifying a restart policy (e.g., restart: always) to avoid downtime
• Adding extra services (e.g., a log aggregator)

The advice is then not quite similar to the example you mention:

For this reason, you’ll probably want to define an additional Compose file, say production.yml, which specifies production-appropriate configuration. This configuration file only needs to include the changes you’d like to make from the original Compose file.

docker-compose -f docker-compose.yml -f production.yml up -d

This overriding mechanism is better than trying to mix dev and prod logic in one compose file, with environment variable to try and select one.

Note: If you name your second dockerfile docker-compose.override.yml, a simple docker-compose up would read the overrides automatically.
But in your case, a name based on the environment is clearer.