Devo evitar o uso do git para rastrear arquivos individuais com histórico separado, como em / var / named?

Question

Em janeiro de 2012, Randal Schwartz deu uma palestra chamada Introdução ao Git que eu gostei muito, mas fiquei confuso sobre sua admoestação não para usar o git para rastrear arquivos individuais com histórico não relacionado ou separado.

A página 4 de seus slides contém os seguintes itens. . .

But not for...

• Tracking file permissions and ownership
• Tracking individual files with separate history
• Making things painful

. . e aqui está o que ele diz, cerca de 4 minutos em:

It is not optimized for any kind of metadata about the files. It does not, it does not, track file permissions or file ownership. That is not its job. It's managing source files, and sources don't have owners, sources don't have permissions. Sources are used in recipes to build the real thing that you are going to deploy. So git does not have technology about that. People have tried to build structures on top of it to do that, with some degree of success, but really let's look at basically what git is meant for and not what people are building on top of it.

It's also not meant for tracking individual files with unrelated or separate history. For example, you may think, "Oh, I really like this. I want to track all my et cetera with it. But et cetera is really a bunch of separate, unrelated files. You wouldn't be doing branching and merging. . . add this change to that change and eventually want to back out both of them at the same time. It doesn't really work that way. So it's not good for individual files.

I still use RCS to track individual files in my /etc. It's really fast, it's cheap, and I can get back to the data I need to. It's also not optimized for making things painful. Ok? It's designed to be easy and stuff.

Pessoalmente, não tenho planos de rastrear meu / etc com git, mas recentemente comecei a usar o git para rastrear / var / named (configurações do BIND). Dado o que Randal tem a dizer acima, devo parar de usar o git para esse propósito? Existe uma desvantagem, um problema que não estou antecipando, uma pegadinha? Até agora tudo está funcionando exatamente como eu esperava, e não tive problemas, mas na verdade hesitei em começar a usar o git para rastrear / var / named por causa do aviso acima.

Sou influenciado pelo recurso scm_track_enabled de Cobbler que diz "habilita um gatilho cuja versão controla todas as alterações em / var / lib / cobbler quando eventos de adição, edição ou sincronização são executados. Isso pode ser usado para reverter para versões anteriores do banco de dados, gerar feeds RSS ou para outras finalidades de auditoria ou backup. git é o SCM recomendado para uso com esse recurso. " Meu uso de git com / var / named é muito semelhante a isso.

(Como uma nota lateral, eu nunca usei RCS e não posso imaginar me incomodando em aprender, mesmo se é fácil, quando eu já tenho uma boa compreensão do git.)

Especificamente, estou pensando em usar o git para rastrear / var / named, mas agradeço respostas sobre as melhores práticas para usar o git para rastrear diretórios como ele.

    

Answer 1

Isso está se desviando para um território "bastante subjetivo". Mas ...

Não vejo nada de errado em usar o git para rastrear esse tipo de coisa. Sim, foi desenvolvido para rastrear coleções grandes e complexas de arquivos de origem inter-relacionados. Isso não significa que não seja adequado para rastrear pequenas coleções de arquivos não relacionados.

Pessoalmente, eu uso o etckeeper para rastrear /etc em meus servidores, usando o backend git. Funciona bem. Quando instalado a partir do repositório apt do Ubuntu, ele vem com ótimos ganchos para o apt, então ele irá iniciar automaticamente um commit coincidente com cada nova instalação do pacote. Muito útil.

De qualquer forma, experimente, não vai doer nada, e se você quiser mudar para outro sistema de controle de versão no futuro, há muitas ferramentas de migração disponíveis.

    

Answer 2

Território subjetivo, de fato. Eu não gosto do etckeeper, o que faz é criar uma história muito confusa de / etc. Agora para / var / named (suponho que é onde suas zonas estão definidas) pode ser melhor, especialmente se você tiver apenas algumas zonas, mas ainda assim seria um hack feio.

Acho que a maneira "correta" de fazer isso é usar o Puppet ou outro software similar de gerenciamento de configuração. Em vez de configurar seus servidores, você escreve o código Puppet que configura seus servidores. Eu uso o mercurial (mas você pode usar o git) para gerenciar o repositório do Puppet code. É útil para ramificar e mesclar (por exemplo, você está trabalhando em uma nova configuração, que você não tem certeza é testado o suficiente, e então você deve corrigir urgentemente um problema em um servidor de produção; neste caso você ramifica a partir da versão estável e depois mesclar). A combinação de Puppet + DVCS é muito útil e muito limpa, mas Puppet é uma pequena fera que precisa de um pouco de tempo para domar, e bind é particularmente difícil de fazer certo com o Puppet por causa dos números de série da zona.

Atualização:

Eu tenho pensado nisso e tenho a tendência de concluir que não há nada errado em usar o git para rastrear / var / named, e que não é um hack feio. Sim, os arquivos estão relacionados. Sim, você pode querer clonar a fim de fazer uma revisão séria de sua configuração, ramo, a fim de manter sua configuração de produção durante a revisão e mesclar, quando terminar a revisão (embora tudo isso possa ser incomum).

Um pouco fora do tópico, mas há duas coisas sobre a configuração do bind que eu não gosto. Primeiro, para adicionar uma zona, eu preciso adicionar / modificar dois arquivos: named.conf e o arquivo de zona. Isso é desnecessariamente complicado. Eu preferiria uma configuração similar à do apache, com arquivos de zona em / etc / bind / zones-available, linkado de / etc / bind / zones-enabled, sem a necessidade de tocar em named.conf. Em segundo lugar, os números de série são um incômodo. Nós principalmente automatizamos a manutenção deles; em máquinas gerenciadas por marionetes Eu tenho um shell script que os conserta, e em outros eu uso um plugin vim. O fato de nós os automatizarmos significa que eles podem estar ausentes. Carimbos de data / hora de arquivo podem ser usados em vez disso. Os números de série irão criar alguma fealdade no histórico do repositório, mas isso é um problema de bind, e não um problema de git, ou da prática de usar o git para rastrear a configuração de bind.

    

Answer 3

Pergunte a si mesmo ...

Eu "voltaria" a um commit em particular no git, se ele cobrisse tudo de / etc?

Eu "mesclaria" um commit no meu estado atual, se ele abrangesse todos os itens / etc?

Suponho que a resposta seja NÃO, NÃO, NÃO.

Se sim, git é a ferramenta errada. O Git está rastreando uma árvore de arquivos, não um único arquivo. É por isso que defendo o RCS para arquivos únicos.