Dominando a Configuração de Usuário do Git: Nome, Email e Editor Padrão

A configuração de usuário do Git parece chata até a primeira vez que seus commits de trabalho aparecem com o endereço de email errado, o gráfico de contribuição da sua empresa perde metade das suas alterações, ou o Git abre um editor que você não sabe como sair. A correção geralmente é simples: defina seu nome, email e editor deliberadamente, e saiba como substituí-los para um repositório específico.

O importante não é memorizar cada flag do git config. É entender de onde o Git lê as configurações e como verificar o valor final que o Git usará antes de fazer um commit.

Entendendo os Níveis de Configuração do Git

O Git emprega uma hierarquia de arquivos de configuração. As configurações definidas em um nível superior podem ser substituídas por configurações definidas em um nível inferior. Entender esses níveis permite aplicar configurações de forma granular ou universal.

Existem três níveis principais de configuração:

Nível de Sistema (--system): Aplica-se a todos os usuários e todos os repositórios em toda a máquina. Raramente é usado para identidade de usuário, a menos que esteja gerenciando um servidor de build dedicado.
Nível Global (--global): Aplica-se a todos os repositórios pertencentes ao usuário atual na máquina. É aqui que você normalmente define seu user.name e user.email primários.
Nível Local (--local): Aplica-se apenas ao repositório específico em que você está atualmente. Isso permite usar uma identidade diferente para um projeto específico (ex.: trabalho vs. pessoal).

Visualizando as Configurações Atuais

Antes de fazer alterações, é útil ver o que o Git está configurado para usar atualmente. Você pode listar as configurações para todos os níveis ou apenas para um específico:

# Ver todas as configurações em todos os níveis
git config --list

# Ver apenas as configurações globais
git config --global --list

Configurando Sua Identidade de Usuário (Nome e Email)

Seu nome e endereço de email são as peças mais críticas de informação do usuário armazenadas no Git. Eles identificam quem fez a alteração.

1. Definindo a Identidade Global do Usuário

Para a maioria dos usuários, definir o nome e o email globalmente é o primeiro passo recomendado. Isso garante que todos os seus projetos futuros carreguem essa identidade padrão. Substitua os placeholders pelas suas informações reais.

Definindo o Nome:

git config --global user.name "Seu Nome Completo"

Definindo o Email:

É altamente recomendável usar o endereço de email associado à sua conta GitHub/GitLab/Bitbucket, especialmente se você usa chaves SSH ou assinatura de commits.

git config --global user.email "[email protected]"

Melhor Prática: Use o endereço de email exato vinculado ao seu provedor de hospedagem para garantir que as contribuições apareçam corretamente em plataformas remotas.

2. Substituindo a Identidade para um Repositório Específico (Nível Local)

Às vezes, você pode contribuir para um projeto que requer uma atribuição específica (ex.: usar um email de trabalho para um repositório de cliente). Você pode substituir as configurações globais apenas dentro desse repositório.

Navegue até o diretório raiz do repositório e execute os comandos de configuração sem a flag --global:

# Navegue até o diretório do seu projeto
cd ~/projetos/projeto-cliente-alfa

# Defina um nome específico para este repositório
git config user.name "Nome de Trabalho"

# Defina um email específico para este repositório
git config user.email "[email protected]"

Ao commitar dentro deste repositório, o Git usará essas configurações locais em vez das globais.

Como o Git Escolhe a Identidade

Quando o Git processa um commit, ele verifica os níveis na ordem: Local -> Global -> Sistema. A primeira configuração que encontrar para user.name ou user.email é a usada.

Configurando Seu Editor de Texto Padrão

Quando o Git precisa de entrada sua—como ao escrever uma mensagem de commit, uma instrução de rebase ou uma nota de resolução de conflito de merge—ele abre seu editor de texto configurado. Por padrão, pode ser um editor de terminal básico como vi ou vim, o que pode ser desafiador para novos usuários.

Definindo a Preferência Global do Editor

Você pode configurar o Git para usar seu editor preferido em todas as suas máquinas ou projetos usando a flag --global.

Usando VS Code como Editor

Se você prefere o Visual Studio Code e tem a integração de linha de comando instalada (code), defina-o da seguinte forma:

git config --global core.editor "code --wait"

