El projecte contoso-reservas ja existeix, però és buit. El codi del web de reserves continua on era: al portàtil d'en Diego Salas, en una carpeta amb control de versions local que ningú més no veu, i en una successió de ZIP a la safata d'entrada de la Marta. Aquesta lliçó elimina aquesta situació de soca-rel.

Azure Repos és el servei de repositoris Git privats d'Azure DevOps. Allotjar codi en un repositori remot és la part fàcil —això ho fa qualsevol—; el que de debò transforma la feina de l'equip és el que es construeix a sobre: una estratègia de ramificació que tothom entén, sol·licituds d'incorporació de canvis que converteixen la revisió en conversa registrada, i directives de branca que fan que les regles de l'equip deixin de dependre que algú se'n recordi. En acabar, la branca main de Contoso serà, per construcció, sempre desplegable.

1. Git en l'imprescindible: confirmació, branca, fusió i rebase
2. Crear el repositori contoso-reservas i clonar-lo
3. Autenticació: Credential Manager, testimonis i SSH
4. Estratègies de ramificació i la que tria Contoso
5. Sol·licituds d'incorporació de canvis
6. Directives de branca sobre main
7. Revisors automàtics per ruta: el CODEOWNERS d'Azure Repos
8. Etiquetes i versionat semàntic
9. .gitignore i l'error de pujar un secret
10. Migrar el repositori local conservant l'historial
11. Git LFS per als recursos gràfics pesats
12. Comparació amb GitHub Repos
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Aquesta no és una lliçó de Git, però hi ha quatre conceptes sense els quals la resta no s'entén. Una confirmació (commit) és una instantània completa del projecte, identificada per un resum criptogràfic i que apunta a la confirmació anterior: la història d'un repositori és una cadena d'instantànies, no una llista de diferències. Una branca és només un punter mòbil a una confirmació —crear-ne una és escriure un fitxer de 41 bytes—, i per això el flux de treball modern crea i destrueix branques constantment.

Fusió (merge) i rebase són dues formes d'incorporar la feina d'una branca a una altra, i la diferència importa:

La regla d'or del rebase: només sobre la teva branca personal i abans que altres hi treballin. Rebasar main reescriu la història de tothom i és la manera més ràpida de fer-li malbé el dia a l'equip.

Contoso crea quatre repositoris al projecte, amb el criteri «un artefacte desplegable, un repositori»:

Hi ha tres maneres que el teu Git local s'autentiqui contra Azure Repos, i no són equivalents:

Git Credential Manager ve inclòs amb les instal·lacions recents de Git i respecta l'accés condicional i l'MFA de 04-01: la sessió del portàtil d'en Diego caduca quan ho diu la política d'Entra ID, no quan a algú se li acudeixi. Els testimonis d'accés personal són la font més comuna d'incidents de seguretat a Azure DevOps. Si n'has de fer servir un: concedeix-li només els àmbits necessaris (Code (read) per a una eina que només llegeix) i mai Full access; posa-li la caducitat més curta viable; guarda'l a kv-contoso-pro i no en un fitxer de configuració; i tingues present que un PAT hereta tots els permisos de qui el va crear, així que el d'un administrador és una clau mestra.

Per a les canalitzacions, cap d'aquestes tres: faran servir la federació d'identitat de càrrega de treball de les connexions de servei de 05-01. La coherència és la mateixa que al mòdul 4: si hi ha una manera d'autenticar-se sense secret, és la que es fa servir.

Contoso tria branca de característica amb Trunk-Based per tres raons concretes: només hi ha una versió viva —la que és a Internet—, així que GitFlow resoldria un problema que Contoso no té cobrant-ne la complexitat igualment; l'auditoria PCI DSS exigeix revisió dels canvis, cosa que descarta el trunk-based pur sense sol·licituds de canvi; i les branques curtes ataquen directament la seva pitjor mètrica DORA, el temps de lliurament del canvi. Convenció de noms acordada: feature/<id>-<descripcio>, bugfix/<id>-<descripcio> i hotfix/<id>-<descripcio>, sempre amb l'identificador de l'element de treball al davant.

