Configurar Git por primera vez: nombre, email y editor

Instalas Git, abres la terminal con ganas de hacer tu primer commit, y lo primero con lo que te topas es una pregunta incómoda: ¿quién eres? Antes de guardar un solo cambio, Git quiere saber tu nombre y tu email. Configurar Git es ese paso de dos minutos que casi nadie explica bien y que te ahorra líos durante años.

Si todavía no lo tienes instalado, empieza por la guía para instalar Git en Windows. Y si todo esto te suena a chino y no tienes claro qué es Git ni para qué sirve, lee primero qué es Git y sus primeros pasos. Aquí doy por hecho que ya lo tienes instalado y que sabes abrir una terminal. Con eso te sobra.

¿Por qué Git te pide un nombre y un email?

Git graba tu nombre y tu email dentro de cada commit, de forma permanente, para dejar constancia de quién hizo cada cambio.

Un commit es una foto del estado de tu código en un momento concreto. Cada vez que haces uno, Git escribe junto a esa foto una etiqueta de autoría: tu nombre y tu email. Piensa en la firma que dejas al final de un contrato. Una vez firmado, ahí se queda.

Por eso importa configurarlo antes del primer commit y no después. Si cambias el nombre o el email más tarde, el cambio solo afecta a los commits que hagas a partir de ese momento. Los que ya hiciste conservan la etiqueta vieja. Git no hace esto por fastidiar: el historial es un registro de lo que ocurrió, y reescribirlo es harina de otro costal.

Cómo configurar tu nombre y tu email

Se hace con dos comandos, uno para el nombre y otro para el email (el orden entre ambos da igual):

# Tu nombre: aparecerá como autor de cada commit (las comillas permiten espacios)
git config --global user.name "Tu Nombre"
# Tu email: la otra mitad de la etiqueta de autoría
git config --global user.email "tu@email.com"

Pon el nombre con el que quieras aparecer y un email real, no uno de usar y tirar. Ese email es el que luego GitHub o GitLab usan para asociar tus commits a tu perfil. Con estas dos líneas Git ya sabe quién eres y puedes empezar a commitear.

¿Qué significa --global y en qué se diferencia de local?

El flag --global le dice a Git que guarde esa configuración para todos tus repositorios, escribiéndola en un único archivo de tu usuario llamado ~/.gitconfig.

Si ejecutas el mismo comando sin --global dentro de la carpeta de un repositorio, Git lo guarda en el archivo .git/config de ese repo y solo aplica ahí. Cuando hay valores en los dos sitios, el del repositorio gana: la configuración local tiene prioridad sobre la global, y la global sobre la del sistema ^[1].

Ámbito	Flag	Archivo	Afecta a	Precedencia
Sistema	--system	/etc/gitconfig	todos los usuarios de la máquina	la más baja
Usuario	--global	~/.gitconfig	todos tus repositorios	gana al sistema
Repositorio	--local (o nada, dentro de un repo)	.git/config	solo ese repo	gana a todas

¿Para qué sirve la config local en la práctica? Para tener identidades distintas según el proyecto. El caso típico: en tu portátil usas tu email personal por defecto, pero los repos del trabajo tienen que ir con tu email corporativo. Entras en la carpeta del repo del trabajo y sobrescribes ahí la identidad, sin tocar la global:

# Dentro de la carpeta del repositorio, sin --global:
# esto se guarda solo en .git/config de ESTE repo
git config user.name "Tu Nombre"
git config user.email "tu@empresa.com"

El ~/.gitconfig es un archivo de texto normal: lo abres con cualquier editor y lo lees tal cual.

Cómo elegir el editor por defecto

Git abre un editor de texto cuando necesita que escribas algo largo, por ejemplo el mensaje de un commit al que no le pasaste -m, o el mensaje de un merge. Con core.editor decides cuál abre:

# VS Code: el --wait hace que Git espere a que cierres la pestaña
git config --global core.editor "code --wait"
# nano: el editor de terminal más sencillo para empezar
git config --global core.editor "nano"
# vim: si ya lo conoces y te manejas con él
git config --global core.editor "vim"

El detalle importante es el --wait de VS Code. Sin él, VS Code se abre pero Git no se queda esperando: da por hecho que ya terminaste, y te encuentras con un mensaje vacío. Con --wait, Git pausa hasta que cierras la pestaña. Puedes poner VS Code, nano, vim o cualquier otro editor que uses a diario. Si no tienes preferencia, nano es el que menos dolores de cabeza da al principio.

Cómo comprobar que quedó bien configurado

git config --list muestra toda tu configuración de golpe. Y si añades --show-origin, Git te dice además de qué archivo sale cada valor:

# Toda tu configuración, y el archivo de origen de cada valor
git config --list --show-origin
# O lee un solo valor suelto, sin ruido
git config user.name

--show-origin es la herramienta que te salva cuando algo no cuadra. Si un repo aparece con un email raro, esta vista te dice si el valor viene de tu ~/.gitconfig global o de un .git/config local que configuraste hace meses y olvidaste. Leer un valor suelto (git config user.name) es la comprobación rápida cuando solo quieres confirmar una cosa.

