En la lección anterior aprendimos el mecanismo de configuración: git config, sus niveles y su precedencia. Ahora toca aplicarlo. Esta lección recorre los valores concretos que conviene fijar en un equipo antes de empezar a trabajar, y lo hace acompañando a Ana mientras prepara su portátil para arrancar gestor-tareas.

Algunos de estos ajustes son obligatorios: sin ellos Git se negará a confirmar o lo hará con datos incorrectos que después solo se arreglan reescribiendo el historial. Otros son fuertemente recomendables porque evitan sorpresas desagradables: quedarse atrapado en un editor desconocido, que un compañero de otro sistema operativo vea todo el fichero como modificado, o que Git haga fusiones inesperadas al integrar cambios.

Al terminar, el equipo de Ana quedará listo y cerraremos el módulo enlazando con el módulo 2, donde por fin creará el repositorio.

1. La identidad: user.name y user.email
2. La rama por defecto: init.defaultBranch
3. El editor: core.editor
4. Finales de línea: core.autocrlf y core.eol
5. Comportamiento al integrar: pull.rebase
6. Comportamiento al enviar: push.default
7. Credenciales: credential.helper
8. Color e idioma de la salida
9. Tabla resumen de ajustes recomendados
10. Comprobación final del equipo de Ana

Es el único ajuste verdaderamente obligatorio. Cada confirmación registra quién la hizo, y Git se niega a crear ninguna si no sabe quién eres.

Desglose:

• --global escribe en ~/.gitconfig, de modo que aplica a todos los repositorios de Ana. Es lo correcto para la identidad.
• user.name es tu nombre tal y como aparecerá en el historial. Usa tu nombre real y completo: es lo que verán tus compañeros durante años en cada línea del historial. Nada impide usar un alias, pero dificulta identificar autorías.
• user.email es el correo asociado a la confirmación. Es el campo que las plataformas usan para vincular una confirmación con una cuenta de usuario: si el correo no coincide con ninguno registrado en GitHub o GitLab, la confirmación aparecerá sin foto de perfil ni enlace.

Al intentar confirmar, Git muestra un error explícito:

En algunas configuraciones antiguas, Git no fallaba y adivinaba una identidad a partir del nombre de usuario y del nombre de la máquina, produciendo autores como [email protected]. Ese comportamiento está desaconsejado y desactivado por defecto en versiones modernas, precisamente porque generaba historiales con autorías inservibles.

El autor forma parte del objeto commit, y ya vimos en El Modelo de Datos de Git que el hash se calcula sobre ese contenido. Cambiar el autor de una confirmación existente significa crear una confirmación nueva y reescribir todo el historial posterior. Si ese historial ya está compartido, el problema se multiplica.

Traducción práctica: configura la identidad antes de tu primera confirmación, no después.

Si publicas en GitHub y no quieres exponer tu correo real, la plataforma ofrece una dirección de reenvío del tipo [email protected]. Se configura igual:

Las confirmaciones siguen vinculándose a tu cuenta, pero tu correo real no queda en el historial público. Recuerda que el historial es permanente: un correo confirmado y publicado ya no se puede retirar sin reescribir.

Como vimos en Configurando Git, esto se resuelve con configuración local o, mejor, con includeIf. Ana ya tiene su carpeta ~/personal/ preparada para eso.

Cuando se crea un repositorio, Git crea automáticamente una primera rama. Históricamente se llamaba master; desde 2020 el estándar de facto del sector es main, adoptado por GitHub, GitLab y la mayoría de proyectos nuevos.

Sin este ajuste, Git sigue usando master y muestra un aviso largo cada vez que se crea un repositorio, recordando que el nombre por defecto está sujeto a cambio. Fijarlo elimina el aviso y, sobre todo, evita la incoherencia de tener repositorios con master en local y main en el servidor.

Dos matices importantes:

• Solo afecta a repositorios nuevos. Los ya existentes conservan el nombre que tuvieran.
• No renombra nada. Si trabajas en proyectos antiguos con master, seguirán llamándose así y no hay ningún problema en ello.