La regla que fa que això funcioni: una branca oberta més de dos dies és un senyal d'alarma. Si la feina és més gran, es parteix en increments fusionables a main sense activar-se encara, amb les marques de característica de 05-04.

Una sol·licitud d'incorporació de canvis (pull request) proposa fusionar una branca en una altra i obre una conversa sobre ella. És el mecanisme central de qualitat i, de passada, el registre documental que demanava l'auditor a 05-01.

--delete-source-branch true esborra la branca en completar-se: sense això, d'aquí a sis mesos hi haurà dues-centes branques mortes i ningú no sabrà quines continuen vives. --squash true s'explica a l'apartat següent.

Contoso defineix una plantilla de descripció a .azuredevops/pull_request_template.md, que Azure Repos precarrega a cada sol·licitud nova:

Quatre pràctiques separen una revisió útil d'un tràmit. Sol·licituds petites: per damunt de 400 línies la qualitat de la revisió cau en picat i s'aprova per cansament, mentre que una de 60 línies rep comentaris reals. Canvis suggerits: Azure Repos permet proposar el text exacte des del comentari, i qui el rep l'aplica amb un clic. Comentar el codi, no la persona: «aquesta consulta fa una crida per seient» en lloc de «has fet un N+1». I sobretot, la conversa és documentació: quan la Marta pregunta «per què 90 segons de memòria cau i no 300?» i en Diego respon amb la dada del proveïdor de tarifes, aquesta resposta queda associada al canvi per sempre. És la millor documentació d'arquitectura que existeix, perquè ningú no s'ha de recordar d'escriure-la a part.

Aquí és on l'acord verbal es converteix en regla aplicada. Una directiva de branca és una condició que s'ha de complir per poder completar una sol·licitud d'incorporació de canvis. Contoso protegeix main amb sis:

Tres detalls que la gent passa per alt. --reset-on-source-push true: si després d'aprovar arriben confirmacions noves, les aprovacions s'anul·len —sense això es pot aprovar un canvi de dues línies i colar-ne després cinc-centes—. --valid-duration 720: la compilació caduca a les 12 hores, cosa que impedeix fusionar validat contra un main que ja era una altra cosa. I la combinació en una confirmació, que fa que cada sol·licitud aparegui a main com una única confirmació neta: la història passa a ser la llista de canvis funcionals lliurats, justament el que vol llegir qui investiga una incidència.

