En la lección 02-06 aprendimos a movernos por el historial: git log con sus formatos, sus filtros por autor y fecha, y la búsqueda con -S y -G. Aquello era suficiente para un proyecto de una sola rama y unos pocos commits.

Ahora gestor-tareas tiene ocho meses, cuatro ramas activas, fusiones, etiquetas de versión y tres personas trabajando. Y las preguntas que se hace el equipo han cambiado de naturaleza:

• ¿Qué forma tiene el historial? ¿Qué se ha fusionado en main este mes?
• ¿Qué hay en la rama de Carla que no esté en main, y al revés?
• ¿Quién ha contribuido qué, y cuánto?
• ¿Cuáles son los hitos —etiquetas y fusiones— sin el ruido de los commits intermedios?

Y hay un segundo problema, más prosaico pero igual de real. La invocación de la lección anterior era git blame -w -C --date=short -L :normalizarTexto:app.js app.js. Nadie escribe eso dos veces. La segunda mitad de la lección va de eso: convertir los comandos largos que usas a diario en palabras cortas, con los alias de Git.

1. --graph: ver la forma del historial
2. --first-parent: la línea principal, sin ruido
3. --simplify-by-decoration: solo los hitos
4. --merges y --no-merges
5. Rangos de tres puntos y --left-right
6. --pretty=format: avanzado: colores y alineación
7. git shortlog: quién ha contribuido qué
8. Componiendo consultas con lo aprendido
9. Alias: qué son y dónde viven
10. Alias con !: shell y funciones
11. Un juego de alias para el día a día
12. Riesgos y buenas prácticas con los alias

git log por defecto da una lista plana ordenada por fecha, que en un historial con ramas es engañosa: no se ve qué venía de dónde. --graph dibuja el DAG (lección 03-01) con caracteres ASCII a la izquierda.

Los tres modificadores son inseparables en la práctica:

Cómo leer el dibujo:

• Cada * es un commit. La columna en la que está indica su "carril".
• |\ marca un commit de fusión: dos líneas entran en él.
• |/ marca el punto en el que dos carriles se unen hacia atrás: el ancestro común.
• La rama correccion/borrado-svg aparece colgando de 3f1a8d6 sin haberse fusionado: son commits que existen solo en esa rama.

Un detalle sobre --decorate: desde Git 2.13 está activo por defecto cuando la salida va a un terminal (--decorate=auto), así que a menudo no hace falta escribirlo. Se puede fijar con:

Y variantes de --all que evitan el ruido de decenas de ramas remotas antiguas:

Ya apareció en la lección 06-02 con bisect, y en la 05-06 al elegir -m 1. La idea es la misma: en un commit de fusión, el primer padre es la rama en la que estabas (normalmente main) y el segundo es la que trajiste.

Compáralo con el --graph del apartado anterior: han desaparecido 4e8b2c9 y 2c6e9a4, que eran los commits dentro de la rama fusionada. Lo que queda es la historia de main a nivel de integraciones: cada línea es o un commit directo o "aquí entró una funcionalidad entera".

Es la vista correcta para:

• Redactar las notas de una versión.
• Responder a "¿qué ha entrado en main esta semana?".
• Contar cuántas funcionalidades se integraron en un periodo.

Esta opción es poco conocida y muy útil. Muestra únicamente los commits que tienen una referencia apuntándoles (una rama, una etiqueta o HEAD), más los mínimos necesarios para mantener el grafo conectado.

Cuatrocientos commits reducidos a cinco líneas: el esqueleto del proyecto. Es lo primero que conviene ejecutar al llegar a un repositorio desconocido, porque en diez segundos te da el mapa: qué versiones hay, qué ramas están vivas y dónde nacieron.

Combinaciones útiles:

Dos filtros complementarios y directos:

--no-merges es especialmente importante para las estadísticas: si cuentas commits por autor sin él, quien más fusiona parece el más productivo.

