Как поддержать (главным образом) параллельные ответвления только с некоторыми различие
Сценарий: я пытаюсь получить свои точечные файлы Unix при мерзавце. Я должен работать (по крайней мере), между cygwin средой и некоторыми стандартными дистрибутивами Linux (человечность и opensuse), и у меня есть файлы/строки кода, которые только характерны для, скажем, cygwin. Так как я не хочу к контролю бесполезные файлы или имею для контакта с большим количеством случаев в моем dotfiles, я создаю ответвления для каждой из моих сред. Но большинство редактирований, которые я делаю, характерно для всех сред, таким образом, почти каждый раз я сделал фиксацию, я должен распространить то изменение во всех своих ответвлениях.
Так в основном у меня есть несколько ответвлений, которые почти идентичны за исключением нескольких фиксаций и большинства фиксаций, которыми я действительно должен быть во всех ответвлениях.
Вопрос: каков рекомендуемый рабочий процесс мерзавца для этого, если существует кто-либо? Или есть ли лучшая установка (не используя несколько ответвлений?) для моего сценария?
[Я пытался избирательно подойти к выбору, но это включает довольно мало работы, и не говоря уже обо всех дублирующихся фиксациях здесь и кошмаре, который это должно сохранить моими ответвлениями в синхронизации.]
3 ответа
Один из подходов - чтобы сохранить ветвь для каждой среды, а также «главную» ветвь, общую для всех сред. Всякий раз, когда вы вносите изменения в основную ветку и хотите перенести ее в другую систему, сделайте что-нибудь вроде:
git pull
git checkout local
git rebase master
Это перезапишет текущие изменения на «локальном» (то есть для этой конкретной среды) против текущего состояния «master». ".
Ручная вещь, на которую вам нужно обратить внимание, - это то, где вы фиксируете изменение, которое хотите внести. Если он является локальным для системы, зафиксируйте его в «локальной» ветке этой системы, иначе зафиксируйте его в «главном» и отправьте в общий репозиторий.
Конечно, перебазирование может привести к конфликтам, которые придется разрешать вручную. Кроме того, если вы решите отправить локальные ветки в общий репозиторий, вам придется (а) выбрать уникальные имена для каждой среды и (б) иметь дело с толчками без перемотки вперед после перезагрузки. Обе эти проблемы разрешимы.
Хороший вопрос. Несмотря на то, что вы сказали:
... так как я не хочу оформить о проверке бесполезных файлов ...
Я бы пошел на размещение платформы или вариант-специфических элементов в той же ветке, что и главный код, Но в отдельном каталоге для этой платформы / варианта. Ключ состоит в том, чтобы выделить конкретную платформу, как можно более маленькую область (то есть. Избегайте IFDEF в главном коде).
E.g.:
/
+--common
+--linux
+--cygwin
+--windows
+--mac
Различные кроссплатформенные проекты организуют себя таким образом. Например. Проверьте структуру исходного кода Python для поддержки нескольких платформ.
Это упрощает ваш рабочий процесс в этом отношении, поэтому вы более свободны использовать филиалы для других более интересных целей.
В этом конкретном случае, когда в одной ветке развивается много общих файлов, и только несколько файлов конфигурации для каждой среды ... мы делаем не хранить файл конфигурации в Git. Вообще.
Мы храним шаблон указанных файлов конфигурации, плюс все конкретные значения для среды, а также сценарий, способный заменять переменные в файлах шаблонов на правильные значения (определение текущей платформы)
Таким образом, нам не нужно создавать ветку только для этих файлов.
Еще один хороший способ управлять такими файлами (с содержанием, зависящим от платформы) - использовать драйвер фильтра атрибутов git (см. Также Pro Git book ).
Драйвер фильтра состоит из команды
cleanи командыsmudge, любую из которых можно не указывать.
При проверке, когда указана командаsmudge, команда получает объект blob со стандартного ввода, а его стандартный вывод используется для обновления файл рабочего дерева.
Аналогично, командаcleanиспользуется для преобразования содержимого файла рабочего дерева при регистрации.
Таким образом, сценарий (управляемый с помощью Git), на который ссылается smudge, может заменить все переменные значениями, зависящими от платформы, в то время как чистый сценарий восстановит свое содержимое в нетронутый файл конфигурации.
Основная идея остается: избегать создания ветвей только для такого рода параллельной эволюции.