I don't know how applicable this would be to your use-case, but dealing with this sort of situation (project has local configuration which should not go into the git repo) is precisely the reason that Config::Onion exists. The master config file, let's call it config.yml, goes into git with a full, working configuration, aside from dummy/empty values for anything that's either sensitive information or so site-specific that having a global default doesn't make sense. Then, after you clone the repo, you create a config.local.yml which sits beside config.yml and any settings in the local config will override the settings in the master config. And don't forget to add *.local.* to .gitignore to ensure that these local settings never get accidentally committed to the project history.

Prior to this we tried to do the same sort of thing manually, by putting config.example.yml (which isn't actually looked at by the code) into git and then copying it to config.yml and customizing it, but this had problems with having to remember to check for changes in the example config and then propagate them into the live config.