Docker .gitignore template

The first three rules work together. docker-compose*.yml ignores every compose file, then two negations bring back docker-compose.yml and docker-compose.override.yml. The intent is that the base file is shared, the override file is where local adjustments go, and any other variant is somebody's personal experiment.

That intent does not match how most projects use compose today. Environment specific files such as docker-compose.prod.yml or docker-compose.ci.yml are usually deliberate, tracked, and referenced from a deploy script. Under this template they are silently ignored, and the failure appears when a colleague clones and the deploy command cannot find the file it expects.

The naming convention has also moved. The current tooling looks for compose.yaml by default, and neither the ignore rule nor its negations mention that name, so a project using it is unaffected by all three rules in either direction. If you have renamed your files to the newer convention, the whole block is doing nothing, and you should replace it with rules that match what you actually have.

.dockerignore is the rule that surprises people most. That file controls what gets sent to the daemon as build context, and excluding a large directory from it is often the difference between a fast build and one that uploads a gigabyte of dependencies. It is project configuration in the same sense a Dockerfile is, and almost every project should track it.

*.log is the last rule and the least controversial, covering container and application logs that end up in the working directory during local runs. What the template does not cover is a .env file, which compose reads by default for variable substitution and which routinely holds database passwords.