Les directives s'apliquen també als administradors, i aquesta és la seva gràcia. Existeix l'opció de concedir «ometre directives», i la resposta correcta gairebé sempre és no concedir-la: si cal saltar-se el procés per una urgència, és que el procés està mal calibrat. Per a les urgències reals, Contoso manté branques hotfix/* amb la seva pròpia directiva d'un sol revisor, passant per la mateixa canalització.

A GitHub, un fitxer CODEOWNERS assigna propietaris per carpeta. Azure Repos fa el mateix amb la directiva de revisors inclosos automàticament, configurada per ruta —no en un fitxer del repositori, sinó a la mateixa directiva—:

Els grups són els mateixos del mòdul 4, amb la qual cosa la gestió de persones continua estant en un únic lloc. L'efecte pràctic: en Diego ja no pot canviar l'esquema de db-reservas sense que un DBA se n'assabenti, i no perquè li ho hagin prohibit, sinó perquè la fusió no es completa.

Una etiqueta (tag) marca una confirmació concreta amb un nom permanent. És el que permet respondre a «quin codi exacte és la versió 2.5.0 que hi ha en producció».

Contoso fa servir versionat semàntic MAJOR.MENOR.PEDAÇ:

A 05-05 el número de versió dels paquets es generarà automàticament des de la canalització, i a 05-04 l'etiqueta es crearà sola en desplegar en producció, de manera que la correspondència entre etiqueta i entorn no depengui que ningú l'escrigui a mà.

El fitxer .gitignore indica què no ha d'entrar mai al repositori:

Ara l'error greu. En Diego confirma per accident un appsettings.json amb la cadena de connexió de sql-contoso-reservas-dev i la clau de la passarel·la de pagament. Ho descobreix al cap de deu minuts i esborra el fitxer a la confirmació següent. El secret continua compromès, perquè la història de Git és immutable i cada confirmació conserva el contingut complet: qualsevol que hagi clonat el repositori —o qualsevol còpia de seguretat, o qualsevol registre de compilació— té el valor. Esborrar-lo després no l'elimina, només l'amaga de la vista superficial.

El procediment correcte, per ordre estricte:

1. Rotar el secret immediatament. És l'única cosa que de debò tanca el forat: generar una clau nova de la passarel·la de pagament, actualitzar-la a kv-contoso-pro i deixar l'anterior sense valor. Tota la resta és neteja, no remei.
2. Comprovar l'ús. Revisar els registres d'accés del recurs per si la credencial es va fer servir des de fora; per a això serveixen les alertes de Microsoft Defender for Cloud de 04-05.
3. Netejar la història amb git filter-repo, coordinant un reclonatge amb tot l'equip. És destructiu i disruptiu, i en repositoris grans moltes vegades no compensa.
4. Prevenir la reincidència: .gitignore correcte, revisió a la sol·licitud de canvis i detecció automàtica.

Azure DevOps inclou detecció de secrets que analitza les confirmacions i avisa —i amb GitHub Advanced Security for Azure DevOps, de pagament, pot bloquejar l'enviament abans que el secret entri—. Un ganxo local o un pas d'anàlisi a la canalització atura la majoria dels casos restants.

La solució de fons ja la coneixes del mòdul 4: si no hi ha secrets, no es poden filtrar. L'aplicació de Contoso s'autentica contra SQL i contra l'emmagatzematge amb identitat administrada, i el poc que continua sent secret de debò —pasarela-pago-clave, token-meteo— viu a kv-contoso-pro i es referencia amb @Microsoft.KeyVault(...). El fitxer de configuració del repositori conté noms de recursos, mai credencials.

El repositori d'en Diego té tres anys d'història que no es poden perdre: és el que permet saber per què es va escriure cada línia. La migració ho conserva tot:

Abans de donar la migració per bona, dues coses: fixar main com a branca predeterminada i deixar el repositori antic en només lectura. Si continua acceptant enviaments, apareixeran dues històries divergents i algú perdrà feina.

El web inclou imatges de destinacions, mapes de cabina en alta resolució i vídeos de capçalera: binaris de desenes de megabytes. Git guarda cada versió completa de cada binari per sempre, així que un mapa de 30 MB modificat vint vegades són 600 MB permanents que tothom es descarrega en clonar. Git LFS (Large File Storage) substitueix el binari a la història per un punter de text i guarda el contingut a part, descarregant només la versió que necessites:

Dos advertiments: LFS s'ha de configurar abans de pujar els binaris (fer-ho després exigeix reescriure la història), i el seu emmagatzematge consumeix la quota facturable d'Artifacts de l'organització. Els recursos que el web serveix en producció viuen en un compte d'emmagatzematge darrere de la CDN de 02-06; al repositori només hi va el que forma part del codi font.

A la pràctica, l'experiència de revisió de GitHub sol resultar més agradable, mentre que les directives d'Azure Repos són més granulars. Contoso es queda a Azure Repos per la integració amb Boards i la traçabilitat que exigeix PCI DSS.

• Branques de llarga durada. Una branca de tres setmanes garanteix una fusió dolorosa. Si la feina és gran, es parteix en increments fusionables i s'oculta amb marques de característica.
• Rebasar una branca compartida. Reescriu la història de tothom. Rebase només a la teva branca i abans que ningú més hi treballi.
• Sol·licituds de canvi enormes i aprovacions sense llegir. A partir de 400 línies la revisió és un tràmit; i la directiva de dos revisors no val res si la segona signatura és automàtica. Millor cinc sol·licituds de 80 línies i una revisió honesta.
• Creure que esborrar la confirmació esborra el secret. No l'esborra. Rotar sempre, i després netejar.
• Concedir «ometre directives» als administradors. Converteix la protecció en un suggeriment. Si hi ha urgències, configura una directiva pròpia més laxa sobre hotfix/*.
• Pujar binaris pesats sense LFS. El repositori creix per sempre i el clonatge es fa insuportable; i recorda que LFS consumeix quota facturable.
• Consell: escriu missatges de confirmació amb un títol breu en imperatiu, un cos que expliqui per què —el què ja es veu al diff— i la referència AB#<id>.
• Consell: activa l'esborrat automàtic de la branca d'origen en completar la sol·licitud i purga periòdicament les branques sense activitat.

L'equip de Contoso Millas (centro-coste=CC-2077) manté un portal web i, a més, una aplicació mòbil la versió 3.2 de la qual continua instal·lada als telèfons dels clients i rep correccions mentre es desenvolupa la 4.0.

1. Quina estratègia de ramificació correspon a cadascun dels dos productes, i per què són diferents?
2. Per al portal, defineix les directives de branca que posaries a main amb la seva justificació.
3. Com gestionaries una correcció urgent al portal un dissabte, sense saltar-te el procés?

En Diego confirma i envia a main un fitxer appsettings.json que conté la clau de la passarel·la de pagament i la cadena de connexió de sql-contoso-reservas-pro. Se n'adona vint minuts després. Ja hi ha dos companys que han fet git pull.

1. Enumera les accions per ordre, indicant quina tanca realment el risc.
2. Per què no n'hi ha prou amb una confirmació que esborri el fitxer, ni amb revertir-la?
3. Quines tres mesures tècniques evitarien que torni a passar, i quina decisió d'arquitectura del mòdul 4 ho fa gairebé impossible?

Contoso vol que: (a) ningú no fusioni a main sense dues aprovacions i sense element de treball; (b) tot canvi sota /src/Contoso.Reservas.Datos/Migraciones/ el revisi Contoso-DBA-Reservas; (c) la història de main quedi lineal; (d) una compilació aprovada fa tres dies no serveixi per fusionar avui.

1. Indica quina directiva concreta resol cada punt i escriu l'ordre de la CLI per a (b).
2. Què passa si la Marta, que és administradora del projecte, intenta fusionar sense complir-les?

Solució 1:

1. Per al portal, branca de característica amb Trunk-Based: una sola versió viva (la desplegada), desplegament freqüent i branques d'un o dos dies. Per a l'aplicació mòbil, un flux tipus GitFlow o com a mínim branques release/3.2 i release/4.0 de llarga durada, perquè hi ha dues versions vives simultàniament: la instal·lada als telèfons, que continua rebent pedaços, i la que s'està desenvolupant. La diferència no és de gust: al web tu controles quina versió executa el client; al mòbil, no.
2. Mínim de 2 revisors sense autoaprovació i amb reinici en enviar canvis; element de treball vinculat (traçabilitat); comentaris resolts; compilació amb validació amb caducitat de 12 hores; només combinació en una confirmació; i revisors automàtics per ruta per a infraestructura i esquema.
3. Branca hotfix/<id>-<descripcio> des de main, amb una directiva pròpia sobre el patró hotfix/* que exigeixi un sol revisor però mantingui la compilació amb validació i l'element de treball. Passa per la mateixa canalització i el mateix desplegament; l'única cosa que es relaxa és el nombre d'ulls, no l'automatització. Mai concedir «ometre directives».

Solució 2:

1. (a) Rotar la clau de la passarel·la de pagament i canviar la credencial de la base de dades —això i només això tanca el risc—; actualitzar el valor nou a kv-contoso-pro. (b) Revisar els registres d'accés i les alertes de Defender for Cloud per si hi va haver ús indegut. (c) Afegir el fitxer a .gitignore i eliminar-lo del seguiment. (d) Valorar reescriure la història amb git filter-repo i coordinar el reclonatge, atès que el repositori és privat i l'equip, petit. (e) Comunicar-ho al responsable de seguretat: és un incident, no una distracció.
2. Perquè la història de Git és immutable i cada confirmació desa el contingut complet: el valor continua sent recuperable en qualsevol clon, còpia de seguretat o registre de compilació. Una reversió afegeix una confirmació nova, no elimina l'anterior. Mentre la credencial continuï sent vàlida, continua compromesa.
3. Detecció de secrets activada al repositori; un ganxo de precommit o un pas d'anàlisi a la canalització de CI; i .gitignore complet amb revisió obligatòria dels fitxers de configuració a la sol·licitud de canvis. La decisió d'arquitectura: autenticació amb identitat administrada —sense cadena de connexió amb contrasenya per filtrar— i el poc irreductible a Key Vault referenciat amb @Microsoft.KeyVault(...). Si no hi ha secret al codi, no hi ha secret per pujar.

Solució 3:

1. (a) approver-count amb --minimum-approver-count 2 --creator-vote-counts false, més work-item-linking. (b) required-reviewer amb el seu filtre de ruta i el grup d'Entra ID: az repos policy required-reviewer create --repository-id $REPO_ID --branch main --blocking true --enabled true --required-reviewer-ids "Contoso-DBA-Reservas" --path-filter "/src/Contoso.Reservas.Datos/Migraciones/*". (c) merge-strategy permetent només --allow-squash true. (d) policy build amb --valid-duration 720, que invalida les compilacions de més de 12 hores.
2. No pot. Les directives s'apliquen igual als administradors del projecte llevat que es concedeixi explícitament el permís d'ometre directives, cosa que Contoso no fa. Això és justament el que converteix l'acord de l'equip en una regla real i el que satisfà l'auditor: no hi ha excepcions per càrrec.

El codi de Contoso Airlines ja no viu en un portàtil ni viatja per correu. Has repassat l'imprescindible de Git —confirmació, branca, fusió i rebase, amb la regla de no rebasar mai branques compartides—, has creat els quatre repositoris del projecte i has migrat el repositori local d'en Diego conservant els seus tres anys d'història, deixant l'origen antic en només lectura perquè no apareguin dues veritats. Saps autenticar-te amb Git Credential Manager com a opció per defecte, amb SSH quan convé i amb testimonis d'accés personal només quan no hi ha alternativa, sabent que un PAT hereta tots els permisos de qui el crea.

Has triat conscientment l'estratègia de ramificació: branca de característica amb Trunk-Based, amb branques de vida molt curta, perquè Contoso té una sola versió viva, necessita revisió per PCI DSS i la seva mètrica DORA més feble és el temps de lliurament. I has convertit el procés de qualitat en una cosa que no depèn de la memòria de ningú: sol·licituds d'incorporació de canvis amb plantilla, revisors i conversa registrada —que és, de passada, la millor documentació d'arquitectura que tindrà l'equip—, i directives sobre main que exigeixen dues aprovacions sense autoaprovació, element de treball vinculat, comentaris resolts, compilació amb validació vigent i combinació en una sola confirmació, amb revisors automàtics per ruta que porten cada canvi d'esquema a Contoso-DBA-Reservas i cada plantilla a Contoso-Infraestructura. Saps etiquetar amb versionat semàntic, mantenir un .gitignore seriós i, sobretot, saps que un secret pujat s'ha de rotar: esborrar la confirmació no esborra res, i la solució de fons continua sent la del mòdul 4, no tenir secrets per filtrar.

Queda un cap solt molt visible. La directiva més important que has configurat —la compilació amb validació— apunta a una canalització que encara no existeix: avui ningú no comprova que el codi compila, que les proves passen o que no s'ha colat una errada evident abans de fusionar. A la lliçó següent, Azure Pipelines: integració contínua, construiràs aquesta canalització: agents allotjats i autoallotjats amb els seus costos reals, l'anatomia d'un azure-pipelines.yml explicada línia a línia, restauració, compilació, proves amb publicació de resultats i cobertura, anàlisi estàtica, memòria cau, plantilles reutilitzables per no repetir el mateix YAML a cada servei, i els secrets entrant des de Key Vault sense passar mai pel repositori. En acabar-la, la regla «main sempre compila» deixarà de ser una intenció per ser un fet verificat a cada canvi.