dotenv is *NOT* meant to be used this way...
Generally speaking, do *NOT* commit your environment configurations (other than local development) to source control, you do *NOT* want variance in your configuration files, this is a deployment issue.
What you should do, is add `.env` to your .gitignore file so it doesn't get committed. You may want to add a `.env.dev.env` to source control with typical local settings. The dev env file should have a comment that you should copy it to a plain `.env` file for local development. You should also consider having fallback options in your configuration module, that represents the dev or production defaults as much as reasonable. ONLY load `.env` not ENVIRONMENT.env
Advice, load the .env file before loading any other modules, do it all synchronously, or an async load of your modules after environment and configuration are loaded. I would advise searching upward at least 2-3 directories for the .env then change your working directory to where the .env file is... for a static (non-container) deployment, this allows you to setup your .env in a parent directory from your application, and relative paths should work properly.
For containerized (docker) deployments, you should set the environment as part of your start/deployment model. Kubernetes, Dokku and other orchestration environments have options for this, you shouldn't deploy a .env file inside a container, and generally it should be mostly for development and/or static deployments.
Aside: you may, if using CI/CD for static deployments, want to use a `.env.template.env` file for transformation as part of your deployment model.