Git abre un editor de texto en varias situaciones: al escribir un mensaje de confirmación largo, al resolver un rebase interactivo, al editar la configuración con --edit. Si no se configura, usa el valor de las variables de entorno GIT_EDITOR, VISUAL o EDITOR, y a falta de todas ellas, Vim en la mayoría de sistemas Unix.

Ese último caso es un clásico: un principiante ejecuta un comando, aparece una pantalla azul incomprensible y no consigue salir. (Por si te ocurre: se sale con Esc, luego :q! e Intro para descartar, o :wq para guardar.)

Configura el editor que ya sepas usar:

La parte crítica en los editores gráficos es la opción de espera:

• --wait en VS Code, -w en Sublime.
• Sin ella, el editor se abre y devuelve el control a Git inmediatamente, así que Git cree que has terminado y recibe un fichero vacío. El resultado es un mensaje de confirmación en blanco y la operación abortada.

Ana usa VS Code para programar, así que:

Requisito en macOS para VS Code. El comando code debe estar disponible en el PATH. Se activa desde el propio VS Code con la paleta de comandos (Cmd+Shift+P) → Shell Command: Install 'code' command in PATH.

Este es el ajuste que más problemas causa en equipos con sistemas operativos mixtos, y gestor-tareas es exactamente ese caso: Ana en Linux, Bruno en macOS y Carla en Windows.

Los sistemas operativos marcan el final de línea de forma distinta:

Para Git, que compara contenidos byte a byte, un fichero con LF y el mismo fichero con CRLF son contenidos distintos, con hashes distintos. Sin tratamiento, ocurre esto: Carla clona el proyecto en Windows, su editor convierte los finales de línea al guardar y de repente Git le indica que los cuatro ficheros están modificados de arriba abajo, aunque no haya cambiado ni una palabra. Su siguiente confirmación cambiará el 100 % de las líneas y hará ilegible cualquier revisión de código.

La convención universal es guardar siempre LF dentro del repositorio y convertir al vuelo en los sistemas que lo necesiten.

Qué hace cada valor exactamente:

Con esta configuración, el repositorio siempre contiene LF, Carla ve CRLF en su disco como espera Windows, y Ana y Bruno ven LF. Nadie percibe cambios falsos.

Es un ajuste complementario que define qué final de línea se escribe en el disco para los ficheros marcados explícitamente como texto:

Valores posibles: lf, crlf o native (el del sistema, que es el valor por defecto). Solo entra en juego cuando core.autocrlf es false y hay atributos de fichero definidos.

core.autocrlf es una configuración personal: depende de que cada miembro del equipo la haya puesto bien en su máquina. La solución robusta es un fichero .gitattributes versionado dentro del proyecto, que impone la norma a todo el mundo independientemente de su configuración:

Este fichero se trata en profundidad en el módulo 8, en la lección Atributos de Fichero con .gitattributes. Menciónalo aquí como la meta a la que llegar; core.autocrlf es la red de seguridad individual mientras tanto.

Cuando descargas cambios del remoto y tu rama local también ha avanzado, Git tiene que integrar las dos líneas. Hay tres formas de hacerlo, y desde la versión 2.27 Git se niega a elegir por ti: muestra un aviso y exige que configures cuál prefieres.

Recomendación para empezar: pull.ff only. Es la opción más conservadora: cuando no hay conflicto de líneas de desarrollo, integra sin ruido; cuando lo hay, se detiene y te dice que decidas. Así aprendes a reconocer la situación en lugar de que Git tome una decisión silenciosa que no entiendes todavía.

Muchos equipos experimentados prefieren pull.rebase true para mantener el historial lineal. Es una elección legítima, pero implica entender el rebase y sus riesgos, que se tratan en el módulo 5. Cuando llegues allí podrás cambiar el valor con conocimiento de causa.

Ajuste complementario, muy recomendable si más adelante activas el rebase automático:

Guarda temporalmente los cambios sin confirmar antes del rebase y los restaura después, evitando el error "no puedes hacer rebase con cambios pendientes". El guardado temporal (stash) se trata en el módulo 5.

Determina qué ramas se envían cuando ejecutas git push sin argumentos.

simple es el valor por defecto desde Git 2.0 y el recomendado: envía solo la rama actual, y únicamente si su nombre coincide con el de la rama remota que sigue. Es el comportamiento menos sorprendente.

