Você já fez um commit no repositório do trabalho e percebeu que estava com o seu e-mail pessoal? Ou o contrário? Esse é um dos erros mais comuns de quem usa Git com múltiplas contas no mesmo computador.
Neste tutorial você vai aprender a configurar tudo corretamente, de uma vez, usando chaves SSH separadas e .gitconfig condicional — sem gambiarras.
O problema
Por padrão o Git usa uma configuração global:
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"
Isso significa que todos os repositórios no seu computador usam o mesmo usuário. Quando você tem contas separadas (ex: joao@empresa.com no GitLab da empresa e joao@gmail.com no GitLab pessoal), os commits vão sair com o e-mail errado.
A solução profissional envolve duas partes:
- Chaves SSH separadas para cada conta
-
.gitconfigcondicional que aplica o usuário certo — e a chave SSH certa — por pasta
Passo 1 — Gerar as chaves SSH
Abra o terminal e gere uma chave para cada conta. Use nomes diferentes para não sobrescrever:
# Chave para a conta pessoal
ssh-keygen -t ed25519 -C "joao@gmail.com" -f ~/.ssh/id_ed25519_pessoal
# Chave para a conta do trabalho
ssh-keygen -t ed25519 -C "joao@empresa.com" -f ~/.ssh/id_ed25519_trabalho
💡 Por que
ed25519? É o algoritmo mais moderno, mais seguro e recomendado pelo GitHub, GitLab e Bitbucket. Evite RSA a menos que seu servidor seja muito antigo.
Ao final você terá quatro arquivos em ~/.ssh/:
id_ed25519_pessoal ← chave privada (nunca compartilhe)
id_ed25519_pessoal.pub ← chave pública (você registra no GitLab)
id_ed25519_trabalho
id_ed25519_trabalho.pub
Passo 2 — Registrar as chaves no GitLab
Para cada conta:
- Copie o conteúdo da chave pública:
# Pessoal
cat ~/.ssh/id_ed25519_pessoal.pub
# Trabalho
cat ~/.ssh/id_ed25519_trabalho.pub
- Acesse Settings → SSH and GPG keys → New SSH key na conta correspondente e cole o conteúdo.
Faça isso nas duas contas, cada uma com a sua respectiva chave pública.
Passo 3 — Configurar o Git por pasta (o pulo do gato)
Aqui está o diferencial: usar o includeIf do Git para aplicar configurações diferentes dependendo de onde o repositório está — incluindo qual chave SSH usar, sem precisar mexer no ~/.ssh/config.
A ideia é simples: você organiza seus projetos em pastas separadas:
~/
├── projetos/
│ ├── pessoal/ ← projetos pessoais
│ └── trabalho/ ← projetos da empresa
3.1 — Criar os .gitconfig específicos
Cada arquivo define o usuário e a chave SSH que o Git deve usar naquela pasta. O core.sshCommand instrui o Git a chamar o SSH com uma chave específica e ignorar qualquer configuração do ~/.ssh/config (o -F /dev/null garante isso):
# Configuração pessoal
cat > ~/.gitconfig-pessoal << 'EOF'
[user]
name = João Silva
email = joao@gmail.com
[core]
sshCommand = ssh -i ~/.ssh/id_ed25519_pessoal -F /dev/null
EOF
# Configuração do trabalho
cat > ~/.gitconfig-trabalho << 'EOF'
[user]
name = João Silva
email = joao@empresa.com
[core]
sshCommand = ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null
EOF
💡 O que é
-F /dev/null? Diz ao SSH para ignorar completamente o~/.ssh/config. Isso evita que configurações globais de SSH interfiram e garante que a chave especificada em-iseja a única usada. Sem essa flag, o SSH ainda pode carregar outras identidades do seu agente.
3.2 — Configurar o .gitconfig global com includeIf
Edite ~/.gitconfig:
vim ~/.gitconfig
Deixe assim:
[user]
name = João Silva
email = joao@gmail.com # fallback (usado fora das pastas mapeadas)
[includeIf "gitdir:~/projetos/pessoal/"]
path = ~/.gitconfig-pessoal
[includeIf "gitdir:~/projetos/trabalho/"]
path = ~/.gitconfig-trabalho
⚠️ A barra no final do caminho é obrigatória.
~/projetos/trabalho/funciona;~/projetos/trabalhonão.
Passo 4 — Testar a conexão SSH
Com os .gitconfig configurados, o teste correto é deixar o Git invocar o SSH automaticamente — sem passar a chave no comando.
O detalhe importante: o includeIf só é ativado dentro de um repositório git. Por isso o teste cria um repo temporário dentro de cada pasta mapeada e roda git ls-remote, que faz uma conexão SSH real sem precisar de nenhum clone:
# Crie as pastas base se ainda não existirem
mkdir -p ~/projetos/pessoal ~/projetos/trabalho
# Teste da conta pessoal
cd ~/projetos/pessoal
git init .teste-pessoal && cd .teste-pessoal
git ls-remote git@gitlab.com:joao-pessoal/meu-projeto.git HEAD
# deve listar o HEAD autenticado como joao-pessoal
cd .. && rm -rf .teste-pessoal
# Teste da conta do trabalho
cd ~/projetos/trabalho
git init .teste-trabalho && cd .teste-trabalho
git ls-remote git@gitlab.com:empresa/projeto-empresa.git HEAD
# deve listar o HEAD autenticado como conta da empresa
cd .. && rm -rf .teste-trabalho
💡 O
git initdentro da pasta é necessário porque oincludeIf "gitdir:..."só é avaliado quando o Git está operando dentro de um repositório. Ols-remotefaz a conexão SSH sem precisar de histórico ou commits — é o teste mais leve possível.
Se aparecer Permission denied (publickey), volte ao Passo 2 e verifique se a chave pública foi cadastrada na conta correta.
Passo 5 — Clonar repositórios
Com essa abordagem, as URLs de clone continuam normais — você usa git@gitlab.com em todos os casos. O Git saberá qual chave usar com base na pasta onde o repositório está:
# Repositório pessoal — clone normalmente dentro de ~/projetos/pessoal/
git clone git@gitlab.com:joao-pessoal/meu-projeto.git ~/projetos/pessoal/meu-projeto
# Repositório do trabalho — clone dentro de ~/projetos/trabalho/
git clone git@gitlab.com:empresa/projeto-empresa.git ~/projetos/trabalho/projeto-empresa
Para repositórios já clonados fora da pasta certa, mova-os para a pasta correta ou defina o sshCommand manualmente só naquele repo:
cd ~/algum-repo-avulso
git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null"
git config user.email "joao@empresa.com"
Verificação final
Dentro de cada repositório, confirme que o Git está usando o usuário e a chave corretos:
cd ~/projetos/trabalho/projeto-empresa
git config user.email
# deve retornar: joao@empresa.com
git config core.sshCommand
# deve retornar: ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null
cd ~/projetos/pessoal/meu-projeto
git config user.email
# deve retornar: joao@gmail.com
Resumo da estrutura
~/.ssh/
├── id_ed25519_pessoal ← chave privada pessoal
├── id_ed25519_pessoal.pub
├── id_ed25519_trabalho ← chave privada do trabalho
└── id_ed25519_trabalho.pub
~/.gitconfig ← config global com includeIf
~/.gitconfig-pessoal ← user, email e sshCommand pessoal
~/.gitconfig-trabalho ← user, email e sshCommand do trabalho
~/projetos/
├── pessoal/ ← clones pessoais aqui
└── trabalho/ ← clones do trabalho aqui
Problemas comuns
"Still using the wrong email after setup"
Verifique se a barra final está no includeIf. Rode git config user.email dentro do repositório (não globalmente).
"Permission denied (publickey)"
Rode ssh -i ~/.ssh/id_ed25519_trabalho -vT git@gitlab.com para ver o que acontece. Confirme que a chave pública está cadastrada na conta correta no GitLab.
"sshCommand não está sendo aplicado"
Confirme que o repositório está dentro da pasta mapeada no includeIf e que a barra final está presente. Teste com git config core.sshCommand dentro do repo.
Conclusão
Com essa configuração você nunca mais vai:
- ❌ Commitar com o e-mail errado
- ❌ Misturar credenciais de contas diferentes
- ❌ Precisar criar aliases de host no
~/.ssh/config - ❌ Precisar configurar manualmente cada repositório
A lógica é elegante: o includeIf do Git ativa automaticamente o user, o email e o core.sshCommand certos com base na pasta — tudo em um único lugar, sem efeitos colaterais no restante do sistema.
Gostou? Deixa uma reação e compartilha com aquele dev que sempre commita com o e-mail errado 👇












