Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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


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

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

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

http://git-scm.com/figures/18333fig0702-tn.png

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

Ответ 2

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

git pull
git checkout local
git rebase master

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

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

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

Ответ 3

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

... Так как я не хочу проверять бесполезные файлы...

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

например:.

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

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

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