Un complemento muy práctico:

Disponible desde Git 2.37, hace que al enviar por primera vez una rama nueva, Git configure automáticamente su rama de seguimiento en lugar de fallar con el mensaje fatal: The current branch X has no upstream branch. Ahorra escribir git push --set-upstream origin <rama> cada vez que se crea una rama, algo que en un flujo de trabajo por ramas ocurre a diario.

Los remotos y el envío de cambios son el contenido del módulo 4; aquí solo dejamos el terreno preparado.

Cuando trabajes con repositorios remotos por HTTPS, Git pedirá usuario y contraseña —en realidad, un token de acceso— en cada operación. Un gestor de credenciales las guarda de forma segura para no tener que repetirlas.

Advertencia sobre store. Guarda las credenciales sin cifrar, en texto legible. Aparece en muchos tutoriales por ser la más sencilla y es una mala práctica de seguridad. El módulo 8 dedica una lección a las mejores prácticas de seguridad.

La alternativa a todo esto es usar SSH en lugar de HTTPS, con claves criptográficas en lugar de contraseñas. Es lo que suelen preferir los equipos, y se trata en el módulo 4, en la lección de autenticación con repositorios remotos.

auto activa el color cuando la salida va a una terminal y lo desactiva cuando va a un fichero o a otro programa, evitando que aparezcan códigos de escape en los volcados. Suele venir activo por defecto en Git moderno, pero fijarlo explícitamente no está de más.

Se puede afinar por comando:

Y personalizar colores concretos, con la sintaxis <color de texto> <color de fondo> <atributo>:

Es opcional y cuestión de gusto; con color.ui auto es suficiente para trabajar cómodamente.

Git traduce sus mensajes al idioma del sistema si la traducción está disponible. En un sistema en español verás mensajes como:

Aquí hay una decisión práctica que tomar. La recomendación de este curso es dejar la salida de Git en inglés, por tres razones concretas:

1. Casi toda la documentación, los manuales y las respuestas que encontrarás al buscar un mensaje de error están en inglés. Buscar el texto exacto de un error traducido rara vez da resultados.
2. Las traducciones son parciales: verás mensajes mezclados en dos idiomas.
3. Los ejemplos de este curso y de cualquier material técnico muestran la salida en inglés.

Para forzarlo:

Si prefieres mantener el resto del sistema en español y afectar solo a Git, existe una variable específica:

En Windows, Git Bash usa el idioma del instalador; la variable de entorno funciona igualmente si se define en el fichero de arranque del shell.

Ana decide dejarlo en inglés para que los mensajes coincidan con la documentación.

Este es el conjunto completo que Ana aplica en su portátil, con la justificación de cada uno:

Y aquí está todo junto, tal y como Ana lo ejecuta en su portátil Linux. Puedes copiar este bloque cambiando el nombre, el correo y el editor:

El fichero ~/.gitconfig resultante:

Doce líneas de configuración que evitan la mayoría de los tropiezos habituales de los primeros meses.

Antes de dar el equipo por listo, Ana verifica que todo esté en su sitio. Estos son los comandos de comprobación, con la salida esperada.

Si alguno de los dos no devuelve nada, falta por configurar y Git no permitirá confirmar.

Muestra cada clave con el fichero del que procede. Es el momento de detectar erratas: repasa que los nombres de clave sean exactamente los de la tabla del apartado 9.

Debe abrirse tu editor con el contenido de ~/.gitconfig. Ciérralo sin guardar. Si se abre Vim en lugar de tu editor, o si el comando devuelve el control instantáneamente sin abrir nada, revisa core.editor y comprueba que incluye la opción de espera (--wait, -w).

Con las siete casillas marcadas, el portátil de Ana está listo.

