3 ms·
In my experience, there is almost always a simpler way to handle these cases that involves being able to put a file in gitignore. This is one of the big advanta
by MrJohz 3y ago
In my experience, there is almost always a simpler way to handle these cases that involves being able to put a file in gitignore. This is one of the big advantages of environment variables, for example - they can typically be stored in a .env file (with a .env.default file checked in for new developers to copy from), and loaded dynamically in different configuration systems.
If my local setup requires me to ignore changes in checked-in files, I usually find that I need to handle configuration more cleanly.
(I did work on a project that made use of git update-index - this was a terrible mistake and caused pain every time we needed to update the config file in the repository. Please never go down this route!)
- ljm 3y agodotenv and direnv are more than enough for this task, I think, but you can make it as complicated as you care to with similar tooling that pulls secrets/config from the cloud (Doppler, parameter store, etc.) Most places I've worked at have created tooling that more or less merges the two - sane defaults and non-sensitive values go into a `.env` file of some kind (.env, .env.development, whatever), and then a tool merges a subset of that config from a remote store which contains the stuff you don't want committed in the repo. Usually used for connecting to a remote dev or staging instance if you can't or don't want to run the entire stack locally.