A flag --wait é crucial; ela diz ao Git para pausar a execução até que você feche o arquivo aberto no VS Code, garantindo que a mensagem de commit seja finalizada.

Usando Sublime Text como Editor

Para usuários do Sublime Text:

git config --global core.editor "subl -n -w"

Usando Nano ou Vim (Se já estiver familiarizado)

Se você prefere um editor de terminal simples:

# Para Nano
git config --global core.editor "nano"

# Para Vim (geralmente o padrão)
git config --global core.editor "vim"

Testando Sua Configuração de Editor

A maneira mais fácil de testar se sua configuração de editor está funcionando é iniciar um amend que requer uma mensagem, ou criar um commit sem fornecer a flag -m:

# Crie um arquivo dummy e tente um commit sem -m
touch arquivoteste.txt
git add arquivoteste.txt
git commit 
# Isso deve abrir seu editor recém-configurado.

Corrigindo uma Identidade Errada Existente

Alterar user.name e user.email afeta commits futuros. Não reescreve commits que já existem. Se seu último commit tem o autor errado e você ainda não o enviou, você pode corrigi-lo após ajustar a configuração:

git config user.name "Nome Correto"
git config user.email "[email protected]"
git commit --amend --reset-author

Se o commit ruim já foi enviado para um branch compartilhado, tenha cuidado. Reescrever o histórico publicado pode atrapalhar outras pessoas. Para um branch privado, um amend e force push podem ser aceitáveis:

git push --force-with-lease

Para um branch compartilhado, a resposta mais segura geralmente é deixar o histórico como está e corrigir a identidade para commits futuros. Se muitos commits precisarem de reparo, use uma ferramenta de reescrita de histórico somente após coordenar com a equipe.

Verificando de Onde Veio um Valor

Quando o Git se comporta de forma estranha, git config --list pode ser muito ruidoso. Use --show-origin para que o Git informe qual arquivo forneceu cada valor:

git config --show-origin --list

Você pode ver uma saída como:

file:/Users/alex/.gitconfig    [email protected]
file:.git/config               [email protected]

Isso significa que o valor local do repositório vence no repositório atual. Esta é a maneira mais rápida de diagnosticar "Mudei meu email global, mas o Git ainda usa o antigo".

Você também pode perguntar por um único valor:

git config --show-origin user.email

Uma Configuração de Trabalho e Pessoal que se Sustenta

Um padrão comum é manter uma identidade global pessoal e substituir repositórios de trabalho localmente:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

cd ~/trabalho/payments-api
git config user.email "[email protected]"

Algumas equipes preferem clones separados em diretórios separados. Versões mais recentes do Git suportam includes condicionais, que podem carregar automaticamente uma configuração de trabalho para repositórios sob um caminho:

# ~/.gitconfig
[user]
    name = Alex Rivera
    email = [email protected]

[includeIf "gitdir:~/trabalho/"]
    path = ~/.gitconfig-trabalho

# ~/.gitconfig-trabalho
[user]
    email = [email protected]

As regras exatas de correspondência de caminho podem ser um pouco surpreendentes entre plataformas, então teste dentro de um repositório real:

cd ~/trabalho/algum-repo
git config --show-origin user.email

Problemas de Editor que Você Pode Evitar

A configuração core.editor importa principalmente quando o Git precisa de uma mensagem ou arquivo de instrução: commits de merge, rebases interativos, amendments de commit e commits sem -m. Se o Git abrir o Vim e você não se sentir confortável com ele, pode parecer que o comando está travado.

Para VS Code, a flag --wait não é opcional:

git config --global core.editor "code --wait"

Sem --wait, o Git pode abrir o arquivo e continuar imediatamente antes que você termine de escrever a mensagem. Para servidores apenas com terminal, nano geralmente é menos surpreendente:

git config --global core.editor "nano"

Você pode testar o editor sem criar uma alteração real no projeto:

git commit --allow-empty

Escreva uma mensagem de teste, salve e, em seguida, exclua o commit vazio se não quiser mantê-lo:

git reset --soft HEAD~1

Assinatura de Commits e Contas de Hospedagem

Seu email do Git é separado da autenticação. Chaves SSH, tokens de acesso pessoal e login no navegador decidem se você pode fazer push. user.email decide qual email do autor é escrito no objeto do commit.

