We use git for most of the web applications we build in our shop, and though the applications themselves use a variety of technologies (PHP, Rails, etc), we generally have a sta
I assume that usually, master
only holds commits that are already in staging
. If you add an extra commit to master
which contains the differences in configuration between the two branches, then rebasing this commit on top of whatever is pulled from staging
should maintain the configuration. This isn't quite as simple as "merging staging into master shouldn't affect master config files in any way", but as you'd get a merge conflict in these cases, it may be close enough.
Not sure why people think they can get away without some sort of install tool. Git is about tracking source, not about deploying. You should still have a "make install"-type tool to go from your git repo to the actual deploy, and this tool might do various things like template expansion, or selection of alternate files.
For example, you might have "config.staging" and "config.production" checked in to git, and when you deploy to staging, the install tool selects "config.staging" to copy to "config". Or you might have a single "config.template" file, which will be templated to make "config" in the deploy.
You could try using the post-merge or post-checkout hooks to verify that all is as it should be, and fix it otherwise. This actually seems to be suggested by the ProGit book.
The concept is basically to write those hooks to act as mini "make install" scripts that ensure the correct configuration by branch, by host, by the presence or contents of other files, by whatever you like. The hooks could even rewrite your config files or recreate them by filling in templates.
Try out https://microconfig.io
It is designed exactly for managing microservice configuration with multiple environments.
You can have your base configuration files and environment specific overrides. And then use it to generate final results for specific env.