A la lliçó 02-06 vam aprendre a moure'ns per l'historial: git log amb els seus formats, els seus filtres per autor i data, i la cerca amb -S i -G. Allò era suficient per a un projecte d'una sola branca i uns quants commits.

Ara gestor-tasques té vuit mesos, quatre branques actives, fusions, etiquetes de versió i tres persones treballant-hi. I les preguntes que es fa l'equip han canviat de naturalesa:

• Quina forma té l'historial? Què s'ha fusionat a main aquest mes?
• Què hi ha a la branca de la Carla que no sigui a main, i a l'inrevés?
• Qui ha aportat què, i quant?
• Quines són les fites —etiquetes i fusions— sense el soroll dels commits intermedis?

I hi ha un segon problema, més prosaic però igual de real. La invocació de la lliçó anterior era git blame -w -C --date=short -L :normalitzaText:app.js app.js. Ningú escriu això dues vegades. La segona meitat de la lliçó va d'això: convertir les ordres llargues que fas servir cada dia en paraules curtes, amb els àlies de Git.

1. --graph: veure la forma de l'historial
2. --first-parent: la línia principal, sense soroll
3. --simplify-by-decoration: només les fites
4. --merges i --no-merges
5. Rangs de tres punts i --left-right
6. --pretty=format: avançat: colors i alineació
7. git shortlog: qui ha aportat què
8. Component consultes amb el que hem après
9. Àlies: què són i on viuen
10. Àlies amb !: shell i funcions
11. Un joc d'àlies per al dia a dia
12. Riscos i bones pràctiques amb els àlies

git log per defecte dona una llista plana ordenada per data, que en un historial amb branques és enganyosa: no es veu què venia d'on. --graph dibuixa el DAG (lliçó 03-01) amb caràcters ASCII a l'esquerra.

Els tres modificadors són inseparables a la pràctica:

Com llegir el dibuix:

• Cada * és un commit. La columna en què es troba indica el seu "carril".
• |\ marca un commit de fusió: hi entren dues línies.
• |/ marca el punt en què dos carrils s'uneixen cap enrere: l'ancestre comú.
• La branca correccio/esborrat-svg apareix penjant de 3f1a8d6 sense haver-se fusionat: són commits que existeixen només en aquella branca.

Un detall sobre --decorate: des de Git 2.13 està actiu per defecte quan la sortida va a un terminal (--decorate=auto), així que sovint no cal escriure'l. Es pot fixar amb:

I variants de --all que eviten el soroll de desenes de branques remotes antigues:

Ja va aparèixer a la lliçó 06-02 amb bisect, i a la 05-06 en triar -m 1. La idea és la mateixa: en un commit de fusió, el primer pare és la branca en què eres (normalment main) i el segon és la que vas portar.

Compara-ho amb el --graph de l'apartat anterior: han desaparegut 4e8b2c9 i 2c6e9a4, que eren els commits dins de la branca fusionada. El que queda és la història de main a nivell d'integracions: cada línia és o un commit directe o "aquí va entrar una funcionalitat sencera".

És la vista correcta per a:

• Redactar les notes d'una versió.
• Respondre a "què ha entrat a main aquesta setmana?".
• Comptar quantes funcionalitats es van integrar en un període.

Aquesta opció és poc coneguda i molt útil. Mostra únicament els commits que tenen una referència apuntant-los (una branca, una etiqueta o HEAD), més els mínims necessaris per mantenir el graf connectat.

Quatre-cents commits reduïts a cinc línies: l'esquelet del projecte. És el primer que convé executar en arribar a un repositori desconegut, perquè en deu segons et dona el mapa: quines versions hi ha, quines branques són vives i on van néixer.

Combinacions útils:

Dos filtres complementaris i directes:

--no-merges és especialment important per a les estadístiques: si comptes commits per autor sense aquesta opció, qui més fusiona sembla el més productiu.

