Realizar a configuração de um computador novo é uma das tarefas que, ao mesmo tempo, são super legais e super chatas. Todos nós provavelmente já tivemos que trocar de computador e reconfigurar todos os nossos arquivos.

Isto é um pouco trabalhoso para todas as pessoas, porém é ainda mais trabalhoso para devs. Temos uma série de arquivos de configuração de ambiente, variáveis, configurações de binários e os nossos preciosos shells que precisam estar configurados da maneira como queremos para que possamos ser os mais produtivos possíveis!

Vamos entender o que são os dotfiles e como você vai ser muito mais produtivo (e sua sanidade vai melhorar demais) quando você começar a versioná-los usando nosso querido Git.

Dotfiles? É de comer?

Dotfiles é o nome que foi dado ao conjunto de arquivos ocultos utilizados para armazenar a configuração de estado ou então a configuração de preferências de uma ferramenta.

O termo "dotfiles" vem, como a maioria das coisas em computação, dos antigos kernels do unix que adotava como prática a adição do prefixo . na frente do nome do arquivo para transformar, por padrão, aquele arquivo em um arquivo oculto, ou seja, que não era mostrado na listagem do ls. Por exemplo, /home/.hushlogin é um arquivo comum do Linux hoje em dia para remover a mensagem de login quando se faz um acesso via SSH.

Como qualquer sistema baseado no unix tem uma relação muito grande com arquivos, já que a maioria dos módulos e até mesmo dispositivos ou interfaces de rede são mostrados como arquivos dentro do sistema de arquivos, eles acabaram tendo uma grande importância para o desenvolvimento de software.

Hoje em dia, a grande maioria das ferramentas utilizam dotfiles para manter arquivos de configuração:

• Bash: usa o .bashrc
• Git: .gitconfig, .gitexcludes
• Vim: .vimrc

E muitos outros.

O problema dos dotfiles

O grande problema dos dotfiles é que eles são locais. Ou seja, sempre que você troca de máquina fisicamente você acaba tendo que configurar tudo de novo.

Existem vários projetos para solucionar o problema de como podemos manter os nossos dotfiles sincronizados em máquinas que possuem o mesmo sistema operacional. Pessoalmente, eu não gosto de nenhuma e prefiro realizar as minhas configurações manualmente, porém pode ser uma ótima ideia ter uma ferramenta para poder auxiliar a realizar não só o armazenamento dos dotfiles, mas também a execução e o link de todos eles na hora de colocá-los para funcionar.

Gerenciando seus dotfiles

Para começar, crie um novo repositório no seu GitHub, geralmente chamamos de dotfiles. Você também pode utilizar alguns repositórios de outras pessoas como inspiração, os meus dotfiles estão neste repositório, embora um pouco desatualizados.

É importante dizer que, se seus arquivos contém algum tipo de dado sensível, como senhas, chaves e etc, então talvez você precise fazer o gerenciamento deles em um repositório privado, ou então utilizar tutoriais como este para fazer com que eles sejam criptografados.

Mas então caímos na pergunta: Quais dotfiles devemos salvar? A resposta é todos. Todas as configuraçòes que puderem ser transformadas em arquivos e salvas no Git devem ser feitas. No meu caso eu tenho grande parte dos arquivos de configuração do Git, Vim e ZSH salvos como configurações no meu repositório.

Além disso, em computadores com sistema MacOS, é possível salvar as configurações utilizando um arquivo .macos, que ficou super famoso através dos dotfiles do Mathias Bynens, estes arquivos permitem que você tenha um setup consistente entre diversos sitemas MacOS.

Ainda para usuários Mac, temos o Mackup que é uma pequena ferramenta que armazena suas configurações de aplicações em um local seguro e depois permite o restore das mesmas em um novo computador. Bem como o BrewBundle que é uma ferramenta que permite que você descreva de forma declarativa quais são os apps instalados através do HomeBrew.

Para os próximos passos, vamos precisar realizar alguns links, então você não pode ter seus arquivos nos locais originais. Portanto se você já criou o repositório, é melhor mover os arquivos do que copiá-los.

Hard e soft links

Depois de mover todos os arquivos para uma estrutura que você se sinta feliz no seu repositório, você pode utilizar a funcionalidade de hard links dos sistemas baseados em Unix para podermos criar uma conexão entre o nosso arquivo original e o local aonde o dotfile vai existir.

Aqui entramos em uma discussão sobre se devemos criar um soft link (ou symbolic link) ou então um hard link, pessoalmente (e também nos meus dotfiles) eu crio um hard link entre os arquivos.

A maior diferença entre eles, no entanto, é o fato de que hard links vão ser um ponteiro para o arquivo em si, ou seja, é um nome diferente para o mesmo arquivo original que independe de qualquer outro recurso do sistema, é como se estivéssemos falando que um arquivo tem múltiplos nomes.

Isso cria uma facilidade grande quando temos que fazer o backup desses arquivos, porque hard links são ponteiros diretos para o conteúdo do arquivo original, então se alterarmos o hard link, vamos alterar o arquivo original também, você pode realizar um teste fazendo o seguinte:

export temp=$(mktemp -d)
touch $temp/original
ln $temp/original ~/hardlink

Agora edite o arquivo presente em ~/hardlink, que é o link em si, e execute cat $temp/original, veja que o conteúdo está presente lá também.

Sempre ao deletar o arquivo original, você também precisará deletar o link, então não adianta executar somente rm -rf $temp, é necessário rodar rm -rf ~/hardlink também.

Soft links não permitem que isso seja feito, uma vez que eles são apenas arquivos que apontam para outros arquivos. Portanto, para dotfiles eu prefiro muito mais ter um hardlink que me permite editar diretamente o meu dotfile aonde quer que ele esteja e essas mudanças são refletidas no meu repositório Git.

Criando os links

Agora que você já tem o repositório com os arquivos, o que falta é somente fazer o link deles para as localizações originais.

Uma das coisas que eu gosto de fazer quando organizo meus dotfiles é manter a estrutura de pastas original para que eu saiba aonde colocá-los depois, você pode fazer isso se quiser.

Para isso vamos usar o comando ln, a sintaxe deste comando é:

ln <arquivo original> <localização do link>

É importante dizer que a localização do link talvez precise ser um caminho absoluto, ou seja, não poderá ser um caminho do tipo ../ ou ~/, em alguns sistemas.

Faça um hard link para cada um dos seus arquivos dotfiles para a localização original deles, por exemplo:

ln ~/meus-dotfiles/home/.gitconfig ~/.gitconfig

O comando não exibe nenhuma saída se tudo correu bem, então a forma de identificar é verificando se, ao executar um comando ls -la no seu diretório de destino, o arquivo está presente lá também.

No caso de links simbólicos, ao executar uma listagem, a saída do comando mostra um caminho do tipo arquivo -> arquivo original

Conclusão

Agora, quando você estiver em uma nova máquina, basta clonar o repositório com seus dotfiles e executar o linking de cada um deles.

Você pode facilitar isso com um script de bootstrap, ou até mesmo ferramentas de bootstrap que podem inclusive baixar e instalar programas dependentes (como o HomeBrew) para que você só precise ligar a nova máquina, executar um único comando e nunca mais terá de configurar suas preferências novamente.

Se você quiser saber mais sobre dotfiles, de uma olhada neste site que contém uma série de ferramentas para colocar seus dotfiles seguramente no ar com o GitHub, também veja artigos como este, este e este para ter uma ideia de como você pode organizar e preparar os seus repositórios para receber os dotfiles da melhor forma possível.