问题
We are using dotCloud, a virtual host, to run some of our apps. dotCloud deploys apps directly from a git repo, and reads a configuration file called dotcloud.yml from that repo to configure and run the stack.
We have two branches (one production, one staging) that are part of the same repo, and these push to separate dotCloud instances. There is a minor difference in the dotcloud.yml file to run each of these instances.
What is the best way to manage this dotcloud.yml file? Currently we simply make sure we're making sure the dotcloud.yml is correct on each branch, but it constantly gets overwritten as we merge changes from staging to master.
回答1:
You could:
- version a
dotcloud.yml.template
- version a
dotcloud.yml.value.prod
and adotcloud.yml.value.staging
with the pertinent values for each environment. - version a smudge script in charge of building the right
dotcloud.ym
l file (which wouldn't be versioned anymore) depending on dotCloud instance.
You would declare that smudge script as a filter content driver in a (also versioned) .gitattribute file:

On any git checkout, the smudge script will be called and, if it recognized the dotcloud.yml.template
content, will build the right dotcloud.yml
file.
回答2:
You could:
- add
dotcloud.yml
to.gitignore
, have two separate files for staging and production (e.g.dotcloud.yml.staging
anddotcloud.yml.production
), both present in your git repository, setup a symlinkdotcloud.yml → dotcloud.yml.production
, and push withdotcloud push --rsync
(the--rsync
flag will override the push mechanism detection, and the rsync mechanism will kick in, instead of the git mechanism); - use the same
dotcloud.yml
file, but rely on a different mechanism (e.g.dotcloud var
or apostinstall
script) to switch between the production and staging behaviors.
来源:https://stackoverflow.com/questions/10426954/different-versions-of-the-same-configuration-file-in-different-branches