Как поддерживать (в основном) параллельные ветви с небольшим отличием

Question

Сценарий: Я пытаюсь получить мои точечные Unix-файлы в git. Я должен работать между (по крайней мере) средой Cygwin и некоторыми стандартными дистрибутивами Linux (Ubuntu и opensuse), и у меня есть файлы / строки кода, которые относятся только к Cygwin. Поскольку я не хочу извлекать бесполезные файлы или иметь дело со множеством дел в моих точечных файлах, я создаю ветки для каждой из моих сред. Но большинство изменений, которые я делаю, являются общими для всех сред, поэтому почти каждый раз, когда я делаю коммит, мне нужно распространять это изменение на все мои ветви.

Так что в основном у меня есть несколько ветвей, которые почти идентичны, за исключением нескольких коммитов, и большинство коммитов мне нужно иметь во всех ветвях.

Вопрос: Каков рекомендуемый рабочий процесс git для этого, если таковой имеется? Или есть лучшая настройка (без использования нескольких ветвей?) Для моего сценария?

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

Answer 1

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

Мы храним шаблон указанных файлов конфигурации, плюс все конкретные значения для среды, а также скрипт, способный заменить переменные в файлах шаблона на правильное значение (обнаружение текущей платформы)

Таким образом, нам не нужно создавать ветку только для этих файлов.

---

Другой хороший способ управления файлами такого типа (с содержимым, определяемым платформой) - через драйвер фильтра атрибутов git (см. Также Книга Pro Git ).

Драйвер фильтра состоит из команды clean и команды smudge, каждую из которых можно не указывать.
После checkout, когда указана команда smudge, команда получает объект blob со стандартного ввода, а его стандартный вывод используется для обновления файла рабочего дерева.
Аналогично, команда clean используется для преобразования содержимого файла рабочего дерева при регистрации.

Таким образом, скрипт (управляемый с помощью Git), на который ссылается smudge, может заменить все переменные значениями, специфичными для платформы, в то время как скрипт clean восстановит свое содержимое в нетронутом конфигурационном файле.

Основная идея остается: избегайте создания ветвей только для такой параллельной эволюции.

Answer 2

Один из подходов состоит в том, чтобы сохранить ветвь для каждой среды, а также «основную» ветвь, которая является общей для всех сред. Всякий раз, когда вы вносите изменения в основную ветку и хотите перенести их в другую систему, выполните что-то вроде:

git pull
git checkout local
git rebase master

Это перезапишет текущие изменения в "local" (для данной конкретной среды) в соответствии с текущим состоянием "master".

Ручная вещь, на которую вам нужно обратить внимание, это то, где вы совершаете изменение, которое хотите внести. Если он является локальным для системы, передайте его в "локальную" ветвь этой системы, иначе передайте его в "master" и отправьте в общий репозиторий.

Конечно, перебазирование может привести к конфликтам, которые вы должны разрешить вручную. Также, если вы решите отправить локальные ветви в общий репозиторий, вам придется (а) выбрать уникальные имена для каждой среды и (б) иметь дело с толчками без ускоренной перемотки вперед после перебазировки. Обе эти проблемы разрешимы.

Answer 3

Хороший вопрос. Даже если вы сказали:

... Так как я не хочу извлекать ненужные файлы ...

Я бы хотел поместить элементы, относящиеся к платформе или варианту, в ту же ветку, что и основной код, но в отдельный каталог для этой платформы / варианта. Ключ заключается в том, чтобы выделить материал, специфичный для платформы, как можно меньшей области (т. Е. Избегать ifdef в основном коде).

например:.

/
+--common
+--linux
+--cygwin
+--windows
+--mac

Таким образом организуются различные кроссплатформенные проекты. Например. проверьте структуру исходного кода Python для поддержки нескольких платформ.

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