Dominando la Configuración de Usuario en Git: Nombre, Correo Electrónico y Editor Predeterminado

La configuración de usuario de Git parece aburrida hasta la primera vez que tus commits aparecen bajo la dirección de correo electrónico incorrecta, el gráfico de contribuciones de tu empresa pierde la mitad de tus cambios, o Git abre un editor que no sabes cómo cerrar. La solución suele ser simple: establece tu nombre, correo electrónico y editor deliberadamente, y luego aprende a sobrescribirlos para un repositorio específico.

Lo importante no es memorizar cada bandera de git config. Es entender de dónde lee Git la configuración y cómo verificar el valor final que Git usará antes de hacer un commit.

Comprendiendo los Niveles de Configuración de Git

Git emplea una jerarquía de archivos de configuración. Las configuraciones definidas en un nivel superior pueden ser sobrescritas por configuraciones definidas en un nivel inferior. Comprender estos niveles te permite aplicar configuraciones de manera granular o universal.

Hay tres niveles principales de configuración:

Nivel de Sistema (--system): Se aplica a cada usuario y cada repositorio en toda la máquina. Rara vez se usa para la identidad del usuario a menos que se administre un servidor de compilación dedicado.
Nivel Global (--global): Se aplica a todos los repositorios propiedad del usuario actual en la máquina. Aquí es donde normalmente configuras tu user.name y user.email principales.
Nivel Local (--local): Se aplica solo al repositorio específico en el que te encuentras actualmente. Esto te permite usar una identidad diferente para un proyecto específico (por ejemplo, trabajo vs. personal).

Visualizando la Configuración Actual

Antes de hacer cambios, es útil ver qué está configurado actualmente Git. Puedes listar configuraciones para todos los niveles o solo para uno específico:

# Ver todas las configuraciones en todos los niveles
git config --list

# Ver solo configuraciones globales
git config --global --list

Configurando tu Identidad de Usuario (Nombre y Correo Electrónico)

Tu nombre y dirección de correo electrónico son las piezas más críticas de información de usuario almacenadas en Git. Identifican quién hizo el cambio.

1. Configurando la Identidad Global del Usuario

Para la mayoría de los usuarios, configurar el nombre y el correo electrónico de forma global es el primer paso recomendado. Esto asegura que todos tus proyectos futuros lleven esta identidad predeterminada. Reemplaza los marcadores de posición con tu información real.

Configurando el Nombre:

git config --global user.name "Tu Nombre Completo"

Configurando el Correo Electrónico:

Se recomienda encarecidamente usar la dirección de correo electrónico asociada con tu cuenta de GitHub/GitLab/Bitbucket, especialmente si usas claves SSH o firma de commits.

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

Mejor Práctica: Usa la dirección de correo electrónico exacta vinculada a tu proveedor de alojamiento para asegurar que las contribuciones se muestren correctamente en plataformas remotas.

2. Sobrescribiendo la Identidad para un Repositorio Específico (Nivel Local)

A veces, puedes contribuir a un proyecto que requiere una atribución específica (por ejemplo, usar un correo electrónico de trabajo para un repositorio de cliente). Puedes sobrescribir las configuraciones globales solo dentro de ese repositorio.

Navega al directorio raíz del repositorio y ejecuta los comandos de configuración sin la bandera --global:

# Navega al directorio de tu proyecto
cd ~/proyectos/proyecto-cliente-alfa

# Establece un nombre específico para este repositorio
git config user.name "Nombre de Trabajo"

# Establece un correo electrónico específico para este repositorio
git config user.email "[email protected]"

Cuando hagas commit dentro de este repositorio, Git usará estas configuraciones locales en lugar de las globales.

Cómo Git Elige la Identidad

Cuando Git procesa un commit, verifica los niveles en orden: Local -> Global -> Sistema. La primera configuración que encuentra para user.name o user.email es la que se usa.

Configurando tu Editor de Texto Predeterminado

Cuando Git necesita tu entrada, como al escribir un mensaje de commit, una instrucción de rebase o una nota de resolución de conflictos de fusión, abre tu editor de texto configurado. Por defecto, podría ser un editor de terminal básico como vi o vim, lo que puede ser desafiante para nuevos usuarios.

