L'auditoria de seguretat de 08-03 va canviar dotze coses del toolkit, i la lliçó d'optimització n'havia canviat unes quantes més abans. Ara mateix, si vigilant.sh comença a fallar el dimarts de matinada, ningú no sap dir què es va tocar, quan ni per què, ni com tornar a la versió que funcionava. Aquesta lliçó posa ~/veloz-ops/ sota control de versions. No és un curs de Git: és Git vist des de la necessitat concreta d'un equip d'operacions que manté cinc scripts, una llibreria i un fitxer de configuració amb credencials que no s'ha de pujar mai.

1. Per què copia.sh.bak.old.v2 no és control de versions
2. Els cinc conceptes que calen
3. Posar ~/veloz-ops/ sota control
4. Veure què ha canviat: git diff i git log
5. Què NO es versiona: .gitignore i la configuració
6. Si ja has pujat un secret
7. Missatges de commit útils en operacions
8. Desfer amb criteri
9. Branques per provar sense tocar producció
10. Etiquetes i desplegament a la flota
11. Remots i repositoris privats
12. Un hook pre-commit de debò
13. Flux de treball mínim per a un equip petit

El patró és universal: abans de tocar un script se'n fa una còpia amb un sufix. Al cap d'un any el directori té copia.sh.bak, copia.sh.old, copia.sh.v2, copia.sh.20260715 i copia.sh.BO. I cap d'aquestes còpies no respon a les preguntes que importen: què va canviar exactament entre dues d'elles, qui ho va canviar, quan, per què i quina és la que corre ara a srv-veloz-02. Tampoc no permeten saber si el canvi del dimarts i el del dijous són independents.

Git respon a les cinc preguntes i hi afegeix dues capacitats que les còpies no donen: provar un canvi en paral·lel sense tocar el que és en producció, i desfer un canvi concret sense desfer els posteriors.

L'àrea de preparació és el que més confon al principi i té una raó molt pràctica: permet haver tocat quatre fitxers i fer dos commits diferents, un amb la correcció de seguretat i un altre amb la millora de rendiment. En operacions això val or, perquè permet revertir-ne un sense l'altre.

Abans del primer git add cal decidir què no hi entra, així que el correcte és escriure el .gitignore primer (apartat 5) i després afegir:

git add mou canvis a l'àrea de preparació; git commit els grava a la història. A git status --short, A és added, M modificat, D esborrat i ?? sense seguiment. Un detall que estalvia sorpreses: Git desa el bit d'execució, així que els chmod +x de bin/ viatgen amb el repositori.

La distinció entre els dos diff és la que més es pregunta en començar: el primer ensenya el que encara no has afegit amb git add; el segon, el que és a punt d'entrar al commit. Revisa sempre git diff --staged abans d'escriure el missatge: és el moment natural per descobrir que t'has deixat un set -x posat. Per investigar un fitxer concret, git log -p bin/vigilant.sh mostra la seva història línia a línia i git blame bin/vigilant.sh diu quin commit va introduir cada línia: l'eina que de debò faràs servir quan alguna cosa faci mesos que està trencada.

Aquesta és la part crítica. etc/veloz-ops.conf conté el token que acabem de protegir a 08-03; pujar-lo el fa visible per a tot l'equip, per sempre i a cada clon.

Al seu lloc es versiona una plantilla que documenta la configuració sense revelar res:

En instal·lar el toolkit en un servidor nou es copia la plantilla, s'omple i s'ajusten els permisos. Una advertència important: .gitignore només afecta els fitxers sense seguiment. Si ja vas fer git add etc/veloz-ops.conf, afegir-lo al .gitignore no el treu: cal git rm --cached etc/veloz-ops.conf, que el treu del repositori i el deixa al disc.

Passa. L'ordre de les accions no és negociable:

1. Rota el secret immediatament. Genera'n un de nou i invalida el vell. És l'únic pas que de debò mitiga; els altres són neteja.
2. Treu-lo del repositori actual: git rm --cached, afegeix-lo al .gitignore, commit.
3. Reescriu la història amb git filter-repo (l'eina recomanada avui) o BFG Repo-Cleaner, que eliminen el fitxer de tots els commits.
4. Avisa l'equip: la reescriptura canvia tots els identificadors de commit i qui tingui un clon l'haurà de refer.

I l'advertència de fons: reescriure la història no n'hi ha prou si el repositori ja s'ha compartit. Qualsevol el va poder clonar, la plataforma el va poder indexar, hi ha còpies a la memòria cau i a les còpies de seguretat. Per això el pas 1 no és opcional ni posterior.

Un missatge no descriu el diff —això ja ho fa el diff—, sinó què va canviar i per què. En operacions, el «per què» sol ser un incident:

Convenció pràctica: primera línia imperativa de menys de 72 caràcters, línia en blanc i cos amb el context.

D'aquí a sis mesos, aquest commit explica per què existeix un bucle de reintents que a primera vista sobra. Un commit per canvi lògic: no barregis la refactorització de rendiment amb la correcció de seguretat encara que les hagis fet la mateixa tarda.

Quatre ordres per a quatre situacions. Confondre-les és la principal font de feina perduda:

Regla d'or: git revert per al que ja han vist altres; git reset --hard només per al que és teu i no publicat. revert deixa constància que hi va haver un canvi i que es va retirar, cosa que en operacions és informació valuosa. I si el missatge de l'últim commit està malament, git commit --amend el corregeix mentre no l'hagis pujat.

Vols reescriure la lògica de llindars de vigilant.sh, però aquest script corre cada cinc minuts a tres servidors. Una branca et dóna un espai paral·lel:

Quan el canvi estigui provat s'integra amb git merge llindars-dinamics i s'esborra la branca amb git branch -d. Si en l'interval algú va tocar les mateixes línies a master, Git avisa d'un conflicte i marca el fitxer:

Resoldre'l és editar el fitxer deixant-hi la versió correcta —sovint una combinació de totes dues—, esborrar les tres línies de marques i fer git add i git commit. No hi ha màgia: decideix un humà. En scripts de Bash convé a més executar bash -n (05-03) sobre el fitxer resolt abans de confirmar, perquè un conflicte mal resolt hi deixa fàcilment un fi de més.

Una etiqueta marca un punt de la història amb un nom estable, i en operacions serveix per saber quina versió corre a cada servidor:

El desplegament a srv-veloz-01/02/03 combina això amb el que vam veure a 07-06:

L'opció A permet consultar la versió desplegada amb git describe a cada màquina; la B evita instal·lar Git i credencials en producció. Fixa't en l'exclusió d'etc/veloz-ops.conf: la configuració és local de cada servidor i no s'ha de sobreescriure des del repositori.

Un repositori local no és una còpia de seguretat: si es perd el disc, es perd la història.

git pull és internament fetch més merge; si prefereixes veure què arriba abans d'integrar-ho, git fetch seguit de git log HEAD..origin/master és un hàbit excel·lent en operacions. I una advertència que no sobra: el codi d'operacions va en repositoris privats. Encara que no contingui secrets —i no n'ha de contenir—, revela noms de servidors, camins interns, llindars i estructura del sistema; és reconeixement gratuït per a un atacant. Autenticació per clau SSH (07-06), no per contrasenya.

Un hook és un script que Git executa automàticament en un cert moment. pre-commit corre abans de crear el commit i, si acaba amb un codi diferent de 0, l'avorta:

Quatre barreres: sintaxi amb bash -n, anàlisi estàtica amb ShellCheck, proves amb Bats i una cerca simple de secrets. --diff-filter=ACM limita la comprovació als fitxers afegits, copiats o modificats —no té sentit analitzar-ne un que s'esborra— i només mira els preparats, no tot l'arbre. Dues limitacions que cal conèixer: els hooks viuen a .git/hooks/ i no es versionen, així que cal instal·lar-los a cada clon (per això molts equips guarden el hook a tools/ i l'enllacen amb un script d'instal·lació), i git commit --no-verify se'ls salta. El hook és una xarxa de seguretat per a despistes, no un control d'accés.

Per a dues o tres persones d'operacions n'hi ha prou amb això: git pull abans de començar; branca curta per al canvi (git switch -c corregir-timeout-api); commits petits amb missatges que citin l'incident; git push -u origin <branca> i petició de revisió a una altra persona; fusió a master, etiqueta si és desplegable i desplegament a la flota; esborrar la branca.

El penúltim pas és el més important de la llista, i no és una eina: és una persona. La revisió per part d'un altre company és el millor control de qualitat que existeix, millor que ShellCheck, que les proves i que la disciplina pròpia. Troba el que les eines no veuen: que el llindar està mal triat, que l'script assumeix un directori que només existeix a la teva màquina, que aquell rm -rf no està tan acotat com sembla. Deu minuts de revisió estalvien una guàrdia nocturna.

• Començar per git add . sense .gitignore. És la manera més habitual de pujar un secret. El .gitignore va abans del primer commit.
• Creure que .gitignore retira fitxers ja versionats. No ho fa: git rm --cached és el que els treu.
• Esborrar el secret i no rotar-lo. Continua a la història, als clons i a les memòries cau.
• git reset --hard sobre commits ja publicats. Trenca el repositori dels altres; per al que està publicat, git revert.
• Consell: git stash per a la interrupció. Desa la feina a mitges, atén la incidència i recupera-la amb git stash pop.
• Consell: git log -S 'veloz_api_get' busca en quin commit va aparèixer o va desaparèixer una cadena; és la manera ràpida de datar un canvi de comportament.

Exercici 1. Descobreixes que etc/veloz-ops.conf, amb el token de l'API, fa tres commits que està versionat en un repositori compartit amb dos companys. Enumera en ordre les accions i les ordres concretes.

Exercici 2. Escriu el .gitignore del toolkit justificant cada exclusió, i explica què es versiona al seu lloc.

Exercici 3. Has fusionat a master un canvi a vigilant.sh (commit 3b8d201) que provoca alertes falses, i ja hi ha dos commits posteriors d'un altre company. Com el desfàs sense perdre la seva feina?

Solució 1. Primer, rotar el token a l'API i invalidar l'antic: és en tres clons i al servidor de Git, i és l'única cosa que talla l'exposició real. Després:

Després reescriure la història amb git filter-repo --path etc/veloz-ops.conf --invert-paths (o BFG), avisant abans els dos companys que hauran de tornar a clonar perquè tots els identificadors de commit canvien. I documentar l'incident, recordant que la reescriptura no substitueix la rotació: si el repositori s'ha compartit, cal assumir que el token és públic.

Solució 2. El de l'apartat 5. etc/veloz-ops.conf, *.key, *.pem i .netrc contenen credencials; logs/ i *.log són sortida regenerable que a més faria créixer el repositori sense límit; *.tmp són temporals de mktemp; dades/ i *.csv són dades de negoci amb informació personal (08-03), que pertanyen a la còpia de seguretat i no al control de versions. Es versiona etc/veloz-ops.conf.exemple perquè documenta quines variables cal definir sense revelar-ne els valors.

Solució 3. Amb git revert, que crea un commit nou desfent exactament els canvis de 3b8d201 i deixa intactes els dos posteriors:

git reset --hard seria un error greu: llençaria també els commits del company i, com que ja estan publicats, obligaria a un push --force que trencaria el seu repositori. Si el revert produeix conflicte perquè els commits posteriors van tocar les mateixes línies, es resol a mà com a l'apartat 9 i s'acaba amb git revert --continue.

Git resol per a un toolkit d'operacions el que les còpies .bak no resolen: què va canviar, qui, quan i per què, i com tornar enrere sense arrossegar la resta. Amb cinc conceptes —repositori, àrea de preparació, commit, branca i remot— n'hi ha prou per treballar: git init, git add, git commit -m, git status --short, git diff i git diff --staged per revisar abans de confirmar, git log --oneline --graph per llegir la història i git blame per saber qui va introduir aquella línia. El primer que s'escriu no és un commit sinó el .gitignore, que deixa fora logs/, temporals, dades i sobretot etc/veloz-ops.conf amb les seves credencials, versionant al seu lloc etc/veloz-ops.conf.exemple; i si un secret ja és a dins, l'ordre és rotar primer, després git rm --cached i després git filter-repo o BFG, sabent que reescriure la història no repara res si el repositori ja s'ha compartit. Els missatges descriuen el canvi i el seu motiu —l'incident que el va provocar—, amb un commit per canvi lògic. Per desfer cal triar bé: git restore descarta edicions, git restore --staged retira de l'àrea de preparació, git revert desfà el que està publicat deixant-ne constància i git reset --hard només es fa servir sobre commits propis no publicats. Les branques (git switch -c) permeten reescriure vigilant.sh sense tocar el que corre cada cinc minuts, amb fusió i resolució manual de conflictes; les etiquetes (git tag -a v1.2) fixen quina versió està desplegada i es combinen amb el desplegament a la flota de 07-06, per git checkout a cada servidor o per rsync excloent .git i la configuració local. El remot —privat i amb clau SSH— és alhora còpia de seguretat i punt de trobada. I el pre-commit automatitza les barreres: bash -n, ShellCheck, Bats i una cerca de secrets, amb la doble advertència que els hooks no es versionen i que --no-verify se'ls salta. Per damunt de tot això queda el control de qualitat més eficaç, que no és una eina: que una altra persona llegeixi el teu canvi abans que arribi a producció.

El hook pre-commit que acabem d'escriure invoca dues ordres que encara no coneixem. La lliçó 08-05 s'ocupa de la primera: ShellCheck, l'analitzador estàtic que troba els errors que aquest curs t'ha ensenyat a evitar —i uns quants més—, juntament amb shfmt per al format uniforme que 08-01 va deixar promès. Recorrerem els avisos més freqüents connectant-los amb la lliçó on es va explicar el problema, aprendrem a silenciar un avís amb criteri i no per comoditat, i passarem ShellCheck als cinc scripts i a lib/comu.sh per classificar i corregir tot el que aparegui.