Избегайте конфликтов слияния при слиянии мастера с отдельной веткой для каждого хоста

Question

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

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

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

Я заменит @EMAIL@ с моим правильным e-mail на машинных отделениях и зафиксировать его, но SURFRAW_google_results останется неизменным. Для например, на work ветке я буду иметь это:

export EMAIL="user@corp.com" 
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 

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

<<<<<<< a60114eea1c98d2354a07bd4fd0cdd63cba62e93 
export EMAIL="@EMAIL@" 
export SURFRAW_google_results=10 
======= 
export EMAIL="user@corp.com" 
export SURFRAW_google_results=1000 
>>>>>>> m 

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

Answer 1

Вместо изменения параллельных данных непосредственно между ветвями (что приводит к конфликту as illustrated in this answer), вы можете с учетом content filter driver, используя .gitattributes declaration.

^{(изображение из «Customizing Git - Git Attributes», от «Pro Git book»)}

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

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

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

Чтобы иметь размытие, действующее по-разному на каждую ветку, я бы рекомендовал вызвать скрипт, который начинается с поиска имени текущей ветви.
См. Пример в моем более раннем ответе «Best practice - Git + Build automation - Keeping configs separate».

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

OP упоминает, что для сценария размазать применять на проверку, удаление необходим индекс. Это верно, так как I explained here:

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

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

См. "git: re-checkout files after creating smudge filter".