Os provedores de hospedagem geralmente correspondem commits à sua conta pelo endereço de email. Se você usa um email de privacidade, defina esse endereço exato:

git config --global user.email "[email protected]"

Se sua organização exige commits assinados, a identidade é apenas uma parte da configuração. Você também pode precisar de user.signingkey, commit.gpgsign ou configuração de assinatura SSH. Mantenha isso separado da configuração básica de nome/email para que você possa depurar uma camada de cada vez.

Autor, Committer e Substituições de Ambiente

O Git armazena tanto um autor quanto um committer em cada commit. Na maioria das vezes, são a mesma pessoa. Eles diferem quando alguém aplica um patch de outro desenvolvedor, faz rebase de commits ou altera um commit originalmente escrito por outra pessoa.

Você pode ver ambos os campos com:

git log --format=fuller -1

Essa saída é útil quando alguém diz "O Git usou o email errado", mas o log normal de uma linha mostra apenas o autor. O committer pode ser diferente porque um mantenedor aplicou o patch, ou porque um rebase recriou o commit.

O Git também pode ler a identidade de variáveis de ambiente:

GIT_AUTHOR_NAME="Build Bot" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Atualizar arquivos gerados"

Sistemas de CI às vezes usam esse padrão. Tudo bem quando intencional, mas confuso quando um pipeline vaza essas variáveis para um shell de desenvolvedor ou um script local. Se o Git ignorar sua configuração, verifique o ambiente:

env | rg '^GIT_(AUTHOR|COMMITTER)'

Remova substituições acidentais antes de commitar:

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Uma Pequena Política de Equipe que Previne Histórico Bagunçado

Para equipes, a melhor política de configuração de usuário do Git geralmente é curta:

Use seu nome real ou o mesmo identificador que sua equipe reconhece.
Use um email da empresa para repositórios da empresa.
Use um email verificado do provedor de hospedagem para que os commits sejam anexados à conta correta.
Não reescreva o histórico compartilhado apenas para limpar metadados antigos de autor, a menos que a equipe concorde.
Documente o core.editor preferido apenas se seus scripts de integração dependerem dele.

Você pode adicionar uma verificação de pré-commit ou pré-push para domínios de email, mas mantenha-a amigável. Um hook local que bloqueia todo commit porque alguém está pareando de uma máquina diferente criará atrito. Uma política do lado do servidor ou verificação de CI em branches protegidos geralmente é mais fácil de gerenciar.

Aqui está uma verificação local simples que você pode executar manualmente antes de enviar código de trabalho:

git config user.email
git log --format='%h %ae %s' origin/main..HEAD

Se algum commit mostrar um email pessoal em um branch da empresa, corrija-o antes de abrir o pull request. Isso é muito mais fácil do que reparar um branch mesclado posteriormente.

Solucionando Surpresas Comuns de Configuração

Se git config --global user.email mostra o valor correto, mas os commits ainda usam outra coisa, verifique se você está dentro de um repositório com uma substituição local:

git config --local user.email
git config --show-origin user.email

Se o valor local estiver errado, substitua-o ou remova-o:

git config user.email "[email protected]"
git config --unset user.email

Remover o valor local faz com que o Git volte ao valor global novamente. Isso geralmente é mais limpo do que definir o mesmo valor em todos os repositórios.

Se o Git disser Author identity unknown, significa que o Git não conseguiu encontrar um user.name e user.email utilizáveis na configuração ou no ambiente. Defina ambos, não apenas um:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

Em servidores compartilhados, evite --system a menos que você gerencie a máquina para todos. Uma identidade em nível de sistema pode fazer com que usuários não relacionados commitem acidentalmente como a mesma pessoa. Agentes de build são a principal exceção, e mesmo assim geralmente é melhor configurar o workspace de CI ou a conta de serviço explicitamente.

Lista de Verificação Rápida

Use git config --global para configurações que se aplicam em todos os lugares, como sua identidade e editor padrão.
Use git config (sem flags) dentro de um repositório para substituir configurações globais localmente.
Use git config --show-origin --list quando precisar saber qual arquivo está vencendo.
Use git commit --amend --reset-author apenas quando reescrever o commit mais recente for apropriado.
Use --wait ao configurar editores gráficos para que o Git espere você terminar de editar.