It looks like you can use git validation as a deployment method. Sometimes it works, sometimes it takes a little more. If you need a little more when creating artifacts in the repository.
The most obvious way to handle this is to have a script deploy that pulls and then removes the extra directories and files. This, unfortunately, leaves you with a partial repository that can confuse people, and it adds a special script that must remember that it will be used and updated.
Another way to handle this is to have a deployment branch. Make a branch, delete offensive files and directories, and then pull it out of this branch. Yes, you will have to merge the changes from your development branch into the deployment. You see it as a burden, but it is a defense. If you quickly create development opportunities and deploy them just as quickly, you might have a problem with the deployment cycle.
You need a step between development and deployment in which you can review and test your changes. If nothing else, this will prevent developer A from failing to make a bad change, and administrator B exacerbates the error by unknowingly pulling it into production. You also want to be able to move towards development and share your work with other developers without fear that it will be put into production.
You may be the only person involved in development and deployment right now, but you cannot be later. If nothing else, this will protect you from accidentally pushing an unsustainable change in development, and then exacerbate this error by pulling it into a deployment before you can think.