Configurando la Preferencia Global del Editor

Puedes configurar Git para usar tu editor preferido en todas tus máquinas o proyectos usando la bandera --global.

Usando VS Code como Editor

Si prefieres Visual Studio Code y tienes la integración de línea de comandos instalada (code), configúralo de la siguiente manera:

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

La bandera --wait es crucial; le dice a Git que pause la ejecución hasta que cierres el archivo abierto en VS Code, asegurando que el mensaje de commit esté finalizado.

Usando Sublime Text como Editor

Para usuarios de Sublime Text:

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

Usando Nano o Vim (Si ya estás familiarizado)

Si prefieres un editor de terminal simple:

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

# Para Vim (a menudo el predeterminado)
git config --global core.editor "vim"

Probando tu Configuración del Editor

La forma más fácil de probar si tu configuración del editor funciona es iniciar una enmienda que requiera un mensaje, o crear un commit sin proporcionar la bandera -m:

# Crea un archivo ficticio e intenta un commit sin -m
touch archivotemp.txt
git add archivotemp.txt
git commit 
# Esto debería abrir tu editor recién configurado.

Corrigiendo una Identidad Incorrecta Existente

Cambiar user.name y user.email afecta a commits futuros. No reescribe commits que ya existen. Si tu último commit tiene el autor incorrecto y aún no lo has subido, puedes enmendarlo después de arreglar la configuración:

git config user.name "Nombre Correcto"
git config user.email "[email protected]"
git commit --amend --reset-author

Si el commit incorrecto ya está subido a una rama compartida, ten cuidado. Reescribir el historial publicado puede interrumpir a otras personas. Para una rama privada, una enmienda y un push forzado pueden ser aceptables:

git push --force-with-lease

Para una rama compartida, la respuesta más segura suele ser dejar el historial intacto y arreglar la identidad para commits futuros. Si muchos commits necesitan reparación, usa una herramienta de reescritura de historial solo después de coordinar con el equipo.

Verificando de Dónde Vino un Valor

Cuando Git se comporta de manera extraña, git config --list puede ser demasiado ruidoso. Usa --show-origin para que Git te diga qué archivo suministró cada valor:

git config --show-origin --list

Podrías ver una salida como:

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

Eso significa que el valor local del repositorio gana en el repositorio actual. Esta es la forma más rápida de diagnosticar "Cambié mi correo electrónico global pero Git todavía usa el antiguo".

También puedes preguntar por un solo valor:

git config --show-origin user.email

Una Configuración de Trabajo y Personal que se Mantiene

Un patrón común es mantener una identidad global personal y sobrescribir los repositorios de trabajo localmente:

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

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

Algunos equipos prefieren clones separados bajo directorios separados. Las versiones más nuevas de Git admiten inclusiones condicionales, que pueden cargar automáticamente una configuración de trabajo para repositorios bajo una ruta:

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

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

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

Las reglas exactas de coincidencia de rutas pueden ser un poco sorprendentes en diferentes plataformas, así que pruébalo dentro de un repositorio real:

cd ~/trabajo/algun-repo
git config --show-origin user.email

Problemas del Editor que Puedes Evitar

La configuración core.editor importa principalmente cuando Git necesita un mensaje o archivo de instrucciones: commits de fusión, rebases interactivos, enmiendas de commits y commits sin -m. Si Git abre Vim y no te sientes cómodo allí, puede parecer que el comando está atascado.

Para VS Code, la bandera --wait no es opcional:

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

Sin --wait, Git puede abrir el archivo y continuar inmediatamente antes de que termines de escribir el mensaje. Para servidores solo de terminal, nano suele ser menos sorprendente:

git config --global core.editor "nano"

Puedes probar el editor sin crear un cambio real en el proyecto:

git commit --allow-empty

Escribe un mensaje de prueba, guarda, y luego elimina el commit vacío si no lo quieres:

git reset --soft HEAD~1

Firma de Commits y Cuentas de Alojamiento

Tu correo electrónico de Git es independiente de la autenticación. Las claves SSH, los tokens de acceso personal y el inicio de sesión del navegador deciden si puedes hacer push. user.email decide qué correo electrónico del autor se escribe en el objeto del commit.

