So right now we are using Git as our version control. We also use docker compose to manage the deployment
I want to handle the fact that we have some customers that want their own version of the site with slight docker-compose.yml differences (such as an environment variable defined by docker). This causes the git pull to worry about the uncommitted changes in the docker-compose.yml file.
I'm thinking that I can open a branch from master and then pull changes from master as time goes on so that we don't need to worry about the changes for config specific files.
Of course I can be completely missing something and there exists an easy solution to all this.
The standard git way is creating a branch and keeping it updated frequently from master. This is a very common approach.
In fact most open source projects use a very similar technique whereby a fork is taken from the main repository and custom changes by a contributer are done on the forked repository.
As a small remark, it is better to maintain the environment variable in a env_file since env values will likely be different from the client. That way you would have less manual merges in the docker-compose file.
Update
Another idea that might be worth evaluating, is git submodules. Basically, you can put the stuff that need to be different into a git submodule, and keep the parent module the same between your repo and the client's repo. That way the client points to his own submodule and there is no need to maintainer separate branches.