Instead of excluding non-public directories, I like to make an explicit `public` directory (or `doc`, `doc-root`, whatever you want to call it). Then configure your server to point to that subdirectory and don’t worry about the repo.
I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for painless deployment.
Since the web root is already a sub directory, more sensitive things can go into the same repo without worrying about exposing them.
A path traversal is different from putting private files in a public directory. For a simple static site there will always be certs, /etc, and other things outside of the document root that shouldn’t be served.
I expose the .git directories on my web server and never considered it a problem. I also expose them on GitHub and didn't consider that a problem either...
Super common failure is accidental commit of a secret key. People suck at actually deleting something from git history. Had one colleague leak a Digital Ocean key this way with an accidental env file commit. He reverted, but the key is of course still present in the project history.
The speed at which an accidentally committed and reverted key is compromised and used to say launch a fleet of stolen VPSes on a github public repo nowadays is incredible. Fortunately most of the time your provider will cancel the charges...
This has always been the roughest part of git for me, the process to remove accidentally committed sensitive content. Sure we should all strive not to commit stupid things in the first place, and of course we have tools like gitignore, but we are all only human.
"Sensitive data can be removed from the history of a repository if you can carefully coordinate with everyone who has cloned it and you are willing to manage the side effects."
I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.