Los proveedores de alojamiento generalmente emparejan los commits con tu cuenta por dirección de correo electrónico. Si usas un correo electrónico de privacidad, establece esa dirección exacta:

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

Si tu organización requiere commits firmados, la identidad es solo una parte de la configuración. También puedes necesitar user.signingkey, commit.gpgsign, o configuración de firma SSH. Mantén eso separado de la configuración básica de nombre/correo electrónico para que puedas depurar una capa a la vez.

Autor, Committer y Sobrescrituras del Entorno

Git almacena tanto un autor como un committer en cada commit. La mayoría de las veces son la misma persona. Difieren cuando alguien aplica un parche de otro desarrollador, hace rebase de commits, o enmienda un commit originalmente escrito por otra persona.

Puedes ver ambos campos con:

git log --format=fuller -1

Esa salida es útil cuando alguien dice "Git usó el correo electrónico incorrecto" pero el registro normal de una línea solo muestra el autor. El committer puede ser diferente porque un mantenedor aplicó el parche, o porque un rebase recreó el commit.

Git también puede leer la identidad de variables de entorno:

GIT_AUTHOR_NAME="Build Bot" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Actualizar archivos generados"

Los sistemas de CI a veces usan este patrón. Está bien cuando es intencional, pero es confuso cuando una tubería filtra estas variables en un shell de desarrollador o un script local. Si Git ignora tu configuración, verifica el entorno:

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

Deshaz las sobrescrituras accidentales antes de hacer commit:

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Una Pequeña Política de Equipo que Previene un Historial Desordenado

Para equipos, la mejor política de configuración de usuario de Git suele ser corta:

Usa tu nombre real o el mismo identificador que tu equipo reconoce.
Usa un correo electrónico de la empresa para repositorios de la empresa.
Usa un correo electrónico verificado del proveedor de alojamiento para que los commits se adjunten a la cuenta correcta.
No reescribas el historial compartido solo para limpiar metadatos antiguos de autor a menos que el equipo esté de acuerdo.
Documenta el core.editor preferido solo si tus scripts de incorporación dependen de él.

Puedes agregar una verificación previa al commit o previa al push para dominios de correo electrónico, pero mantenla amigable. Un hook local que bloquee cada commit porque alguien está emparejando desde una máquina diferente creará fricción. Una política del lado del servidor o una verificación de CI en ramas protegidas suele ser más fácil de manejar.

Aquí hay una verificación local simple que puedes ejecutar manualmente antes de subir código de trabajo:

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

Si algún commit muestra un correo electrónico personal en una rama de la empresa, arréglalo antes de abrir la solicitud de extracción. Eso es mucho más fácil que reparar una rama fusionada más tarde.

Solución de Problemas Comunes de Configuración

Si git config --global user.email muestra el valor correcto pero los commits aún usan otro, verifica si estás dentro de un repositorio con una sobrescritura local:

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

Si el valor local es incorrecto, reemplázalo o desactívalo:

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

Desactivar el valor local hace que Git recurra al valor global nuevamente. Eso suele ser más limpio que establecer el mismo valor en cada repositorio.

Si Git dice Author identity unknown, significa que Git no pudo encontrar un user.name y user.email utilizables de la configuración o el entorno. Establece ambos, no solo uno:

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

En servidores compartidos, evita --system a menos que administres la máquina para todos. Una identidad a nivel de sistema puede hacer que usuarios no relacionados hagan commit accidentalmente como la misma persona. Los agentes de compilación son la principal excepción, e incluso allí suele ser mejor configurar el espacio de trabajo de CI o la cuenta de servicio explícitamente.

Lista de Verificación Rápida

Usa git config --global para configuraciones que se aplican en todas partes, como tu identidad y editor predeterminados.
Usa git config (sin banderas) dentro de un repositorio para sobrescribir configuraciones globales localmente.
Usa git config --show-origin --list cuando necesites saber qué archivo está ganando.
Usa git commit --amend --reset-author solo cuando sea apropiado reescribir el commit más reciente.
Usa --wait al configurar editores gráficos para que Git espere a que termines de editar.