>>20499
I'm not sure what CGI scripts are, but I think best practice is the former, every company I've worked for did it that way.
Having your docker container have to manage the underlying software and changes will get annoying quick. It's way easier to do as you say, keep the Dockerfile with instructions to build the software inside your git repo. This allows you to manage each separately. Git manages the actual code changes, and the Dockerfile is used to manage (by way of versioned images) the software that you're actually running.
For example, I work with Go alot, so most of my services follow this format. The repo contains the actual Go code, and the Dockerfile contains instructions to build and run the executable. I can version my docker images, upload them to some container registry (dockerhub is free) and keep a history of images. If I make some change to the code that kills the software, I can simply run an older image until I fix whatever bug was introduced.
Doing this is the standard way so that your orchestration engines have an easier time with images. If you're not already using it, use docker-compose to orchestrate your containers. Kubernetes is overkill for personal projects, but the idea is the same. You'll come to understand why you want your docker container to just contain the actual software you want running, and why software management within a container would be too cumbersome to do.