Управление несколькими подмножествами файлов точек

330
GameKyuubi

Я использую git для хранения своих файлов точек, но теперь, когда я начал использовать несколько реализаций Linux, я обнаружил, что мои файлы точек между версиями немного расходятся, в зависимости от того, для чего я использую эту сборку, и того, как аромат действует. Какой хороший способ отследить и сохранить различные точечные файлы для разных вкусов? Могу ли я использовать одно и то же репо, или я должен использовать разные, даже если много общего кода? Например, я хочу использовать отдельные наборы точечных файлов для моего медиацентра Arch, WSL-Ubuntu и моего реального раздела Ubuntu. Между ними есть общие черты, которые я хотел бы разделить, и различия, которые я хотел бы разделить. Как бы вы справились с этим?

1

1 ответ на вопрос

0
Stefan Moch

Хранилища

Если вы посчитаете репозитории git working dir, в которых вы проверяете свои файлы точек, у вас их будет больше, в любом случае. Но вам не нужно несколько git-репозиториев для интеграции - в этом случае достаточно одного. (Если у вас есть доступ к другим домашним каталогам, вам это даже не нужно, но, как правило, самый простой способ - получить доступ к единственному репо, доступ к которому можно получить из всех проверок.)

Стратегии

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

1 филиал

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

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

н филиалы

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

Изменения, характерные для среды (т. Е. Где они отличаются от вашей основной ветви), могут быть зафиксированы в ветви этой среды. Таким образом, поддержание актуальности основной ветки означает, что вы git mergeпереходите из основной ветки во все ветки вашей среды. Вы не вернете git mergeих обратно в основную ветку, потому что это внесет различия в основную ветку. (Если вы внесли изменения в среду, которую вы хотите иметь в основной ветке - но не во всех - git cherry-pickпозволяет применить эти изменения отдельно.)

Какой использовать

Посмотрите на ваши файлы и их различия, чтобы решить, какой путь. П ветви стратегия ограничивает необходимость дополнительного инструмента, но эффективно у вас есть п различных версий и использование GIT инструментов, чтобы держать их в синхронизации, но разные. (Это может быть случай «если все, что у вас есть, это молоток, все выглядит как гвоздь».) Стратегия с 1 веткой определяет один источник для вашей конфигурации и использует git только в качестве распределенной системы контроля версий, вам могут потребоваться дополнительные сценарии здесь для настройки, предварительной обработки и т. д.