La lliçó anterior va resoldre una de les tres maneres en què un repositori es torna inmanejable: els fitxers molt grans. En queden dues, i són independents entre si. Un repositori pot tenir moltíssim historial encara que cada fitxer sigui diminut, i pot tenir moltíssims fitxers encara que l'historial sigui curt. Cada problema té el seu símptoma i el seu remei, i aplicar el remei equivocat no arregla res.

Aquesta lliçó tanca dues promeses del curs. La lliçó 06-05 va deixar oberta la comparativa entre submòduls, subtree, paquets i monorepo, ajornant el monorepo fins aquí. La 08-06 va ensenyar a mesurar i a optimitzar un repositori normal que s'ha tornat lent, i va remetre aquí els repositoris veritablement enormes. I el cas 3 de la 10-01 va descriure el monorepo empresarial explicant-ne el perquè i deixant el com per a aquesta lliçó.

Comencem per deixar clara una cosa, perquè és la més important de totes: gairebé res del que hi ha aquí no ho necessita gestor-tasques, ni probablement ho necessites tu. Això és material per al dia en què et toqui un repositori de cinquanta mil fitxers, i perquè sàpigues reconèixer quan ha arribat aquest dia. Aplicar aquestes tècniques a un repositori sa hi afegeix complexitat, raresa i una superfície nova d'errors, a canvi de res.

1. Les tres dimensions del creixement
2. Mesurar abans d'optimitzar (i què mesurar en cada cas)
3. Clons parcials: --filter=blob:none i --filter=tree:0
4. Clon parcial enfront de clon superficial
5. Sparse checkout i l'índex dispers
6. Acceleradors del costat del client
7. Monorepo enfront de multirepo
8. Què cal perquè un monorepo funcioni
9. Quan NO cal res d'això
10. Una recepta per símptoma

L'error més habitual en enfrontar-se a un repositori lent és tractar-lo com un problema. No ho és. Són tres, es manifesten de manera diferent i s'arreglen amb eines diferents.

Les tres són independents. Un repositori pot patir-ne una, dues o les tres alhora, i cal diagnosticar cadascuna per separat.

Un exemple que aclareix la independència: un repositori amb vint anys d'història i seixanta fitxers de text pateix la dimensió 1 i cap més. git clone triga deu minuts i git status és instantani. Aplicar-li sparse-checkout no serviria absolutament de res.

La regla de la lliçó 08-06 continua vigent i aquí importa més: la intuïció sobre què és lent és gairebé sempre equivocada. Abans d'aplicar cap d'aquestes tècniques, mesura.

Tres xifres que orienten la decisió, amb ordres de magnitud aproximats:

Són referències, no llindars exactes: depenen molt del maquinari, del sistema de fitxers i del sistema operatiu. Un repositori de 30.000 fitxers va fi en un portàtil modern amb Linux i pot ser penós a Windows amb un antivirus revisant cada accés.

Lectura del diagnòstic: 1,8 segons llegint l'índex i 9,1 segons recorrent directoris buscant fitxers sense seguiment. És un problema de dimensió 2 pur. Ni el commit-graph ni el clon parcial hi farien res; el que cal és untrackedCache, fsmonitor i, si escau, sparse-checkout.

I gestor-tasques, per tenir-ne la referència:

Cap de les tres dimensions. Res d'aquesta lliçó no li aplica.

El clon parcial és, de llarg, la tècnica més útil i menys coneguda d'aquesta lliçó.

Un clon normal descarrega tots els objectes assolibles: tots els commits, tots els arbres i tots els blobs de tota la història. Un clon parcial descarrega el graf però omet certs objectes, i els demana al servidor sota demanda quan alguna ordre els necessita.

Això requereix que el servidor ho admeti —ho fan les plataformes principals i les versions modernes de Git— i funciona sobre una connexió persistent anomenada promisor remote: el remot "promet" tenir els objectes que falten.

Descarrega tots els commits i tots els arbres, però cap blob llevat dels necessaris per extreure la revisió de treball.

Què continua funcionant sense descarregar res:

Què provoca una descàrrega sota demanda:

Veure-ho en marxa:

Git ha anat a buscar les 47 versions del fitxer que necessitava per al blame, i després ha respost. És més lent la primera vegada i queda a la memòria cau per a les següents.

Els objectes que ja s'han portat s'hi queden:

Aquest --missing=print llista amb un ? al davant els objectes que falten localment. És la manera de saber quant queda per descarregar.

Encara més agressiu: omet també els arbres. Només es descarreguen els objectes commit.

Amb això continua funcionant git log --oneline, git log --graph, git rev-list i qualsevol consulta purament topològica o de missatges. Però gairebé qualsevol operació sobre fitxers dispara descàrregues, inclòs git log --name-only, perquè els noms viuen als arbres.

És l'opció per a casos molt concrets: analitzar el graf d'un repositori enorme, comptar commits, extreure estadístiques d'autoria, generar un registre de canvis. Per treballar cada dia, --filter=blob:none és gairebé sempre l'elecció correcta.

blob:limit=1m és un punt intermedi interessant: porta tot el codi (que és petit) i deixa fora els binaris pesants. Sense necessitar LFS.

Per a un repositori hipotètic de gran mida, amb ordres de magnitud aproximats:

La fila que importa és la segona: el 8 % de la descàrrega conservant l'historial complet. Això és el que fa del clon parcial l'opció per defecte raonable per a repositoris grans.

A la lliçó 02-02 vam veure el clon superficial --depth=1. Convé contrastar-los, perquè resolen coses diferents i el superficial té paranys que el parcial no té.

1. No trenca la semàntica de Git. Un clon superficial és un repositori incomplet: hi ha commits que senzillament no existeixen, i qualsevol operació que necessiti assolir-los falla. Un clon parcial és un repositori complet amb contingut diferit: tot existeix, algunes coses es descarreguen en demanar-les.

Aquest és l'argument de fons. Amb --depth, Git et mentirà sobre la història i tu hauràs de recordar que està truncada. Amb --filter, Git et dirà la veritat i descarregarà allò que li falti.

2. La recuperació és transparent. Si un clon superficial necessita alguna cosa antiga, cal executar git fetch --unshallow, que descarrega el repositori sencer de cop. Un clon parcial porta només els objectes concrets que li calen, sense que tu hi intervinguis.

3. Els errors del superficial són confusos. Aquest és el clàssic en una canonada de CI:

O pitjor, en una comparació de petició d'extracció:

Tots dos fallen perquè el punt de divergència és fora de la profunditat descarregada. És el motiu que tantes configuracions de CI portin fetch-depth: 0 (descarregar-ho tot), que resol el problema per la via cara. L'alternativa bona:

Historial complet per a les comparacions i el describe, sense descarregar gigabytes de blobs antics. És la configuració recomanada per a CI en repositoris grans.

• El servidor no admet clons parcials.
• Una tasca de CI que només compila la revisió actual i no consulta res de l'historial: --depth=1 és mínim i suficient.
• Un contenidor de desplegament on només vols els fitxers d'una versió concreta. Encara que per a això, git archive sol ser encara millor:

Això no crea repositori: descarrega només els fitxers d'aquella etiqueta.

El clon parcial ataca el que es descarrega. sparse-checkout ataca el que apareix al disc, que és un problema diferent: la dimensió 2.

Un monorepo amb 300.000 fitxers. L'Ana treballa només a serveis/tasques/, que en són 400. Però la seva còpia de treball té els 300.000, i en conseqüència:

• git status recorre 300.000 entrades.
• L'editor indexa 300.000 fitxers.
• Cada git checkout entre branques comprova 300.000 rutes.
• La cerca de text travessa codi que no li interessa.

Després d'això, la còpia de treball conté només aquests directoris (més els fitxers de l'arrel), i git status passa de recórrer 300.000 entrades a recórrer'n unes poques milers.

I una manera més directa de clonar amb això ja actiu:

Aquesta combinació —clon parcial + sparse checkout— és el muntatge estàndard per treballar en un monorepo gran: descarregues poc i materialitzes menys.

sparse-checkout té dos modes, i la diferència és crucial.

El mode con renuncia a l'expressivitat per guanyar una propietat estructural: com que els patrons són sempre directoris sencers, Git pot raonar sobre subarbres complets en lloc de sobre fitxers solts. I això habilita el que és veritablement important.

Recorda de la lliçó 01-04 i de la 08-06 que l'índex (.git/index) conté una entrada per fitxer seguit. En un monorepo de 300.000 fitxers, l'índex té 300.000 entrades i ocupa desenes de megabytes. Llegir-lo i escriure'l és la primera causa de lentitud de git status, i passa encara que els fitxers no siguin al disc: l'índex els continua llistant.

L'índex dispers (sparse index) ho resol. En lloc d'una entrada per fitxer, en guarda una de sola per cada directori que és fora del con, apuntant directament al seu objecte arbre.

S'activa així:

I es comprova:

L'efecte sobre git status en un monorepo gran és d'un ordre de magnitud. I el motiu és purament estructural: una entrada d'arbre representa un subarbre sencer, gràcies al fet que el hash d'un arbre resumeix tot el seu contingut (lliçó 01-04). Si el hash de l'arbre de serveis/facturacio/ no ha canviat, Git sap amb certesa matemàtica que res d'aquest subdirectori no ha canviat, sense mirar ni un sol fitxer.

Aquest és un exemple preciós de per què entendre el model de dades importa: l'índex dispers no és un truc, és una conseqüència directa de l'adreçament per contingut.

Amb sparse-checkout actiu, git status inclou un avís:

Aquest avís és important i cal saber llegir-lo. No estàs veient el repositori sencer. Si busques un fitxer i no apareix, potser no és que no existeixi: és que és fora del teu con.

Ordres que es comporten de manera diferent:

I la raresa que més desconcerta: si fas git checkout d'una branca que esborra un fitxer fora del teu con, no veuràs res, perquè aquest fitxer mai no va ser al teu disc. Tot és coherent, però requereix tenir el model clar.

Aquests ja van aparèixer a la lliçó 08-06; aquí van amb el matís de l'escala.

És un fitxer d'índex auxiliar que guarda, precalculada, la topologia de l'historial: per a cada commit, els seus pares, la seva data i el seu número de generació (la distància al commit arrel).

Sense ell, respondre "és A avantpassat de B?" obliga a llegir objectes commit del disc i a recórrer el graf. Amb ell, el número de generació permet descartar branques senceres del recorregut sense llegir res.

El --changed-paths mereix atenció especial en repositoris enormes: guarda un filtre de Bloom amb les rutes modificades a cada commit. Serveix per accelerar dràsticament:

En un monorepo, git log sobre un fitxer concret passa d'examinar milions de commits a descartar-los gairebé tots amb una comprovació de bits. És la diferència entre trenta segons i mig segon.

És l'optimització de dimensió 1 amb millor relació cost/benefici, i no té cap inconvenient: és un fitxer de memòria cau regenerable que no altera res del repositori.

fsmonitor engega un dimoni que escolta les notificacions del sistema de fitxers i manté la llista del que ha canviat. Així git status no ha de recórrer els directoris: pregunta al dimoni.

untrackedCache guarda a l'índex l'última exploració de cada directori juntament amb la seva marca de temps, per no tornar a explorar els que no s'han tocat.

Efecte conjunt en un repositori de 100.000 fitxers, com a ordre de magnitud: git status pot passar de diversos segons a fraccions de segon. La combinació amb l'índex dispers és multiplicativa, perquè ataquen parts diferents del cost: fsmonitor redueix el que cal mirar al disc, l'índex dispers redueix el que cal llegir de l'índex.

Nota de plataforma: fsmonitor integrat funciona a macOS i Windows de sèrie; a Linux depèn de la versió de Git i pot requerir configuració addicional. Mesura-ho abans i després al teu entorn concret.