De la lección 02-06 recordamos A..B: "los commits alcanzables desde B pero no desde A". Es asimétrico y responde a "¿qué le falta a A de B?".

El triple punto A...B es la diferencia simétrica: los commits que están en uno u otro, pero no en ambos. Responde a "¿en qué se han separado estas dos ramas?".

Con A...B a secas no se sabe qué commit es de cuál lado. Para eso está --left-right:

Es la vista perfecta antes de fusionar o rebasar: de un vistazo ves cuánto se ha movido cada lado. Y con el remoto:

Dos commits por delante en main, dos en la rama. Ese rev-list --count es, por cierto, lo que hay detrás del [ahead 2, behind 2] de git status y git branch -vv.

Un añadido útil: --cherry-mark marca con = los commits que son equivalentes a uno del otro lado (mismo cambio, distinto hash) —lo que veíamos con git cherry en la lección 05-03:

En la lección 02-06 vimos los marcadores básicos de --pretty=format:. Ahora vamos a los dos grupos que convierten una salida legible en una salida excelente: colores y alineación.

%C(auto) es el que hay que usar por defecto, y hay una razón concreta: aplicado a %d (las decoraciones), pinta cada referencia con su color canónico —HEAD en cian, las ramas locales en verde, las remotas en rojo, las etiquetas en amarillo— exactamente como hace git log --decorate sin formato personalizado. Escribir eso a mano es imposible.

Además, %C(auto) respeta la configuración color.ui: si rediriges la salida a un fichero o a grep, los códigos de escape no se emiten y el fichero queda limpio.

Cuando el formato tiene varias columnas, sin alineación queda un desastre visual. Los marcadores de relleno lo resuelven:

El formato completo que usa el equipo:

Desglose pieza a pieza:

• %C(auto)%h → hash abreviado, con el color estándar de Git para hashes.
• %C(blue)%<(16,trunc)%an%C(reset) → autor en azul, exactamente 16 columnas, truncado si no cabe.
• %C(green)%<(12)%ar%C(reset) → fecha relativa ("hace 2 días") en verde, 12 columnas.
• %C(auto)%d%C(reset) → las decoraciones, cada una con su color canónico.
• %s → el asunto, que ocupa el resto.

El resultado es tabular, legible y compacto. En el apartado 11 lo convertiremos en un alias.

Un recordatorio de los marcadores más usados, para no volver a la lección 02-06:

Y para no repetir el formato cada vez, se puede guardar con nombre en la configuración:

git shortlog agrupa los commits por autor. Sin argumentos, lista los mensajes agrupados; con -s (summary) y -n (numbered), da el recuento ordenado:

Opciones útiles:

Esa última salida es, literalmente, un borrador de notas de versión.

Dos advertencias importantes, porque shortlog se malinterpreta con facilidad:

• El número de commits no mide productividad. Un commit puede ser una coma o una funcionalidad entera. Como métrica de rendimiento es peor que inútil: es perversa, porque premia trocear artificialmente.
• Una misma persona puede aparecer varias veces si ha usado distintos nombres o correos (portátil personal, servidor, plataforma web). Se unifica con un fichero .mailmap en la raíz del repositorio:

Git lo aplica automáticamente en shortlog, log y blame.

Todo lo anterior se combina, y ahí está la potencia real. Algunos ejemplos que resuelven preguntas concretas del día a día de gestor-tareas:

--ancestry-path restringe el rango a los commits que están en el camino entre los dos extremos, lo cual es exactamente lo que quieres para responder "¿cómo llegó ese commit hasta main?".

Y una comparación de las tres vistas del historial que hemos visto, para tenerlas juntas:

Llegados aquí, el problema es evidente: ninguno de estos comandos se escribe a mano dos veces.

Un alias de Git es un nombre corto para un comando largo. Se define con git config:

A partir de ahí, git st es git status. Git resuelve el alias antes de ejecutar y le pasa los argumentos extra:

