Gerenciando vários subconjuntos de dotfiles

Question

Estou usando o git para armazenar meus dotfiles, mas agora que comecei a usar várias implementações do Linux, estou descobrindo que meus dotfiles entre os sabores divergem um pouco, dependendo do que eu estou usando nessa build e a maneira como o sabor funciona. O que é uma boa maneira de rastrear e armazenar diferentes dotfiles para diferentes sabores? Posso usar o mesmo repo ou devo usar diferentes mesmo se muitos códigos forem compartilhados? Por exemplo, eu quero usar conjuntos separados de dotfiles para o meu centro de mídia Arch, WSL-Ubuntu e minha partição real do Ubuntu. Existem pontos em comum entre eles que gostaria de manter compartilhados e diferenças que gostaria de manter separadas. Como você lidaria com isso?

    

Answer 1

Repositórios

Se você contar os repositórios git working dir onde você verifica seus dotfiles, você terá mais de um de qualquer maneira. Mas você não precisa de múltiplos repositórios git para integração - um é o suficiente neste caso. (Se você tiver acesso aos outros diretórios home, você nem precisa disso, mas um único repositório vazio que você pode acessar de todos os checkouts é geralmente o modo mais fácil.)

Estratégias

Basicamente, você pode trabalhar em uma ramificação e diferenciar os ambientes sem a ajuda do git e usar o git apenas para rastrear e compartilhar as alterações. Ou você mantém as mudanças desviantes nos ramos. Detalhes:

1 filial

Você trabalha em uma agência e a mantém atualizada em todos os ambientes. Para as diferenças, você usa outros mecanismos, por exemplo,

• para dotfiles que são realmente scripts, if s dependendo do ambiente pode fazer coisas que são executadas em um ambiente e não nos outros
• os dotfiles em um diretório git geralmente são vinculados a links simbólicos em seus lugares certos no diretório inicial: configure-o para que os arquivos certos sejam vinculados se houver várias variantes
• gerar os arquivos a partir de uma única fonte por meio de um pré-processador também pode ser uma opção, especialmente se houver alterações em andamento de diferentes ambientes e para todos os ambientes no (s) mesmo (s) arquivo (s)

n Ramos

Tenha uma ramificação principal (master) se as alterações forem feitas regularmente. Cada ambiente tem seu próprio ramo, que deve refletir os arquivos desse ambiente. O ramo principal pode ser um dos ambientes, se é que você costuma trabalhar e os outros ambientes são os mesmos + modificações. A ramificação principal também pode ser independente, mas se cada ambiente for diferente dela, como você testa o conteúdo da ramificação principal?

As alterações específicas de um ambiente (ou seja, onde elas diferem de seu ramo principal) podem ser confirmadas no ramo desse ambiente. Manter-se atualizado com a ramificação principal significa, em seguida, git merge as alterações da ramificação principal em todas as suas ramificações de ambiente. Você não git merge de volta para o ramo principal, porque isso traria as diferenças para o ramo principal. (Se você fez alterações em um ambiente que deseja ter na ramificação principal - mas nem todas elas - git cherry-pick permite aplicar essas alterações separadamente.)

Qual deles usar

Veja seus arquivos e suas diferenças para decidir o caminho a seguir. A estratégia n branches limita a necessidade de ferramentas adicionais, mas efetivamente você tem n versões diferentes e usa ferramentas de git para mantê-las em sincronia, mas diferentes. (Isso pode ser um caso de "se tudo que você tem é um martelo, tudo parece um prego".) A estratégia 1 ramificação define uma fonte para sua configuração e usa git apenas como sistema de controle de versão distribuída , você pode precisar de scripts adicionais aqui para configuração, pré-processamento, etc.