Предотвращение конфликтов слияния при объединении мастера в настраиваемую ветвь для каждого узла

Question

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

У меня будет один master ветвь, которая содержит только определения и определения шаблонов, которые должны быть общими для всех ветвей, например:

export EMAIL="@EMAIL@"
export SURFRAW_google_results=1000

Я заменю @EMAIL@ с моей правильной электронной почтой на ветках машины и зафиксировать ее, но SURFRAW_google_results останется прежним. Например, на work Ветка у меня будет такая:

export EMAIL="[e-mail]"
export SURFRAW_google_results=1000

Теперь я решил изменить SURFRAW_google_results=1000 до 10. Это должно быть распространено глобально, поэтому я сначала меняю его на master:

export EMAIL="@EMAIL@"
export SURFRAW_google_results=10

а потом я перебазировать work на master:

$ git checkout work
$ git rebase master

И теперь я получаю конфликт, потому что линия, которая выше линии, которую я изменил, отличается:

<<<<<<< a60114eea1c98d2354a07bd4fd0cdd63cba62e93
export EMAIL="@EMAIL@"
export SURFRAW_google_results=10
=======
export EMAIL="[e-mail]"
export SURFRAW_google_results=1000
>>>>>>> m

В случае bash Я мог бы быстро обойтись включением машинно-специфической детали с помощью механизма поиска, но как насчет конфигураций, которые не поддерживают включение / поиск других конфигураций, таких как .fluxbox/keys или же .screenrc?

Answer 1

Вместо того, чтобы изменять одновременные данные непосредственно между ветвями (что приводит к конфликту, как показано в этом ответе), вы можете рассмотреть драйвер фильтра содержимого, используя объявление.gitattributes.

^{(изображение из " Настройка Git - атрибутов Git", из " Книги Pro Git")}

Идея состоит в том, чтобы управлять этими точечными файлами в версии, но с шаблонными заполнителями вместо фактических значений (которые зависят от ветви).
Сгенерированные фактические точечные файлы остаются игнорируемыми (.gitignore).
Это означает, что ваше фактическое рабочее дерево не становится "грязным".

Файлы с фактическими значениями также могут быть версионными, но с разными именами (поэтому нет конфликтов при слиянии / перебазировании)

Сценарий smudge выбирает правильный файл значений в зависимости от имени ветви и генерирует правильный файл точек на основе шаблона dotfile, к которому применяется сценарий пятна во время git checkout,

Чтобы пятно действовало по-разному для каждой ветви, я бы порекомендовал вызвать скрипт, который начинается с просмотра названия текущей ветви.
См. Пример в моем предыдущем ответе " Лучшая практика - Git + Build Automation - Хранение конфигов отдельно".

#!/bin/sh
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)

В user1042840 упоминается, что для применения сценария smudge при извлечении необходимо удалить индекс. Это правда, как я объяснил здесь:

Индекс является посредником для перемещения вещей из вашего рабочего дерева в хранилище объектов И для перемещения вещей из хранилища объектов в ваше рабочее дерево.

Удаляя индекс, вы заставляете git его восстанавливать, что означает применение любого драйвера фильтра содержимого, если таковой имеется.

Смотрите " git: повторная проверка файлов после создания фильтра пятен".