Машинные настройки web.config и app.config в git

У нас есть несколько команд разработчиков в разных офисах, и им нужны разные значения для ряда параметров конфигурации в наших проектах web.configи app файлы .config.

Нам нравится сохранять эти конфигурационные файлы проверенными с разумным набором значений по умолчанию, чтобы, проверяя ветку trunk/master, у вас было что-то работающее без необходимости копаться в конфигурационных файлах.

Исторически мы использовали Subversion и, в частности, TortoiseSVN, и это обеспечивало простой способ управления локальными изменениями: мы просто добавляли эти файлы в автоматический игнор-при-фиксациисписок изменений TortoiseSVN. Это предотвращает случайную регистрацию этих файлов, так как вам нужно будет выбрать их специально, чтобы включить их в регистрацию (и вы можете убедиться, что вы регистрируете значительные изменения, а не шум локальной конфигурации). Основным недостатком этого подхода является то, что файлы конфигурации всегда выглядят «измененными», поэтому невозможно с первого взгляда узнать, есть ли у вас какие-либо локальные изменения.

Мы собираемся перейти на Git, и я пытаюсь найти наилучший подход.

Прежде всего, что уже есть в других ответах StackOverflow:

Вариант 1: Проверить файлы xxx.sample и .gitignore фактические файлы конфигурации : это рекомендуется, например, в этом ответе .Основная проблема, которую я вижу в этом, заключается в том, что изменения в файле конфигурации легко забываются в двух разных моментах: коммиттер может легко пропустить изменения, которые им нужно добавить в файл .sample, и потребители (esp . сервер непрерывной интеграции) могут легко пропустить изменения, которые им необходимо включить из файла .sampleв свой локальный файл конфигурации. Так что в принципе это не похоже на очень хорошее решение.

Вариант 2: наличие зарегистрированного файла xxx.defaults и файла конфигурации .gitignored xxx.local, который переопределяет любые заданные им настройки: предлагается, например, здесь. Проблема в том, что мы работаем со стандартными поставщиками конфигурации .Net — я действительно не хочу, чтобы мы реализовывали совершенно новую структуру загрузки настроек, когда Mirosoft уже сделал всю работу. Кто-нибудь знает способ получить app.config и web.config для ссылки на необязательные локальные файлы переопределения?

Вариант 3: Пусть разработчики сохранят локальные ветки, а затем пусть они всегда проверяют выборки или перебазированные ветки в master, чтобы всегда обходить/избегать нежелательных коммитов в своей локальной ветке: Это предлагается как возможный вариант. рабочий процесс здесь, и хотя я ценю его чистоту с точки зрения отслеживания изменений (все проверено), он вносит значительный объем требуемыхнакладных расходов на каждую отдельную регистрацию; это большая боль!

Вариант 4: Зарегистрировать файлы конфигурации, но пометить их --assume-untchanged: Предлагается в качестве возможного варианта здесь; насколько я могу судить, по духу он очень похож на список изменений ignore-on-commitв TortoiseSVN, за исключением того, что вы не видите эти «скрытые» измененные файлы в процессе фиксации; TortoiseGit, например, показывает файл с «измененным» наложением значка, но в диалоговом окне фиксации файл вообще не отображается. Это кажется немного пугающим, опять же очень легко забыть зафиксировать изменения.

Учитывая эти параметры, а это все те, которые я нашел, я действительно надеюсь, что есть способ опционально «включить» локальный файл конфигурации. в зарегистрированный файл app.config/web.config и перейти к опции 2; Кто-нибудь знает способ сделать это или другие варианты, которые мне не хватает? (У меня есть слабое искушение рассмотреть пользовательский шаг перед сборкой слияния Xml...)

Я должен был упомянуть ранее, что мы все еще на VS2008, поэтому преобразования конфигурации недоступны.

ОБНОВЛЕНИЕ: (удалено, было просто неправильно)

ОБНОВЛЕНИЕ 2: Я удалил свое предыдущее обновление и ответ, это было глупо / не работало. Я не осознавал, что после «нашего» слияния следующее слияние в другом направлении возвращает «исходные» версии этих файлов (перезаписывает изменения локальной ветки); посмотрите историю редактирования, если вам интересно. Этот вопрос открыт как никогда.