How to Maintain a "Version For the Server" - With Only Config Files Changed, in Git

What is the right way to maintain a version for the server - with only config files changed, in Git?

You could keep versioned:

• two "value config files", with the right values for each environment
• a template config file, with value placeholder in it (for instance, @@PORT_NUMBER@@)
• a script able to generate the actual config file depending on the current environment
• a content filter driver which, on checkout, will trigger the script in order to generate the right config file.

Note: that supposes your template config file has a recognizable content (the filter doesn't have a name or path of the file). See "Git equivalent of subversion's $URL$ keyword expansion" for more on the limitation of git content filter driver).

How do you deal with configuration files in source control?

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.

Version control of a web server config files

If you use GIT then puitting the whole /usr/local/etc under version control is not pointless at all.

• you can only track a handfull of files if you so chose
• the working directory with all config files tracked is hardly bigger in size

Just install git, then go to /usr/local/etc and write git init. This will create the .git folder in your current location (basically making this folder a repository).

Then add the config files you want to track:
git add firewall/firewall_config.conf apache2/httpd.conf etc
and commit: git commit -m "Initial Configuration"

Your config files are now being tracked.

SCM for configuration statement versioning

If you want to do version control for files, git is a very popular way. For your detail requirement in git as below (if there has misunderstanding for your requirement, please correct):

Treat master branch as main branch, every time, after finish a sprint you can merge it to master branch, master branch is the last previous version, and the branch you are working on is the current, so you can use git merge to deal the conflict files with delta configuration.

Show as the below graph, when you start a new sprint, create dev1 branch (git checkout -b dev1) and make and commit changes for config files. Then merge dev1 into master branch (git checkout master and git merge dev1), you can solve the conflict files to keep delta changes, use git add . and git commit to finish the merge. The next sprint is similar.

      ______C_____                          dev1
     /            \
A---B--new commit--D---E--new commit--G--H  master
                       \             /
                         _____F_____        dev2

Note: when you create a new bench new master, the config files can’t cleaned automatically, you need to delete the files or use git rm * to delete all files.

New solution bases on your edit:

A---B---C                     master
         \
          D---E---F---G---H   dev

If you use cherry-pick, you need do 4 steps to make changes for E,F,G,H to master. Of cause it can work correctly, but there are also two ways to make it easier:

1. Rebase commit E,F,G,H to master branch for one command:

git rebase --onto master <commit id for D> dev

2. Because commitH has already contained changes for E,F and G, so you can only need to rebase/cherry-pick commitH to master branch. This will keep the master branch only contains the final edition for each sprint.

how to except files from be merged to other git branch?

Then perhaps you best bet would be to not even version the app.config

Exactly, but you can still generate it, with a content filter driver, using .gitattributes declaration.

What you would version is a template file, and a file with all possible values per environment (per branch).

^{(image from "Customizing Git - Git Attributes", from "Pro Git book")}

The generated actual file remains ignored (by the .gitignore): your actual working tree does not get "dirty".

The smudge script:

• detect the right branch
• selects the correct value file and generates the correct file based on the template the smudge script is applied on during a git checkout.

That way, you modify the config.<branch> value file as much as you want: the config file (not versioned) will be generated from those values.

And it won't have any merge issue.

---

Related Topics