Un ajuste extra: la rama por defecto

Cuando creas un repositorio nuevo, Git le pone nombre a la primera rama. Con init.defaultBranch eliges cuál:

# La rama inicial de los repos NUEVOS se llamará "main" en vez de "master"
git config --global init.defaultBranch main

Durante años esa primera rama se llamaba master por defecto. Hoy el estándar de facto en GitHub, GitLab y compañía es main, así que configurarlo ahora te evita el paso manual de renombrarla en cada repo nuevo. Ojo: esto solo afecta a los repositorios que crees a partir de ahora, no a los que ya tienes.

Errores comunes al configurar Git

Empezar a commitear sin configurar nada

Es el clásico. Te lanzas a programar, haces cuarenta commits en una tarde, y días después descubres que todos llevan un autor con la pinta de Tu Nombre <tu@portátil.local> o directamente vacío. Configurar ahora el nombre correcto no arregla los commits viejos: esos ya tienen su etiqueta grabada. Por eso los dos comandos de identidad son literalmente lo primero que haces tras instalar Git.

El email de Git no es tu contraseña de GitHub

Esto confunde a mucha gente al empezar. El email de Git no es una credencial de acceso, es solo la etiqueta de autoría que viaja en cada commit. GitHub lo usa para asociar tus commits a tu perfil cuando coincide con un email de tu cuenta, pero jamás para dejarte entrar. Para autenticarte están tu contraseña, las claves SSH o los tokens. Poner tu contraseña en user.email no tiene ningún sentido y, encima, quedaría escrita en el historial.

Poner code sin --wait

Si configuras core.editor "code" a secas, Git abrirá VS Code y seguirá su camino sin esperarte. Resultado: commits con mensaje vacío. Añade el --wait.

Usar --global cuando querías identidad por proyecto

Si en el trabajo dejas tu email personal en la configuración global, todos los repos de la empresa llevarán ese email en el historial. Lo correcto es configurar la identidad corporativa en local dentro de cada repo de trabajo, como viste en la tabla de arriba.

Checklist de configuración inicial

• user.name configurado con git config --global user.name
• user.email configurado con el email real que quieres que aparezca como autor
• core.editor apunta a un editor que sabes usar (con --wait si es VS Code)
• init.defaultBranch en main para los repositorios nuevos
• git config --list --show-origin muestra tus valores saliendo de ~/.gitconfig
• tienes claro que estos valores solo afectan a los commits futuros

El siguiente paso

Ya tienes Git listo: sabe quién eres y guardará tu nombre en cada commit que hagas. El paso natural ahora es crear tu primer repositorio y hacer tu primer commit, donde estos ajustes empiezan a notarse de verdad.

Si prefieres practicar esto con ejercicios guiados en vez de solo leerlo, lo trabajamos paso a paso en el curso Git de cero a profesional.

Un concepto nuevo cada semana

Suscribirme

Fuentes

1. Documentación oficial de git-config: ámbitos --system, --global y --local, sus archivos, la precedencia entre ellos y las claves user.name, user.email, core.editor e init.defaultBranch.

Preguntas Frecuentes

¿El email de Git es mi contraseña de GitHub?

No. El email solo firma la autoría de tus commits y no sirve para iniciar sesión. Lo que de verdad te da acceso a GitHub es una clave SSH (si te conectas por SSH) o un token de acceso personal (si te conectas por HTTPS); eso se configura aparte, una sola vez. Si al hacer git push te piden credenciales, el asunto va por ahí y no por tu user.email.

¿Puedo cambiar el nombre o el email que configuré en Git?

Sí. Vuelve a ejecutar git config --global user.name o user.email con el valor nuevo y listo. La pega es que el cambio solo afecta a los commits que hagas a partir de ese momento; los que ya hiciste conservan la etiqueta antigua. Para reescribir la autoría de los commits pasados hay herramientas: git commit --amend corrige el último commit, y git filter-repo (o el más antiguo git filter-branch) sirve para reescribir muchos de golpe. Eso sí, es terreno avanzado y conviene evitarlo al principio.

¿Tengo que configurar Git en cada repositorio nuevo?

No, si usaste --global. La configuración global vive en ~/.gitconfig y sirve para todos tus repos automáticamente. Solo repites la configuración dentro de un repo concreto cuando quieres una identidad distinta ahí, por ejemplo para separar tus proyectos del trabajo de los personales.

¿Qué editor pongo si no sé cuál elegir?

nano. Es el más sencillo para empezar: se maneja con los atajos que ves en la parte de abajo de la pantalla, guardas con Ctrl+O y sales con Ctrl+X. Cuando te sientas cómodo, cambias a VS Code (con code --wait) o al que prefieras.

¿Dónde se guarda toda esta configuración?

En archivos de texto normales. La configuración global está en ~/.gitconfig, dentro de tu carpeta de usuario, y la de cada repositorio en su propio .git/config. Puedes abrirlos con cualquier editor y verás tus valores en texto plano. De hecho, git config --list --show-origin te dice exactamente de qué archivo sale cada uno.