設定ファイルなどのバージョン管理について、デフォルト値が設定された基本となるファイルがある一方で、導入先ごとの、例えばホスト名などが少しずつ異なる版も多数（数十とか）管理したいという場合、どのようにするのがよいでしょうか。

考え方としてはブランチで良いと思いますが、使っている VCS だったり、その管理の単位によっていろいろとありそうな感じがします。

例えば、Subversion で、その「設定ファイルなど」の管理がソースなんかと一緒くたになってるとしたら、考えただけでちょっとげっそりします。

Git であれば、マージは楽ですが、導入先が多ければやはり手間は大きいですし、使っているスタイルにもよりますけど、どこからブランチを切るの、というポリシー的な解決は必要です。

ブランチを切るとしても、設定ファイルだけのプロジェクトにしておいた方が良さげな気がします。
＃ CVS だったら、気にしなくて良いけど

新しい設定項目が追加された場合は全部にもれなく反映される必要があります。

このような要求があるのであれば、VCS の外で解決すべきだと思います。

ぼくなら、設定ファイルなら、ふたつのファイルを重ね読みするような構造にします。

ひとつは、システムのよくある設定値（デフォルト値）を持った設定ファイル。
全ての設定項目を持ちます。

もうひとつは、導入先毎で変更した設定値を持った設定ファイル（差分）。
同じ項目名は、先のファイルに定義がありますが、こちらに設定した方が優先するように読み込みます。

バージョンアップなどで設定項目が増えた場合には、それを扱うプログラムのソースと、デフォルトを持った設定ファイルだけが更新されます。
その項目を変更する必要がある導入先だけ、差分のファイルに新しい項目の定義を追加してコミット。

Git なら、ソースと一緒くたで管理でも、問題ないと思います。
Subversion だったら、やっぱり差分のファイルは別プロジェクトでの管理で。



質問には「設定ファイルなど」ってありますね。
環境構築用のスクリプトとかに、IPアドレスとかホスト名が直に書き込まれているのでしょうか。

こいつらは、変更されるような値をスクリプトの外に出します。
そして、そのファイルは、先の設定ファイルと同じ扱いにします。