Git com múltiplos perfis, do jeito certo
Quantas vezes você já fez um commit e só depois percebeu estar com o e-mail errado no autor? Se você trabalha com projetos pessoais e profissionais na mesma máquina, sabe como isso acontece fácil — e como consertar depois é um incômodo.
No começo do trabalho remoto, eu me vi nesse cenário: cada repositório exigia um perfil diferente, e manter isso manualmente era pedir para errar. Foi aí que descobri uma solução elegante, nativa do próprio Git, que me poupou retrabalho, estresse — e constrangimento em pull requests.
Organização é mais do que estética: é controle
O primeiro passo foi estruturar meus repositórios de forma clara, direto na raiz do disco:
D:/
└── repos/
├── personal/
└── acme/
Essa separação não só facilita a navegação, como permite que o Git entenda em qual contexto estou trabalhando — pessoal ou profissional.
O problema é que o Git, por padrão, usa um único autor global — e isso pode gerar situações delicadas. Imagine comitar em um repositório da empresa usando seu e-mail pessoal, ou, pior, contribuir para um projeto open source sem perceber que seu e-mail corporativo está sendo exposto publicamente.
Além de dificultar o rastreamento interno por ferramentas de auditoria, isso pode levar à exposição desnecessária de informações pessoais ou corporativas — e comprometer políticas de segurança ou compliance.
Git inteligente: mudando de identidade automaticamente
O Git permite que você defina configurações específicas com base no caminho do repositório. E isso muda o jogo.
Como o includeIf funciona — explicando a mágica
O includeIf é uma diretiva do Git que permite carregar configurações condicionais, com base em onde você está no sistema de arquivos. Ele avalia o caminho do repositório atual (gitdir:) e, se o prefixo bater com o que foi definido, carrega o bloco correspondente.
Isso significa que o Git está lendo seu .gitconfig e, ao detectar um caminho como:
[includeIf "gitdir:D:/repos/personal/"]
[user]
email = hadad@outlook.com
Ele entende que, sempre que você estiver dentro de D:/repos/personal/, deve aplicar esse user.email no lugar da configuração global.
🐧 Se você estiver no Linux ou macOS, o caminho segue o padrão POSIX: gitdir:/home/hadad/repos/personal/.
Por que o gitdir: precisa terminar com uma barra (/)
Quando você usa gitdir: dentro de includeIf, o Git faz uma verificação de prefixo de caminho. Isso significa que ele verifica se o diretório do repositório atual começa com o caminho fornecido.
✅ Correto:
[includeIf "gitdir:D:/repos/personal/"]
Esse padrão casa com qualquer repositório dentro de D:/repos/personal/, como:
- D:/repos/personal/webapi-dotnet/
- D:/repos/personal/webapp-react/
A barra no final indica: "aplique a configuração para qualquer coisa que esteja dentro dessa pasta".
❌ Incorreto:
[includeIf "gitdir:D:/repos/personal"]
Aqui o Git espera que o diretório do repositório seja exatamente D:/repos/personal, e nada mais. Ou seja, não aplicará a regra para D:/repos/personal/webapi-dotnet/, o que costuma ser o caso de uso real.
Em resumo: sempre que quiser que a configuração se aplique a todos os repositórios dentro de uma pasta, termine o caminho com /. Isso garante que o Git interprete corretamente como um prefixo de diretório — e evita comportamentos inesperados, como uma regra que nunca é aplicada.
Se nenhuma regra includeIf for satisfeita, o Git simplesmente volta a usar o que está no escopo global ou local do repositório, conforme a precedência usual (local > global > system).
Aplicando na prática
Exemplo com arquivos separados
No seu .gitconfig global:
[includeIf "gitdir:D:/repos/personal/"]
path = .gitconfig-personal
E no .gitconfig-personal:
[user]
email = hadad@outlook.com
Ou direto no mesmo arquivo:
[user]
name = Hadad Dev
[includeIf "gitdir:D:/repos/personal/"]
[user]
email = hadad@outlook.com
[includeIf "gitdir:D:/repos/acme/"]
[user]
email = hadad@acme.com
Com isso, qualquer projeto clonado ou criado dentro dessas pastas usará automaticamente o e-mail correto.
Sem comandos extras. Sem gambiarra. A identidade certa, no lugar certo. Sempre.
E se quiser ir além…
Essa técnica vale para muito mais que user.email. Você pode condicionar:
- Aliases personalizados, como co para checkout, mas só em projetos pessoais.
- Ferramentas diferentes de diff e merge dependendo do tipo de projeto.
- Hooks ativados apenas em repositórios críticos (como validação de mensagens de commit ou verificação de secrets).
Isso te dá poder real: comportamentos diferentes para contextos diferentes, sem interferência entre eles.
Conclusão
Se você ainda configura o user.email manualmente, está aceitando um risco desnecessário. O Git já tem tudo que você precisa para gerenciar múltiplos perfis com segurança, elegância e zero fricção.
Automatizar seu perfil de Git não é frescura — é profissionalismo.
#Git #DesenvolvimentoDeSoftware #ProdutividadeDev #BoasPraticas #DevExperience #GitConfig