Dónde viven. En el .gitconfig correspondiente al nivel elegido (lección 01-05), bajo la sección [alias]:

Se pueden editar a mano en el fichero —que es más cómodo para los alias largos— o con git config. Y consultarlos:

Los tres niveles funcionan igual que para el resto de la configuración: --system, --global y local. Los alias personales van en --global; un alias específico de un proyecto, en el local. Y recuerda que la configuración no se clona: los alias son tuyos, no del repositorio.

Dos reglas que evitan sorpresas:

• Un alias no puede sobrescribir un comando existente. Si defines alias.status, Git ignorará el alias y ejecutará el comando real. Es una protección deliberada.
• Los alias pueden encadenarse, pero con cuidado: un alias que invoca a otro funciona, y un alias recursivo cuelga Git.

Un alias normal solo puede empezar por un subcomando de Git. Para todo lo demás —encadenar comandos, usar tuberías, invocar programas externos, colocar los argumentos en un sitio distinto del final— se antepone !, que le dice a Git: "esto es una orden de shell, ejecútala tal cual".

Tres cosas fundamentales sobre los alias con !:

Este es el riesgo principal y la fuente número uno de sorpresas. Git hace cd a la raíz del árbol de trabajo antes de ejecutar el alias. Así que si estás en ~/proyectos/gestor-tareas/componentes/ y ejecutas un alias con !ls, verás el contenido de ~/proyectos/gestor-tareas/, no el del directorio en el que estás.

Git da una variable para paliarlo:

GIT_PREFIX contiene la ruta relativa desde la raíz hasta el directorio en el que estabas al invocar el alias (vacía si ya estabas en la raíz). Cualquier alias con ! que trabaje con rutas relativas debe tenerlo en cuenta:

Git pega los argumentos que escribas al final del comando del alias. Eso es un problema cuando los necesitas en medio:

En este caso funciona por casualidad. Pero si el argumento va en medio, no:

La solución canónica es definir una función de shell y llamarla:

El patrón '!f() { ...; }; f' se lee así: define una función llamada f, y a continuación invócala. Los argumentos que Git pega al final se convierten en los argumentos de f. Es el idioma estándar y lo verás en todos los .gitconfig del mundo.

Usa "$@" para pasar todos los argumentos y "$1", "$2" para posiciones concretas. Y comíllalo siempre: sin comillas, un nombre de rama con caracteres raros rompe el alias.

Git usa /bin/sh. En muchos sistemas eso es dash, no bash, y las extensiones de bash ([[ ]], arrays, mapfile) no funcionan. Escribe alias en shell POSIX o invoca explícitamente el intérprete:

Para cualquier cosa que pase de tres líneas, la respuesta correcta no es un alias sino un script en el PATH. Git tiene una convención preciosa para eso: cualquier ejecutable llamado git-<algo> que esté en el PATH se puede invocar como git <algo>:

Sin configurar nada. Es la vía correcta para la lógica compleja, y de paso el script se puede versionar y compartir.

Estos son los que de verdad se ganan el sitio. Empezando por el clásico absoluto:

El lg es probablemente el alias más copiado de la historia de Git, y con razón: sustituye a un comando de 180 caracteres que nadie recuerda.

La tabla completa del juego recomendado:

Ese último es más útil de lo que parece: a los seis meses nadie recuerda todos sus alias.

Para instalarlos de golpe, es más cómodo editar el fichero que lanzar veinte git config:

Fíjate en el escapado: en el fichero, los valores con comillas o barras invertidas van entre comillas dobles y con las barras duplicadas. Es la parte más molesta de los alias con !, y la razón por la que conviene probarlos justo después de escribirlos.

Y esto conecta con los módulos anteriores: los alias no son solo para log. pendiente usa @{u} de la lección 04-06; enmendar es el --amend de la 02-04; limpiar es la gestión de ramas de la 03-06; culpa es el blame de la 06-03. Un alias es la forma de fijar en un gesto lo que has aprendido a hacer bien, para no tener que recordar las siete opciones cada vez.