• Empezar a confirmar sin configurar la identidad. Es el error más costoso del módulo, porque corregir el autor de confirmaciones ya hechas obliga a reescribir el historial. Configura user.name y user.email antes de crear tu primer repositorio.
• Configurar un editor gráfico sin la opción de espera. code en lugar de code --wait hace que Git reciba un mensaje vacío y aborte la operación. El síntoma es "el editor se abre y Git dice que el mensaje está vacío".
• Ignorar los finales de línea hasta que el equipo es mixto. Cuando Carla entra en el proyecto desde Windows sin core.autocrlf, su primera confirmación aparece cambiando el 100 % de las líneas de todos los ficheros. Configúralo desde el principio y, en cuanto haya un proyecto compartido, añade un .gitattributes (módulo 8).
• Usar credential.helper store. Guarda las contraseñas en texto plano en tu carpeta personal. Usa el gestor nativo de tu sistema o, mejor, SSH.
• Escribir la configuración en el nivel local sin querer. Como vimos en la lección anterior, omitir --global escribe en .git/config. Para la identidad y las preferencias personales, el nivel correcto es siempre el global.
• Copiar bloques de configuración de internet sin entenderlos. Aparecen ajustes exóticos que cambian comportamientos importantes y luego producen efectos difíciles de explicar. Añade opciones de una en una, sabiendo qué hace cada una.
• Consejo: revisa la configuración al cambiar de máquina o de empresa. Un portátil corporativo puede traer valores en el nivel de sistema (proxies, gestores de credenciales, plantillas) que no esperas. git config --list --show-origin --show-scope es lo primero que conviene mirar.
• Consejo: versiona tu ~/.gitconfig. Es un fichero de texto pequeño que representa muchos ajustes acumulados. Guardarlo en un repositorio propio te permite replicar tu entorno en cualquier máquina nueva en un minuto.

Aplica en tu máquina la configuración completa recomendada, adaptándola a tu caso:

1. Fija tu identidad con tu nombre real y tu correo.
2. Fija main como rama por defecto.
3. Configura el editor que sepas usar, con la opción de espera si es gráfico.
4. Configura core.autocrlf con el valor correcto para tu sistema operativo.
5. Fija pull.ff only, push.default simple y color.ui auto.
6. Ejecuta las cinco comprobaciones del apartado 10 y anota la salida de cada una.
7. Muestra el contenido resultante de tu ~/.gitconfig y compáralo con el de Ana.

El equipo de gestor-tareas es heterogéneo:

• Ana: Ubuntu, editor VS Code, correo [email protected].
• Bruno: macOS, editor Vim, correo [email protected]. Además quiere que las credenciales HTTPS se guarden en el Llavero del sistema.
• Carla: Windows 11 con Git Bash, editor Notepad++, correo [email protected]. Trabaja también en proyectos de otra empresa que guarda en C:\Users\carla\empresa\ y que deben usar el correo [email protected].

Escribe la secuencia de comandos de configuración para cada uno. Presta especial atención a core.autocrlf en cada sistema y, para Carla, resuelve el caso de los dos correos usando lo aprendido en la lección Configurando Git.

Un compañero recién incorporado se queja de tres problemas distintos y te enseña el resultado de git config --global --list:

Sus quejas son:

1. "Git no me deja hacer commits, dice que no sabe quién soy."
2. "Cuando escribo un mensaje largo, se abre VS Code pero Git dice inmediatamente que el mensaje está vacío."
3. "Al integrar cambios del remoto, mis confirmaciones cambian de identificador y mi compañero dice que le he liado el historial."

Para cada queja: identifica la causa exacta en esa configuración, escribe el comando que la corrige y explica brevemente el porqué. Indica también si hay algo en esa lista que no sea un problema aunque lo parezca.

Solución al Ejercicio 1

Ejemplo de resolución para un usuario en Linux llamado Marta Pons:

El punto 4 es el que más varía: en Windows debe ser true, no input. El punto 3 solo necesita la opción de espera si el editor es gráfico (code --wait, subl -n -w); los editores de terminal como nano o vim bloquean por naturaleza.

Solución al Ejercicio 2

Ana — Ubuntu

Bruno — macOS

core.autocrlf es input igual que en Linux, porque macOS también usa LF. Vim no necesita opción de espera.

Carla — Windows 11

Y para el segundo correo, editando ~/.gitconfig (que en Windows está en C:\Users\carla\.gitconfig) para añadir al final:

Con el fichero ~/.gitconfig-otraempresa:

Tres detalles importantes en la solución de Carla:

• Se usa gitdir/i: en lugar de gitdir: porque el sistema de ficheros de Windows no distingue mayúsculas y la variante insensible evita fallos por diferencias de capitalización en la ruta.
• La ruta se escribe con barras normales (/), no invertidas, aunque sea Windows: Git usa siempre barras normales en sus ficheros de configuración.
• La ruta termina en /, requisito para que la coincidencia sea recursiva.

Comprobación desde cualquier repositorio de C:\Users\carla\empresa\:

Solución al Ejercicio 3

Queja 1 — "no sabe quién soy"

• Causa: la clave está mal escrita. Dice user.emial en lugar de user.email. Como Git no valida los nombres de clave, la guardó sin protestar y user.email sigue sin estar definido.
• Corrección:

Queja 2 — "el mensaje está vacío"

• Causa: core.editor=code no lleva la opción --wait. VS Code se abre y devuelve el control a Git de inmediato, así que Git lee el fichero de mensaje antes de que se haya escrito nada y aborta por mensaje vacío.
• Corrección:

Queja 3 — "le he liado el historial"

• Causa: pull.rebase=true reaplica las confirmaciones locales sobre las descargadas, lo que crea confirmaciones nuevas con hash distinto, como vimos en El Modelo de Datos de Git. Si esas confirmaciones ya estaban compartidas, el compañero se encuentra con historiales divergentes. No es un valor "incorrecto" en sí —muchos equipos lo usan deliberadamente— pero no es apropiado para alguien que empieza y no distingue todavía cuándo es seguro.
• Corrección para un principiante:

Así, si al integrar aparece divergencia, Git se detiene y avisa en lugar de reescribir nada. Cuando el compañero llegue al módulo 5 podrá volver a activar el rebase con criterio.

Lo que NO es un problema: la línea init.defaultbranch=main. Las claves de configuración no distinguen mayúsculas en la sección ni en el nombre, así que init.defaultbranch e init.defaultBranch son exactamente la misma clave. De hecho, Git normaliza el nombre a minúsculas al listar la configuración, así que esa línea aparecerá así aunque se escribiera con la mayúscula. Funciona perfectamente.

El portátil de Ana está listo. Hemos fijado los dos valores obligatorios —user.name y user.email, que identifican al autor en cada confirmación y que conviene acertar antes de la primera, porque corregirlos después obliga a reescribir el historial— y una docena de ajustes muy recomendables: init.defaultBranch=main para alinearse con el estándar del sector, core.editor para no quedar atrapado en un editor desconocido, core.autocrlf para que un equipo con Linux, macOS y Windows no genere cambios falsos en cada fichero, pull.ff only para que Git nunca integre de forma inesperada, push.default y push.autoSetupRemote para que enviar cambios sea predecible, un gestor de credenciales seguro y el color de la salida.

Con esto cerramos el módulo 1. En estas seis lecciones hemos recorrido el camino completo desde el desconocimiento hasta un entorno preparado:

• Por qué existe Git y qué lo diferencia de los sistemas centralizados, con gestor-tareas como proyecto guía.
• Cómo instalarlo en Linux, macOS y Windows, y por qué usaremos la línea de comandos.
• El vocabulario: tres zonas, tres estados, referencias, remotos, fusión y rebase.
• El modelo de datos: blobs, árboles, commits y etiquetas enlazados por hash, y la inmutabilidad que de ahí se deriva.
• El mecanismo de configuración: tres niveles, precedencia y perfiles condicionales.
• Los valores concretos que dejan el equipo listo para trabajar.

Sabes qué es Git, lo tienes instalado, entiendes cómo guarda la información y está configurado a tu medida. Solo falta usarlo.

En el módulo 2: Operaciones Básicas de Git empieza el trabajo real. Ana convertirá por fin su carpeta gestor-tareas en un repositorio con Creando un Repositorio, aprenderemos a clonar uno existente, recorreremos el flujo de trabajo básico que conecta las tres zonas que ya conoces, y practicaremos a fondo cómo preparar y confirmar cambios, inspeccionar diferencias y leer el historial. Todo lo que has aprendido aquí sobre las tres zonas, los objetos y las referencias empezará a verse en acción.