Programa tasques periòdiques al planificador del sistema: actualitzar el commit-graph, empaquetar objectes solts de manera incremental, fer prefetch dels remots i netejar referències.

Enfront del gc automàtic de sempre, té dos avantatges: s'executa quan no estàs treballant en lloc d'interrompre't, i inclou tasques que gc no fa, com el prefetch (que descarrega en segon pla el que altres publiquen, de manera que el teu git fetch sigui instantani).

Configuració recomanada per a un repositori gran:

Git ofereix dos "paquets" de configuració que activen diverses coses alhora:

feature.manyFiles activa index.version=4 (format d'índex més compacte), core.untrackedCache=true i index.skipHash=true. És la drecera raonable per a la dimensió 2. El que fa exactament pot canviar entre versions de Git, així que convé comprovar-ho amb git help config.

Aquí es tanca la comparativa que la lliçó 06-05 va deixar oberta i que el cas 3 de la 10-01 va deixar pendent.

Multirepo: cada projecte o biblioteca té el seu repositori. La relació entre ells s'estableix amb versions publicades (paquets), amb submòduls o amb subtree.

Monorepo: un únic repositori conté molts projectes, que es relacionen per rutes de directori i es compilen junts.

Fixa't en les versions del diagrama de l'esquerra: tres consumidors fent servir tres versions diferents de la mateixa biblioteca. Això és el normal en multirepo, i és alhora el seu avantatge més gran (autonomia) i el seu problema més gran (deriva).

El monorepo té sentit quan:

• Els projectes canvien junts sovint: el símptoma inequívoc és que una petició d'extracció necessita canvis coordinats en diversos repositoris.
• Hi ha biblioteques internes compartides i la deriva de versions ja fa mal.
• Tothom pot veure tot el codi.
• Hi ha capacitat d'invertir en eines i de mantenir-les.
• Es vol que la refactorització global sigui possible.

El multirepo té sentit quan:

• Els projectes són realment independents i evolucionen a ritmes diferents.
• Hi ha requisits d'accés que obliguen a separar.
• Els equips són autònoms i publiquen pel seu compte.
• Alguns components es publiquen fora de l'organització.
• No hi ha capacitat de mantenir eines pròpies.
• Es prefereix la solució que funciona sola.

De tots els criteris, un pesa més que els altres:

Amb quina freqüència un canvi necessita tocar diversos repositoris alhora?

Si la resposta és "gairebé mai", multirepo, sense dubtar-ho. Si és "constantment, i és el nostre coll d'ampolla més gran", el monorepo resol exactament aquest problema i mereix la inversió.

I recorda la conclusió de la lliçó 06-05: els submòduls no resolen això. Lliguen una versió concreta d'una biblioteca a un consumidor —donen traçabilitat— però cada actualització continua sent un commit a cada consumidor. Són un multirepo amb traçabilitat, no un monorepo barat.

No és una decisió binària ni irreversible. Els patrons intermedis més habituals:

1. Monorepo per domini. Un repositori per àrea gran (plataforma, producte, dades), no un per servei ni un per a tot. Captura la major part del benefici d'atomicitat sense arribar a escales que exigeixin eines exòtiques. És el punt òptim per a la majoria d'organitzacions mitjanes.

2. Monorepo per a les biblioteques compartides. S'agrupen només les biblioteques internes, que són les que pateixen la deriva de versions, i els productes continuen separats. És un pas reversible i amb benefici immediat.

3. Migració gradual. Es pot fusionar un repositori dins d'un altre conservant el seu historial:

La combinació merge -s ours + read-tree --prefix és el mecanisme clàssic: el merge connecta els dos historials sense portar contingut, i el read-tree col·loca l'arbre de l'altre repositori sota el prefix indicat. El resultat és que git log --follow biblioteques/components-ui/boto.js continua funcionant cap enrere. És també, essencialment, el que fa git subtree add per sota (lliçó 06-05).

Si la decisió és monorepo, aquestes peces no són opcionals. Un monorepo sense elles és simplement un repositori lent i caòtic.

Això convé posar-ho en un guió d'incorporació al mateix repositori, perquè ningú no recordarà sis ordres.

El fitxer CODEOWNERS que vam veure a la lliçó 10-01. Sense ell, el monorepo perd la propietat clara que el multirepo dona de franc.

Ja en vam veure l'esquelet a la 10-01. La versió que importa aquí és la basada en el graf de dependències, no en directoris:

Fixa't en el sparse-checkout dins de la tasca de CI: cada execució materialitza només el projecte que provarà. És la mateixa tècnica de l'apartat 5, aplicada a la canonada.

El que fa afectats.sh és el que distingeix una CI selectiva bona d'una d'ingènua: si canvia biblioteques/components-ui, no n'hi ha prou de provar aquesta biblioteca; cal provar tots els projectes que en depenen. Això exigeix un graf de dependències explícit, que el proporciona el sistema de compilació.

En un monorepo, compilar-ho tot a cada canvi és inviable. Cal un sistema que entengui el graf de dependències i que guardi els resultats a la memòria cau indexats pel hash de les entrades: si res del que entra en un objectiu no ha canviat, es reutilitza el resultat anterior.

És, curiosament, el mateix principi que sosté Git: identificar pel hash del contingut i no recalcular el que no ha canviat.

Amb molts projectes en un repositori, calen convencions fortes: estructura de directoris homogènia, noms predictibles, i eines per aplicar canvis massius ("reanomenar aquesta funció a 200 llocs") de manera automàtica i revisable.

Aquest apartat és tan important com els anteriors.

gestor-tasques no necessita res d'aquesta lliçó. Ni clons parcials, ni sparse-checkout, ni fsmonitor, ni monorepo. Té nou fitxers, 412 commits i pesa 2 MB. git status respon en mil·lisegons.

I no és un cas excepcional: la immensa majoria dels repositoris del món estan en aquesta situació. Un projecte amb 5.000 fitxers, 30.000 commits i 200 MB va perfectament amb Git de sèrie en qualsevol ordinador modern.

La tècnica més perillosa de la llista és sparse-checkout. Un company nou que hereta una configuració dispersa sense saber-ho pot passar-se hores sense entendre per què un fitxer que veu al web no és al seu disc.

Si git status respon en menys d'un segon i git clone triga menys d'un minut, no tens cap problema que aquestes tècniques resolguin.

Mesura primer (apartat 2). Aplica el remei de la dimensió que faci mal. Mesura després. I si no fa mal res, no facis res.

Taula de consulta ràpida.

Error 1: optimitzar sense mesurar. L'error central de la lliçó. Aplicar sparse-checkout a un problema d'historial no fa res. Diagnostica la dimensió primer.

Error 2: fer servir --depth=1 a la CI i després necessitar l'historial. Produeix fatal: no merge base i fatal: No names found. Fes servir fetch-depth: 0 amb filter: blob:none.

Error 3: sparse-checkout sense --cone. El mode de patrons és més lent, no permet índex dispers i és molt més fàcil de configurar malament. Fes servir --cone llevat que tinguis una raó molt concreta.

Error 4: oblidar que sparse-checkout està actiu. Documenta la configuració dispersa al README.md i recorda que git status avisa amb "You are in a sparse checkout with N% of tracked files present".

Error 5: creure que el clon parcial funciona sense connexió. Si treballes en un avió amb un clon parcial i executes git log -p sobre història antiga, fallarà: necessita anar al servidor. Abans de desconnectar-te, porta el que hagis de necessitar:

Error 6: triar monorepo per moda. Sense CI selectiva, sense CODEOWNERS i sense sistema de compilació amb memòria cau, un monorepo és pitjor que el que tenies. La pregunta no és "què fan les empreses grans?", sinó "amb quina freqüència un canvi nostre toca diversos repositoris?".

Error 7: creure que els submòduls són un monorepo barat. No ho són: no donen atomicitat. Cada actualització de la biblioteca continua exigint un commit a cada consumidor (lliçó 06-05).

Consell 1: commit-graph per a tothom. És l'única optimització de la lliçó sense cap inconvenient. Activa-la encara que el teu repositori sigui mitjà:

Consell 2: git maintenance start als teus repositoris grans. Millor que esperar el gc automàtic, i sense interrompre't.

Consell 3: mesura amb hyperfine o amb un bucle senzill. Abans i després, diverses vegades:

Consell 4: posa un guió d'incorporació al repositori. Si el teu monorepo necessita sis ordres de configuració, posa-les a eines/configurar.sh i menciona-ho al README.md.

Consell 5: la CI també pot fer servir sparse checkout. Els fluxos moderns permeten declarar quins directoris materialitzar. En un monorepo, això redueix cada tasca de minuts a segons.

Per a cada repositori, digues quina dimensió pateix, què NO ho arreglaria i què sí:

A.

B.

C.

L'Ana s'incorpora a un equip amb un monorepo: 340.000 fitxers, 2,1 milions de commits, 12 GB. Ella treballarà només a serveis/tasques/ i farà servir biblioteques/components-ui/.

Escriu la seqüència completa d'ordres, des del clon fins a un lloc operatiu, explicant què ataca cadascuna i a quina dimensió. Inclou també què li diries sobre les rareses amb què es trobarà.

Una empresa de 120 persones té 23 repositoris: 8 serveis, 6 aplicacions client, 9 biblioteques internes.

Símptomes que reporten:

• Canviar la interfície de la biblioteca autenticacio triga sis setmanes a arribar a tots els consumidors.
• Hi ha quatre versions diferents de components-ui en producció alhora.
• Ningú no sap quins serveis fan servir quines biblioteques.
• Un col·laborador nou triga tres dies a clonar i configurar el que necessita.
• Dos dels serveis els manté una empresa externa que no ha de veure la resta del codi.
• Les biblioteques grafics i utilitats es publiquen públicament com a codi obert.

Decideix què recomanaries, amb quins passos i en quin ordre. Assenyala explícitament què no ficaries al monorepo i per què.

Solució 1

A. Dimensió 1 pura: molt historial.

Indicis: 1,8 milions de commits però només 1.204 fitxers. git status respon en 89 ms (la dimensió 2 no existeix). El repositori pesa 1,84 GB, cosa coherent amb 1,8 milions de commits de codi de text, no amb binaris.

El símptoma decisiu: git log sobre un fitxer triga 47 segons. Git ha de recórrer milions de commits comprovant si cadascun va tocar src/nucli.c.

Què NO ho arreglaria: sparse-checkout (només hi ha 1.204 fitxers i status ja és instantani), LFS (no hi ha binaris), fsmonitor (res per recórrer al disc).

Què sí:

Amb --changed-paths, aquest git log -- src/nucli.c de 47 segons hauria de baixar a menys d'un segon: el filtre de Bloom descarta la immensa majoria dels commits sense obrir-ne els arbres.

B. Dimensió 2 dominant: molts fitxers.

Indicis: 285.000 fitxers, només 8.420 commits (l'historial és curt), i git status triga 42 segons. Els 3,21 GB són consistents amb molts fitxers, no necessàriament amb binaris grans.

Què NO ho arreglaria: commit-graph (amb 8.420 commits, l'historial no és el problema), clon superficial (tampoc).

Què sí, en ordre de menor a major intrusió:

L'ordre importa: els passos 1 i 2 no canvien el que veus al disc i poden resoldre-ho. El pas 3 sí que ho canvia i té cost de comprensió per a tot l'equip.

Convé a més comprovar si aquests 3,21 GB amaguen un problema de dimensió 3:

C. Dimensió 3 pura: fitxers molt grans.

Indicis inequívocs: 89 fitxers, 1.204 commits, 6,72 GB. L'aritmètica no deixa lloc a dubtes: 6,72 GB entre 89 fitxers són uns 75 MB per fitxer de mitjana. Són binaris.

Què NO ho arreglaria: absolutament res de sparse-checkout ni de commit-graph. Ni tan sols un clon superficial ajudaria gaire, perquè els blobs grans de l'última revisió ja pesen.

Què sí:

El pas 4 és un alleujament útil: el clon parcial evita descarregar totes les versions històriques dels binaris, encara que no arregli la mida del repositori del costat del servidor.

Solució 2

--filter=blob:none evita descarregar el contingut històric de 2,1 milions de commits: de 12 GB passem a una fracció petita, conservant el graf complet. --sparse fa que el checkout inicial materialitzi només l'arrel, en lloc d'escriure 340.000 fitxers al disc.

--cone permet l'índex dispers; --sparse-index i index.sparse fan que l'índex guardi una entrada per directori fora del con en lloc d'una per fitxer. De ~340.000 entrades a unes poques milers.

Què li diria a l'Ana sobre les rareses:

1. "No veuràs la majoria dels fitxers." git status t'avisarà: "You are in a sparse checkout with 2% of tracked files present". No estan esborrats: no estan materialitzats. git show HEAD:serveis/facturacio/main.js funciona perfectament.

2. "Si necessites una altra àrea, afegeix-la." git sparse-checkout add serveis/notificacions. No cal clonar de nou.

3. "Algunes operacions aniran a la xarxa." git log -p sobre història antiga, git blame d'un fitxer amb moltes versions, o git checkout d'una etiqueta vella descarregaran blobs. La primera vegada és lenta; després queda a la memòria cau.

4. "Abans d'anar-te'n sense connexió, porta el que hagis de necessitar." Un clon parcial necessita el servidor per al que no té.

5. "El teu editor i les teves cerques només veuen el teu con." Això és bo per al rendiment, però si busques una funció i no apareix, potser és fora de la teva àrea. git grep --no-index o buscar al web del repositori són la sortida.

6. "Si alguna cosa es comporta de manera estranya, mira primer git sparse-checkout list." És el primer sospitós de gairebé qualsevol raresa.

I li passaria un guió eines/configurar-lloc.sh amb tot l'anterior, perquè ningú no recorda catorze ordres.

Solució 3

Recomanació: monorepo parcial, en tres fases, començant per les biblioteques.

El símptoma dominant és inequívoc: sis setmanes per propagar un canvi de biblioteca i quatre versions de components-ui en producció. Això és exactament el problema que el monorepo elimina d'arrel, i confirma que hi ha acoblament fort entre les biblioteques i els seus consumidors.

Però hi ha dues restriccions que impedeixen un monorepo total, i cal respectar-les.

Què NO entra al monorepo, i per què:

Fase 1: monorepo de biblioteques internes (7 biblioteques).

És el pas amb millor relació benefici/risc, i és reversible.

Benefici immediat: un canvi que toca autenticacio i dades alhora passa a ser un commit, i git bisect funciona entre biblioteques.

Aquestes biblioteques continuen publicant-se com a paquets versionats per als consumidors, de manera que res no canvia per als 12 productes. Per això és reversible.

Fase 2: absorbir els consumidors més acoblats.

Mesurar primer quins són:

Els que apareguin repetidament al costat de canvis de biblioteca són els candidats. S'absorbeixen aquests, no tots.

Fase 3: consolidar la resta, si l'experiència ha estat bona.

Inversió obligatòria abans de la fase 2 (sense això, el monorepo empitjora les coses):

1. CODEOWNERS per directori — recupera la propietat que el multirepo donava de franc.
2. CI selectiva amb graf de dependències — sense ella, cada petició d'extracció executa la suite sencera.
3. Sistema de compilació amb memòria cau pel hash de les entrades — o els temps de compilació es disparen.
4. Guió de configuració del lloc — amb --filter=blob:none --sparse, com a la solució 2.

Què resol cada símptoma reportat:

Resultat final: 1 monorepo (7 biblioteques + els productes interns que s'absorbeixin), 2 repositoris privats per a l'empresa externa, 2 repositoris públics. De 23 repositoris a 5, sense violar cap restricció.

El que NO faria: ficar-ho tot de cop. La fase 1 és reversible i dona benefici en setmanes; una migració total de 23 repositoris sense eines és una manera habitual de tenir un repositori de 40 GB, una CI de dues hores i un equip furiós.

Escalar Git comença per deixar de tractar-lo com un sol problema.

• Són tres dimensions independents: molt historial (git log i blame lents), molts fitxers (git status lent) i fitxers molt grans (repositori de gigabytes). Cadascuna té el seu símptoma, la seva mesura i el seu remei, i aplicar el remei equivocat no arregla res. Es diagnostiquen amb git rev-list --count --all, git ls-files | wc -l i git count-objects -vH, i s'afina amb GIT_TRACE2_PERF.
• Els clons parcials són la tècnica més útil i menys coneguda: --filter=blob:none descarrega el graf complet i omet el contingut històric, demanant-lo sota demanda; --filter=tree:0 omet també els arbres. Conserven log, bisect, describe i merge-base.
• Enfront del clon superficial --depth, el parcial és gairebé sempre millor: --depth produeix un repositori incomplet on falten commits i les operacions fallen (fatal: no merge base), mentre que el parcial produeix un repositori complet amb contingut diferit. Per a la CI: fetch-depth: 0 + filter: blob:none.
• sparse-checkout --cone limita el que es materialitza al disc, i l'índex dispers guarda una entrada per directori fora del con en lloc d'una per fitxer. El mode con renuncia a expressivitat per poder raonar sobre subarbres complets, cosa que només és possible perquè el hash d'un arbre resumeix tot el seu contingut (lliçó 01-04).
• Els acceleradors del client —commit-graph --changed-paths, fsmonitor, untrackedCache, feature.manyFiles i git maintenance— ataquen parts diferents del cost i es combinen bé. El commit-graph és l'únic sense inconvenients: activa'l sempre.
• Monorepo enfront de multirepo es decideix amb una sola pregunta: amb quina freqüència un canvi necessita tocar diversos repositoris alhora? El monorepo compra atomicitat i refactorització global; ho paga amb eines pròpies, CODEOWNERS, CI selectiva i escalat de Git. I hi ha camins intermedis: monorepo per domini, monorepo només de biblioteques, migració gradual amb merge -s ours + read-tree --prefix.
• I el més important: la majoria dels repositoris no necessiten res d'això. gestor-tasques té nou fitxers, 412 commits i 2 MB. Aplicar-li sparse-checkout seria afegir confusió a canvi de res.

La regla que resumeix la lliçó, i que és la mateixa de la 08-06 portada a una altra escala:

Mesura, diagnostica la dimensió, aplica el remei d'aquesta dimensió, i torna a mesurar. Si git status respon en menys d'un segon, no tens cap problema que aquestes tècniques resolguin.

Ja sabem operar Git en repositoris de qualsevol mida. Queda l'última peça del món real, i és la que converteix Git en alguna cosa més que una eina de desenvolupadors.

A la lliçó 07-06 vam traçar una frontera: allà parlàvem d'integració contínua —comprovar automàticament que el que s'integra funciona— i vam deixar per a més endavant com aquest codi arriba als usuaris. També a la 07-04 vam ajornar la mecànica dels entorns i la promoció, i a la 05-05, en etiquetar v1.4.0, vam dir que les etiquetes anotades serien la peça que dispara un desplegament.

Tot això convergeix aquí. En moltes organitzacions, Git ja no el fa servir només una persona en un terminal: el fan servir cent canonades que clonen, etiqueten, construeixen i publiquen sense intervenció humana. El repositori deixa de contenir només codi i passa a contenir la definició de l'entorn, la configuració i la infraestructura. I un git push a la branca correcta deixa de ser "he desat la meva feina" per convertir-se en "això és a producció d'aquí a quatre minuts".

La lliçó 10-05: Git a DevOps tanca aquesta promesa: Git com a font única de veritat, els tres esglaons de CI, lliurament i desplegament, què dispara cadascun, per què l'artefacte s'ha d'identificar pel hash del commit, què és GitOps, on viuen els secrets en un món automatitzat, i per què revertir en producció gairebé mai no és un git revert.