Configurando o VS Code como editor padrão de commits

Falamos anteriormente de como uma boa mensagem de commit deve ser escrita: um título curto no imperativo, uma linha em branco, e um corpo explicando o porquê da mudança.

Só que existe um obstáculo prático nisso. O comando que todo mundo aprende primeiro é:

git commit -m "corrige o bug do login"

E o -m te prende a uma linha. Ele é ótimo para mudanças triviais, mas convida à preguiça: quando o único espaço disponível é um argumento de terminal, ninguém escreve o corpo da mensagem. O resultado é aquele histórico de git log cheio de "ajustes", "correções" e "update" — commits que não contam história nenhuma.

A solução é deixar o Git abrir um editor de texto de verdade. Rodando git commit sem o -m, o Git abre um arquivo temporário para você escrever a mensagem com o espaço e o conforto que ela merece. E o editor que ele abre é configurável.

⚙️ Pré-requisito: o comando code no terminal

O Git precisa conseguir chamar o VS Code pela linha de comando. Teste assim:

code --version

Se aparecerem três linhas (versão, hash do commit e arquitetura), está tudo certo. No Windows, o instalador do VS Code já adiciona esse comando ao PATH por padrão.

Se der "comando não encontrado", abra o VS Code, pressione Ctrl+Shift+P (ou Cmd+Shift+P no macOS), busque por Shell Command: Install 'code' command in PATH e execute. Depois feche e reabra o terminal — variáveis de ambiente só são lidas na abertura.

🔧 O comando

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

Vale entender cada pedaço, porque nenhum deles é decorativo:

• git config — lê e escreve as configurações do Git. Nesse caso, escreve uma linha no seu arquivo .gitconfig.
• --global — aplica a configuração ao seu usuário, valendo para todos os repositórios da máquina. Sem essa flag, a configuração ficaria restrita ao repositório atual. (Existe ainda --system, para todos os usuários da máquina.)
• core.editor — a chave de configuração que define qual programa o Git abre quando precisa que você escreva um texto: mensagens de commit, de tag, e o roteiro de um git rebase -i.
• --wait — a parte mais importante e a que mais causa dor de cabeça quando é esquecida. Por padrão, o comando code entrega o arquivo para a janela do VS Code que já está aberta e encerra imediatamente. Do ponto de vista do Git, isso significa "o usuário já terminou de editar" — ele então lê o arquivo ainda vazio e aborta o commit, antes mesmo de você digitar qualquer coisa. O --wait faz o comando ficar travado até você fechar a aba, que é exatamente o sinal que o Git espera.

🧪 Testando na prática

Com tudo configurado, faça uma alteração qualquer, adicione ao stage e rode o commit sem o -m:

git commit

O VS Code abre uma aba chamada COMMIT_EDITMSG. Esse é um arquivo temporário que vive dentro da pasta .git do seu repositório — ele não faz parte do projeto e não será versionado.

Você vai notar que ele já vem com várias linhas escritas, algo como:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Changes to be committed:
#	modified:   src/App.tsx

Todas essas linhas começam com #, e o Git as descarta ao salvar. Elas estão ali só como referência: servem para você conferir, na hora de escrever, exatamente quais arquivos estão entrando no commit. Escreva sua mensagem acima delas.

Terminado o texto, salve com Ctrl+S e feche a aba com Ctrl+W. É o fechamento da aba — não o salvamento — que devolve o controle ao terminal e efetiva o commit.

↩️ E se eu mudar de ideia?

Como o próprio cabeçalho avisa, uma mensagem vazia aborta o commit. Então, para cancelar, apague tudo o que você escreveu (ou simplesmente não escreva nada), salve e feche a aba. O Git responde com Aborting commit due to empty commit message. e nada é registrado — suas alterações continuam intactas no stage.

🔁 Outras opções de editor

O VS Code não é obrigatório. A mesma chave aceita qualquer editor:

git config --global core.editor "notepad"

O Bloco de Notas funciona sem o --wait porque ele não tem o comportamento de "reusar uma janela existente" — o processo só termina quando você fecha a janela, que é o que o Git precisa.

Existe também o caminho pelas variáveis de ambiente: buscar por "Editar as variáveis de ambiente do sistema" no menu Iniciar e criar uma variável de usuário chamada EDITOR. Vale conhecer a ordem de prioridade que o Git usa para decidir:

GIT_EDITOR  →  core.editor  →  VISUAL  →  EDITOR  →  vi (padrão)

Ou seja, o core.editor tem precedência sobre a variável EDITOR. A diferença prática é o alcance: core.editor afeta apenas o Git, enquanto EDITOR é respeitada por diversas outras ferramentas de linha de comando. Configurar as duas com o mesmo valor é uma escolha comum.

Para conferir o que está valendo agora — e de qual arquivo a configuração veio:

git config --show-origin --get core.editor

🎁 Bônus: um modelo pronto toda vez

Já que o objetivo é padronizar, o Git ainda permite pré-preencher o editor com um esqueleto de mensagem. Crie um arquivo ~/.gitmessage.txt com o seu modelo:

<tipo>: <resumo no imperativo, até 50 caracteres>

# Por quê: qual problema isso resolve?
# O que mudou:
# -
# Refs: #issue

E aponte o Git para ele:

git config --global commit.template ~/.gitmessage.txt

A partir daí, todo git commit abre o editor já com essa estrutura no lugar. As linhas comentadas com # funcionam como um roteiro que desaparece do commit final — um lembrete silencioso do padrão que você acabou de adotar.