Riesgo 1: el directorio de ejecución. Ya visto: los alias con ! se ejecutan desde la raíz del repositorio. Usa GIT_PREFIX si el alias trabaja con rutas.

Riesgo 2: alias destructivos con nombres cortos. Un git p que haga push --force es un accidente esperando a ocurrir. Regla: cuanto más destructivo, más largo el nombre. Y en el caso de push --force, usa siempre --force-with-lease (lección 04-05).

Riesgo 3: dependencia de tu máquina. Tus alias no están en el portátil del compañero al que pides ayuda, ni en el servidor. Conviene saber el comando real que hay detrás de cada uno.

Riesgo 4: sh no es bash. Las extensiones de bash fallan silenciosamente o con errores raros.

Riesgo 5: alias que ocultan efectos. Un git sync que haga fetch + rebase + push está bien hasta el día que hay conflictos y no entiendes en qué punto se ha quedado el proceso.

Buenas prácticas:

• Que el nombre diga qué hace. pendiente es mejor que p.
• Versiona tu .gitconfig. Muchos guardan sus dotfiles en un repositorio propio: los alias son configuración valiosa y cuesta rehacerlos.
• Añade alias poco a poco. Cuando notes que escribes lo mismo por tercera vez, ahí tienes un candidato. Copiar una lista de cuarenta alias de internet garantiza no usar ninguno.
• Prueba el alias nada más crearlo, especialmente los que llevan ! y comillas.
• Para lógica compleja, git-<nombre> en el PATH, no un alias de tres líneas.

Error 1: --graph sin --oneline. El grafo con mensajes completos es ilegible. Van siempre juntos.

Error 2: olvidar --all y creer que la rama no existe. git log --graph solo muestra la rama actual. Sin --all, no ves las demás.

Error 3: confundir .. con .... A..B es asimétrico ("lo que le falta a A"); A...B es simétrico ("en qué se han separado"). Con --left-right la ambigüedad desaparece.

Error 4: contar commits con shortlog sin --no-merges. Quien más integra parece el que más produce.

Error 5: usar el recuento de commits como métrica de rendimiento. Es una mala métrica y crea incentivos perversos.

Error 6: alias con ! que asume el directorio actual. Se ejecuta desde la raíz. GIT_PREFIX.

Error 7: argumentos en medio de un alias sin usar función. Git los pega al final. El patrón '!f() { ...; }; f' es la solución.

Error 8: escapado mal hecho en el .gitconfig. Comillas dobles alrededor del valor y barras invertidas duplicadas. Prueba el alias inmediatamente.

Consejo 1: %C(auto) por defecto en tus formatos. Colorea las decoraciones correctamente y respeta la configuración y las redirecciones.

Consejo 2: guarda formatos con nombre. git config --global pretty.tabla '...' y después git log --pretty=tabla.

Consejo 3: --simplify-by-decoration al llegar a un repositorio nuevo. Diez segundos para el mapa completo.

Consejo 4: git rev-list --count A...B para el recuento puro. Cuando solo quieres saber cuánto, no qué.

Consejo 5: un .mailmap en cuanto alguien aparezca duplicado. Es un fichero de tres líneas que arregla shortlog, log y blame a la vez.

Crea un repositorio con esta topología: cuatro commits en main, una rama funcionalidad/a con dos commits fusionada con --no-ff, una rama funcionalidad/b con dos commits sin fusionar, y una etiqueta v1.0 en el segundo commit de main. Después:

1. Muestra el grafo completo con --graph --oneline --decorate --all.
2. Muestra solo la línea principal con --first-parent.
3. Muestra solo los hitos con --simplify-by-decoration --all.
4. Muestra solo las fusiones, y después solo los commits que no lo son.
5. Explica qué commits desaparecen en cada vista y por qué.

Sobre el mismo repositorio:

