How Do You Deal With Configuration Files In Source Control?
Let's say you have a typical web app and with a file configuration.whatever. Every developer working on the project will have one version for their dev boxes, there will be a dev, prod and stage versions. How do you deal with this in source control? Not check in this file at all, check it with different names or do something fancy altogether?
What I've done in the past is to have a default config file which is checked in to source control. Then, each developer has their own override config file which is excluded from source control. The app first loads the default, and then if the override file is present, loads that and uses any settings from the override in preference to the default file.
In general, the smaller the override file the better, but it can always contain more settings for a developer with a very non-standard environment.
- → Commits from different branch on GitHub Pull Request
- → Split SVN repository into several Git repositories
- → File Specific Report generator
- → How to skip first N commits when converting svn repo to Git using reposurgeon?
- → Does Go development require a paid Github account for private development?
- → Git still showing end of line characters
- → Are git and svn different tools with the same purpose or are they different tools for different tasks?
- → Svn to Git of only one subdirectory
- → Incorporate existing project into existing git repo
- → SVN-Git migration: clean-git branch error
- → Why does git-svn make branches with names like [email protected]
- → How can multiple web devs use git to work on one page simultaneously?
- → Getting Subclipse in Aptana to work with the newest release of Subversion