We should be able to agree that not storing secrets in your repo dodges all these problems nicely.
If anything, I like the git repo idea b/c — presuming that the repository stores a history of who had access to what, when — it removes the question of whether you need to rotate a secret. You can look at the history, and if the secret didn't get rotated when access was removed or at some time afterwards, you know you're not secure.
Compare that to say, a random file somewhere, say on a deployment node in deployment code, or alongside that code so as to keep it out of a repo, that just keeps the latest copy of the secrets, where one doesn't know when access was revoked. Do the keys need rotation?
They'll have their own key, which will be revoked from the store, and they might have a single key that machines use to access the store. You should be rotating that machine key all the time anyway, so rotating once more when a dev leaves isn't a big deal. It's also much easier than rotating all of your actual keys, which in many cases is generated by a third party that may make such a thing very hard.
Obviously, nothing you do w/r/t secret storage is going to resolve the problem of what's in your employees' heads.