De la lliçó 02-06 recordem A..B: "els commits assolibles des de B però no des d'A". És asimètric i respon a "què li falta a A de B?".

El triple punt A...B és la diferència simètrica: els commits que són en un o altre, però no en tots dos. Respon a "en què s'han separat aquestes dues branques?".

Amb A...B tot sol no se sap quin commit és de quin costat. Per a això hi ha --left-right:

És la vista perfecta abans de fusionar o rebasar: d'un cop d'ull veus quant s'ha mogut cada costat. I amb el remot:

Dos commits per davant a main, dos a la branca. Aquest rev-list --count és, per cert, el que hi ha darrere del [ahead 2, behind 2] de git status i git branch -vv.

Un afegit útil: --cherry-mark marca amb = els commits que són equivalents a un de l'altre costat (mateix canvi, hash diferent) —el que vèiem amb git cherry a la lliçó 05-03:

A la lliçó 02-06 vam veure els marcadors bàsics de --pretty=format:. Ara anem als dos grups que converteixen una sortida llegible en una sortida excel·lent: colors i alineació.

%C(auto) és el que cal fer servir per defecte, i hi ha una raó concreta: aplicat a %d (les decoracions), pinta cada referència amb el seu color canònic —HEAD en cian, les branques locals en verd, les remotes en vermell, les etiquetes en groc— exactament com fa git log --decorate sense format personalitzat. Escriure això a mà és impossible.

A més, %C(auto) respecta la configuració color.ui: si rediriges la sortida a un fitxer o a grep, els codis d'escapament no s'emeten i el fitxer queda net.

Quan el format té diverses columnes, sense alineació queda un desastre visual. Els marcadors d'emplenament ho resolen:

El format complet que fa servir l'equip:

Desglossament peça a peça:

• %C(auto)%h → hash abreujat, amb el color estàndard de Git per als hashos.
• %C(blue)%<(16,trunc)%an%C(reset) → autor en blau, exactament 16 columnes, truncat si no hi cap.
• %C(green)%<(12)%ar%C(reset) → data relativa ("fa 2 dies") en verd, 12 columnes.
• %C(auto)%d%C(reset) → les decoracions, cadascuna amb el seu color canònic.
• %s → l'assumpte, que ocupa la resta.

El resultat és tabular, llegible i compacte. A l'apartat 11 el convertirem en un àlies.

Un recordatori dels marcadors més usats, per no haver de tornar a la lliçó 02-06:

I per no repetir el format cada vegada, es pot desar amb nom a la configuració:

git shortlog agrupa els commits per autor. Sense arguments, llista els missatges agrupats; amb -s (summary) i -n (numbered), dona el recompte ordenat:

Opcions útils:

Aquesta última sortida és, literalment, un esborrany de notes de versió.

Dos advertiments importants, perquè shortlog es malinterpreta amb facilitat:

• El nombre de commits no mesura la productivitat. Un commit pot ser una coma o una funcionalitat sencera. Com a mètrica de rendiment és pitjor que inútil: és perversa, perquè premia trossejar artificialment.
• Una mateixa persona pot aparèixer diverses vegades si ha fet servir noms o correus diferents (portàtil personal, servidor, plataforma web). S'unifica amb un fitxer .mailmap a l'arrel del repositori:

Git l'aplica automàticament a shortlog, log i blame.

Tot l'anterior es combina, i aquí hi ha la potència real. Alguns exemples que resolen preguntes concretes del dia a dia de gestor-tasques:

--ancestry-path restringeix el rang als commits que són en el camí entre els dos extrems, que és exactament el que vols per respondre "com va arribar aquell commit fins a main?".

I una comparació de les tres vistes de l'historial que hem vist, per tenir-les juntes:

Arribats aquí, el problema és evident: cap d'aquestes ordres no s'escriu a mà dues vegades.

Un àlies de Git és un nom curt per a una ordre llarga. Es defineix amb git config:

A partir d'aquí, git st és git status. Git resol l'àlies abans d'executar i li passa els arguments extra:

