Quais Dotfiles Você Deve Commitar no Git (e Quais Ignorar)

Gerenciar dotfiles em múltiplas máquinas é uma dor de cabeça comum para desenvolvedores. Você passou horas aperfeiçoando sua configuração de shell, configurações de editor e preferências de ferramentas—mas quais arquivos pertencem ao controle de versão? Mais importante ainda, como sincronizá-los sem expor dados sensíveis ou criar um pesadelo de manutenção?

Este artigo compara as duas abordagens mais populares de gerenciamento de dotfiles—repositórios Git bare e GNU Stow—enquanto aborda as considerações críticas de segurança que determinam o que deve e não deve ser commitado.

O Que Commitar: A Abordagem Focada em Segurança

Antes de escolher um método de gerenciamento, entenda o que pertence ao seu repositório de dotfiles. A regra de ouro: nunca commite secrets.

Seguro para Commitar

• Configurações de shell (.bashrc, .zshrc, .config/fish/)
• Configurações de editor (.vimrc, .config/nvim/)
• Configuração do Git (.gitconfig sem credenciais)
• Configurações de emulador de terminal (.alacritty.yml, .config/kitty/)
• Configurações de gerenciador de janelas (.config/i3/, .config/sway/)
• Configurações de ferramentas (.tmux.conf, .config/starship.toml)

Nunca Commitar

• Chaves privadas SSH (~/.ssh/id_*)
• Tokens de API e credenciais
• Strings de conexão de banco de dados
• Chaves de licença
• Cookies de navegador ou dados de sessão
• Arquivos de histórico de comandos (.bash_history, .zsh_history)

Para arquivos de configuração que misturam configurações públicas com secrets, use templates ou separe as partes sensíveis em arquivos carregados via source que permanecem locais.

Repositório Git Bare: O Método Minimalista

A abordagem de repositório Git bare trata seu diretório home como uma working tree sem poluí-lo com uma pasta .git. Este método não requer ferramentas adicionais—apenas Git.

Processo de Configuração

git init --bare $HOME/.dotfiles
alias config='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
config config --local status.showUntrackedFiles no

Gerenciando Arquivos

config add ~/.vimrc
config commit -m "Add vim configuration"
config push origin main

Prós:

• Zero dependências além do Git
• Controle de versão direto sem symlinks
• Funciona identicamente em todos os sistemas Unix-like
• Sem localização de armazenamento intermediária

Contras:

• Fácil commitar acidentalmente arquivos sensíveis
• Requer disciplina com .gitignore
• Pode interferir com outros repositórios Git em subdiretórios
• Menos intuitivo para organizar configurações modulares

GNU Stow: A Abordagem Organizada

GNU Stow gerencia dotfiles através de symlinks, mantendo seus arquivos reais organizados em um diretório dedicado enquanto mantém os caminhos esperados na sua pasta home.

Estrutura de Diretórios

~/.dotfiles/
├── vim/
│   └── .vimrc
├── git/
│   └── .gitconfig
└── shell/
    ├── .bashrc
    └── .zshrc

Implantação

cd ~/.dotfiles
stow vim git shell  # Cria symlinks em ~

Prós:

• Organização clara e modular por aplicação
• Implantação seletiva fácil por máquina
• Detecção de conflitos integrada
• Suporta arquivos de ignore por pacote (.stow-local-ignore)

Contras:

• Requer instalação do GNU Stow
• Algumas aplicações não lidam bem com symlinks (systemd, certos editores)
• Pode quebrar quando aplicações sobrescrevem symlinks
• Camada adicional de abstração para entender

Escolhendo Sua Estratégia de Gerenciamento de Configuração

Sua escolha entre repositório Git bare e GNU Stow depende das suas necessidades específicas:

Use repositório Git bare quando:

• Você quer zero dependências
• Seus dotfiles são relativamente simples
• Você prefere controle de versão direto
• Você está confortável com os internals do Git

Use GNU Stow quando:

• Você gerencia configurações complexas e modulares
• Você precisa de organização por aplicação
• Você implanta diferentes configurações em diferentes máquinas
• Você prefere estrutura de diretórios visual

Melhores Práticas para Produtividade do Desenvolvedor

Independentemente do método escolhido, siga estas melhores práticas de controle de versão:

1. Use .gitignore agressivamente: Comece com * e permita arquivos explicitamente
2. Separe público de privado: Mantenha um repositório privado para configurações sensíveis
3. Documente sua configuração: Inclua instruções de instalação e implantação
4. Teste em um sistema limpo: Verifique regularmente seu processo de bootstrap
5. Use carregamento condicional: Lide com configurações específicas de SO graciosamente

Para ambientes de equipe, considere manter um repositório de configuração “abençoado” separado com padrões sensatos, permitindo customização individual através de overrides locais.

Conclusão

Tanto repositórios Git bare quanto GNU Stow resolvem o problema de gerenciamento de dotfiles efetivamente—a escolha se resume às suas necessidades de complexidade e preferências de ferramentas. O fator crítico não é qual método você escolhe, mas manter separação estrita entre configurações públicas e dados sensíveis. Comece com uma mentalidade focada em segurança, escolha a abordagem que combina com seu workflow, e você terá um ambiente portátil e versionado que aumenta sua produtividade como desenvolvedor sem comprometer a segurança.

Perguntas Frequentes

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.