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/"]
  path = .gitconfig-personal

E você tiver um .gitconfig-personal preenchido da seguinte forma:

[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

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