On viuen. Al .gitconfig corresponent al nivell triat (lliçó 01-05), sota la secció [alias]:

Es poden editar a mà al fitxer —que és més còmode per als àlies llargs— o amb git config. I consultar-los:

Els tres nivells funcionen igual que per a la resta de la configuració: --system, --global i local. Els àlies personals van a --global; un àlies específic d'un projecte, al local. I recorda que la configuració no es clona: els àlies són teus, no del repositori.

Dues regles que eviten sorpreses:

• Un àlies no pot sobreescriure una ordre existent. Si defineixes alias.status, Git ignorarà l'àlies i executarà l'ordre real. És una protecció deliberada.
• Els àlies es poden encadenar, però amb compte: un àlies que n'invoca un altre funciona, i un àlies recursiu penja Git.

Un àlies normal només pot començar per una subordre de Git. Per a tota la resta —encadenar ordres, fer servir canonades, invocar programes externs, col·locar els arguments en un lloc diferent del final— s'anteposa !, que li diu a Git: "això és una ordre de shell, executa-la tal com és".

Tres coses fonamentals sobre els àlies amb !:

Aquest és el risc principal i la font número u de sorpreses. Git fa cd a l'arrel de l'arbre de treball abans d'executar l'àlies. Així que si ets a ~/projectes/gestor-tasques/components/ i executes un àlies amb !ls, veuràs el contingut de ~/projectes/gestor-tasques/, no el del directori en què ets.

Git dona una variable per pal·liar-ho:

GIT_PREFIX conté la ruta relativa des de l'arrel fins al directori en què eres en invocar l'àlies (buida si ja eres a l'arrel). Qualsevol àlies amb ! que treballi amb rutes relatives ha de tenir-ho en compte:

Git enganxa els arguments que escriguis al final de l'ordre de l'àlies. Això és un problema quan els necessites al mig:

En aquest cas funciona per casualitat. Però si l'argument va al mig, no:

La solució canònica és definir una funció de shell i cridar-la:

El patró '!f() { ...; }; f' es llegeix així: defineix una funció anomenada f, i tot seguit invoca-la. Els arguments que Git enganxa al final es converteixen en els arguments d'f. És l'idioma estàndard i el veuràs a tots els .gitconfig del món.

Fes servir "$@" per passar tots els arguments i "$1", "$2" per a posicions concretes. I posa-hi cometes sempre: sense cometes, un nom de branca amb caràcters estranys trenca l'àlies.

Git fa servir /bin/sh. En molts sistemes això és dash, no bash, i les extensions de bash ([[ ]], arrays, mapfile) no funcionen. Escriu àlies en shell POSIX o invoca explícitament l'intèrpret:

Per a qualsevol cosa que passi de tres línies, la resposta correcta no és un àlies sinó un script al PATH. Git té una convenció preciosa per a això: qualsevol executable anomenat git-<alguna-cosa> que sigui al PATH es pot invocar com git <alguna-cosa>:

Sense configurar res. És la via correcta per a la lògica complexa, i de passada l'script es pot versionar i compartir.

Aquests són els que de debò es guanyen el lloc. Començant pel clàssic absolut:

El lg és probablement l'àlies més copiat de la història de Git, i amb raó: substitueix una ordre de 180 caràcters que ningú recorda.

La taula completa del joc recomanat:

Aquest últim és més útil del que sembla: al cap de sis mesos ningú recorda tots els seus àlies.

Per instal·lar-los de cop, és més còmode editar el fitxer que llançar vint git config:

Fixa't en l'escapament: al fitxer, els valors amb cometes o barres invertides van entre cometes dobles i amb les barres duplicades. És la part més molesta dels àlies amb !, i la raó per la qual convé provar-los just després d'escriure'ls.

I això connecta amb els mòduls anteriors: els àlies no són només per a log. pendent fa servir @{u} de la lliçó 04-06; esmena és el --amend de la 02-04; neteja és la gestió de branques de la 03-06; culpa és el blame de la 06-03. Un àlies és la manera de fixar en un gest el que has après a fer bé, per no haver de recordar les set opcions cada vegada.

Risc 1: el directori d'execució. Ja vist: els àlies amb ! s'executen des de l'arrel del repositori. Fes servir GIT_PREFIX si l'àlies treballa amb rutes.

Risc 2: àlies destructius amb noms curts. Un git p que faci push --force és un accident esperant a passar. Regla: com més destructiu, més llarg el nom. I en el cas de push --force, fes servir sempre --force-with-lease (lliçó 04-05).

Risc 3: dependència de la teva màquina. Els teus àlies no són al portàtil del company a qui demanes ajuda, ni al servidor. Convé saber l'ordre real que hi ha al darrere de cadascun.

Risc 4: sh no és bash. Les extensions de bash fallen silenciosament o amb errors estranys.

Risc 5: àlies que amaguen efectes. Un git sync que faci fetch + rebase + push va bé fins al dia que hi ha conflictes i no entens en quin punt s'ha quedat el procés.

Bones pràctiques:

• Que el nom digui què fa. pendent és millor que p.
• Versiona el teu .gitconfig. Molts guarden els seus dotfiles en un repositori propi: els àlies són configuració valuosa i costa refer-los.
• Afegeix àlies a poc a poc. Quan notis que escrius el mateix per tercera vegada, allà tens un candidat. Copiar una llista de quaranta àlies d'internet garanteix no fer-ne servir cap.
• Prova l'àlies tot just crear-lo, especialment els que porten ! i cometes.
• Per a lògica complexa, git-<nom> al PATH, no un àlies de tres línies.

Error 1: --graph sense --oneline. El graf amb missatges complets és il·legible. Van sempre junts.

Error 2: oblidar --all i creure que la branca no existeix. git log --graph només mostra la branca actual. Sense --all, no veus les altres.

Error 3: confondre .. amb .... A..B és asimètric ("el que li falta a A"); A...B és simètric ("en què s'han separat"). Amb --left-right l'ambigüitat desapareix.

Error 4: comptar commits amb shortlog sense --no-merges. Qui més integra sembla qui més produeix.

Error 5: fer servir el recompte de commits com a mètrica de rendiment. És una mala mètrica i crea incentius perversos.

Error 6: àlies amb ! que assumeix el directori actual. S'executa des de l'arrel. GIT_PREFIX.

Error 7: arguments al mig d'un àlies sense fer servir una funció. Git els enganxa al final. El patró '!f() { ...; }; f' és la solució.

Error 8: escapament mal fet al .gitconfig. Cometes dobles al voltant del valor i barres invertides duplicades. Prova l'àlies immediatament.

Consell 1: %C(auto) per defecte als teus formats. Acoloreix les decoracions correctament i respecta la configuració i les redireccions.

Consell 2: desa formats amb nom. git config --global pretty.taula '...' i després git log --pretty=taula.

Consell 3: --simplify-by-decoration en arribar a un repositori nou. Deu segons per al mapa complet.

Consell 4: git rev-list --count A...B per al recompte pur. Quan només vols saber quant, no què.

Consell 5: un .mailmap tan bon punt algú aparegui duplicat. És un fitxer de tres línies que arregla shortlog, log i blame alhora.

Crea un repositori amb aquesta topologia: quatre commits a main, una branca funcionalitat/a amb dos commits fusionada amb --no-ff, una branca funcionalitat/b amb dos commits sense fusionar, i una etiqueta v1.0 al segon commit de main. Després:

1. Mostra el graf complet amb --graph --oneline --decorate --all.
2. Mostra només la línia principal amb --first-parent.
3. Mostra només les fites amb --simplify-by-decoration --all.
4. Mostra només les fusions, i després només els commits que no ho són.
5. Explica quins commits desapareixen en cada vista i per què.

Sobre el mateix repositori:

1. Afegeix dos commits més a main i dos més a funcionalitat/b.
2. Fes servir main..funcionalitat/b i funcionalitat/b..main, i explica la diferència.
3. Fes servir main...funcionalitat/b amb --left-right i identifica cada costat.
4. Obtén el recompte amb git rev-list --left-right --count.
5. Crea un format --pretty amb colors i alineació que mostri hash, autor (14 columnes truncades), data curta i assumpte.

1. Crea els àlies lg, qui, pendent i culpa de la taula de l'apartat 11.
2. Crea un àlies historia que accepti dos arguments (funció i fitxer) i executi git log -L. Prova'l.
3. Crea un àlies que demostri el problema de GIT_PREFIX: un que executi ls sense més, i un altre que ho faci bé. Executa'ls des d'un subdirectori i compara.
4. Llista tots els teus àlies amb un àlies.

Solució 1:

Han desaparegut 2a8c6f9 i 7d3e1b5: són els commits dins de funcionalitat/a, als quals només s'arriba pel segon pare de la fusió.

Només els commits amb referència i el mínim per connectar-los: l'esquelet.

Solució 2:

El que té la branca i no té main: el que entraria en fusionar.

El que li falta a la branca de main: el que portaria en rebasar o fusionar main dins seu.

Solució 3:

L'àlies amb arguments:

El problema de GIT_PREFIX:

Ha llistat l'arrel del repositori, no el directori en què som.

Amb GIT_PREFIX, l'àlies respecta el directori des del qual es va invocar.

Aquesta lliçó ha convertit git log d'un llistat en una eina de consulta, i ha eliminat la fricció de fer-la servir. L'essencial:

• --graph --oneline --decorate --all és la vista canònica de la topologia. Els quatre van junts.
• --first-parent dona la història de main a nivell d'integracions, sense l'interior de les branques fusionades. És el mateix "primer pare" del -m 1 de revert i del bisect --first-parent.
• --simplify-by-decoration redueix l'historial a les seves fites: el primer que cal executar en un repositori desconegut.
• --merges / --no-merges separen integracions de feina real; --no-merges és gairebé obligatori en qualsevol estadística.
• A...B amb --left-right respon a "en què s'han separat aquestes dues branques?", amb < i > marcant cada costat. git rev-list --left-right --count dona només el recompte.
• --pretty=format: amb %C(auto) i els marcadors d'alineació %<(N,trunc) produeix sortides tabulars i acolorides; desa-les amb nom a pretty.<nom>.
• git shortlog -sn --no-merges resumeix les aportacions, amb .mailmap per unificar identitats — i amb l'advertiment que comptar commits no mesura res útil.
• Els àlies viuen a [alias] del .gitconfig del nivell que triïs. Els simples són un nom per a una subordre; els que comencen per ! són shell, amb tres cauteles: s'executen des de l'arrel (fes servir GIT_PREFIX), els arguments s'enganxen al final (fes servir el patró '!f() { ...; }; f') i corren sota sh, no bash.
• Per a lògica llarga, un executable git-<nom> al PATH és millor que un àlies.
• I la idea de fons: un àlies fixa en un gest el que has après a fer bé. culpa, pendent, fites o neteja són les lliçons anteriors condensades en una paraula.

L'equip ja sap interrogar el seu historial amb comoditat. Però gestor-tasques és a punt de deixar de ser un sol repositori: els botons, els diàlegs i els camps de formulari que l'Ana ha anat extraient s'han convertit en una biblioteca interna, components-ui, que viu a git.exemple.cat/equip/components-ui.git i que altres dos projectes de l'empresa també volen fer servir.

La pregunta és com es compon un projecte a partir de diversos repositoris sense copiar i enganxar codi, i sense perdre la traçabilitat de quina versió de la biblioteca fa servir cada versió de l'aplicació. La resposta nativa de Git són els submòduls, i és la lliçó 06-05: Submòduls de Git.