Use symbolic links.
Take an example where you have a config file named "config.ini". In the working directory of your git repo, you would do the following:
Create a version of the config file called "config-sample.ini". This is the file you'll do all your work on.
Create a symbolic link between "config.ini" and "config-sample.ini".
ln -s config-sample.ini config.ini
This let's all your code point to "config.ini" even though you're really maintaining "config-sample.ini".
Update your .gitignore to prevent the "config.ini" from being stored. That is, add a "config.ini" line:
echo "config.ini" >> .gitignore
(Optional, but highly recommended) Create a .gitattributes file with the line "config.ini export-ignore".
echo "config.ini export-ignore" >> .gitattributes
Do some coding and deploy....
After deploying your code to production, copy the "config-sample.ini" file over to "config.ini". You'll need to make any adjustments necessary to setup for production. You'll only need to do this the first time you deploy and any time you change the structure of your config file.
A few benefits of this:
The structure of your config file is maintained in the repo.
Reasonable defaults can be maintained for any config options that are the same between dev and production.
Your "config-sample.ini" will update whenever you push a new version to production. This makes it a lot easier to spot any changes you need to make in your "config.ini" file.
You will never overwrite the production version of "config.ini". (The optional step 4 with the .gitattributes file adds an extra guarantee that you'll never export your "config.ini" file even if you accidentally add it to the repo.)
(This works great for me on Mac and Linux. I'm guessing there is a corresponding solution possible on Windows, but someone else will have to comment on that.)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…