Suppose I create some widget, and decide to share it with Github. In this widget project, there's some configuration/preferences file. I need to share what the values being set are, so that if anyone else wished their own widget they'd know what to set. But I don't necessarily want or need to share my own settings.
This would be a case in which some/all of the settings have no concept of a 'default' - they all need to be explicitly set by the programmer.
I thought I was going to find an answer in this question, but really that (or at least it's answers) are more focussed on keeping things secret. I don't need to share in confidence - I just don't need to share.
In essence, I need to deploy
Foo := 'Bar', but commit/push/share
What's the best way of handling this in Git?
Some possible solutions:
- Commit the unpopulated file; don't include in later commits with preferences set. Disadvantage: if I add a new setting later, need to remove all values to commit it, and then set them again.
- Set the values by import/inclusion (as applicable for the language) to ensure an upfront (and less confusing than it might otherwise be) error; clearly state requirements in a readme. Disadvantage: noone likes errors.
- Branches? I've never really had the need to use multiple, but I have a feeling the 'right' way to do this might be an un-pushed 'deploy' branch with the values set, and unset in the pushed 'master' branch; just deal with the merge conflicts as they arise on adding new properties? Maybe? Same disadvantage as (1) really, but maybe it's the better practice?