1. Añade dos commits más a main y dos más a funcionalidad/b.
2. Usa main..funcionalidad/b y funcionalidad/b..main, y explica la diferencia.
3. Usa main...funcionalidad/b con --left-right e identifica cada lado.
4. Obtén el recuento con git rev-list --left-right --count.
5. Crea un formato --pretty con colores y alineación que muestre hash, autor (14 columnas truncadas), fecha corta y asunto.

1. Crea los alias lg, quien, pendiente y culpa de la tabla del apartado 11.
2. Crea un alias historia que acepte dos argumentos (función y fichero) y ejecute git log -L. Pruébalo.
3. Crea un alias que demuestre el problema de GIT_PREFIX: uno que ejecute ls sin más, y otro que lo haga bien. Ejecútalos desde un subdirectorio y compara.
4. Lista todos tus alias con un alias.

Solución 1:

Han desaparecido 2a8c6f9 y 7d3e1b5: son los commits dentro de funcionalidad/a, a los que solo se llega por el segundo padre de la fusión.

Solo los commits con referencia y lo mínimo para conectarlos: el esqueleto.

Solución 2:

Lo que tiene la rama y no tiene main: lo que entraría al fusionar.

Lo que le falta a la rama de main: lo que traería al rebasar o fusionar main en ella.

Solución 3:

El alias con argumentos:

El problema de GIT_PREFIX:

Ha listado la raíz del repositorio, no el directorio en el que estamos.

Con GIT_PREFIX, el alias respeta el directorio desde el que se invocó.

Esta lección ha convertido git log de un listado en una herramienta de consulta, y ha eliminado la fricción de usarla. Lo esencial:

• --graph --oneline --decorate --all es la vista canónica de la topología. Los cuatro van juntos.
• --first-parent da la historia de main a nivel de integraciones, sin el interior de las ramas fusionadas. Es el mismo "primer padre" del -m 1 de revert y del bisect --first-parent.
• --simplify-by-decoration reduce el historial a sus hitos: lo primero que ejecutar en un repositorio desconocido.
• --merges / --no-merges separan integraciones de trabajo real; --no-merges es casi obligatorio en cualquier estadística.
• A...B con --left-right responde a "¿en qué se han separado estas dos ramas?", con < y > marcando cada lado. git rev-list --left-right --count da solo el recuento.
• --pretty=format: con %C(auto) y los marcadores de alineación %<(N,trunc) produce salidas tabulares y coloreadas; guárdalos con nombre en pretty.<nombre>.
• git shortlog -sn --no-merges resume las contribuciones, con .mailmap para unificar identidades — y con la advertencia de que contar commits no mide nada útil.
• Los alias viven en [alias] del .gitconfig del nivel que elijas. Los simples son un nombre para un subcomando; los que empiezan por ! son shell, con tres cautelas: se ejecutan desde la raíz (usa GIT_PREFIX), los argumentos se pegan al final (usa el patrón '!f() { ...; }; f') y corren bajo sh, no bash.
• Para lógica larga, un ejecutable git-<nombre> en el PATH es mejor que un alias.
• Y la idea de fondo: un alias fija en un gesto lo que has aprendido a hacer bien. culpa, pendiente, hitos o limpiar son las lecciones anteriores condensadas en una palabra.

El equipo ya sabe interrogar su historial con comodidad. Pero gestor-tareas está a punto de dejar de ser un solo repositorio: los botones, los diálogos y los campos de formulario que Ana ha ido extrayendo se han convertido en una biblioteca interna, componentes-ui, que vive en git.ejemplo.es/equipo/componentes-ui.git y que otros dos proyectos de la empresa también quieren usar.

La pregunta es cómo se compone un proyecto a partir de varios repositorios sin copiar y pegar código, y sin perder la trazabilidad de qué versión de la biblioteca usa cada versión de la aplicación. La respuesta nativa de Git son los submódulos, y es la lección 06-05: Submódulos de Git.