A la lliçó anterior vam aprendre el mecanisme de configuració: git config, els seus nivells i la seva precedència. Ara toca aplicar-lo. Aquesta lliçó recorre els valors concrets que convé fixar en un equip abans de començar a treballar, i ho fa acompanyant l'Ana mentre prepara el seu portàtil per arrencar gestor-tasques.

Alguns d'aquests ajustos són obligatoris: sense ells Git es negarà a confirmar o ho farà amb dades incorrectes que després només s'arreglen reescrivint l'historial. D'altres són fortament recomanables perquè eviten sorpreses desagradables: quedar atrapat en un editor desconegut, que un company d'un altre sistema operatiu vegi tot el fitxer com a modificat, o que Git faci fusions inesperades en integrar canvis.

En acabar, l'equip de l'Ana quedarà llest i tancarem el mòdul enllaçant amb el mòdul 2, on per fi crearà el repositori.

1. La identitat: user.name i user.email
2. La branca per defecte: init.defaultBranch
3. L'editor: core.editor
4. Finals de línia: core.autocrlf i core.eol
5. Comportament en integrar: pull.rebase
6. Comportament en enviar: push.default
7. Credencials: credential.helper
8. Color i idioma de la sortida
9. Taula resum d'ajustos recomanats
10. Comprovació final de l'equip de l'Ana

És l'únic ajust veritablement obligatori. Cada confirmació registra qui la va fer, i Git es nega a crear-ne cap si no sap qui ets.

Desglossament:

• --global escriu a ~/.gitconfig, de manera que s'aplica a tots els repositoris de l'Ana. És el que toca per a la identitat.
• user.name és el teu nom tal com apareixerà a l'historial. Fes servir el teu nom real i complet: és el que veuran els teus companys durant anys a cada línia de l'historial. Res no impedeix fer servir un àlies, però dificulta identificar autories.
• user.email és el correu associat a la confirmació. És el camp que les plataformes fan servir per vincular una confirmació amb un compte d'usuari: si el correu no coincideix amb cap de registrat a GitHub o GitLab, la confirmació apareixerà sense foto de perfil ni enllaç.

En intentar confirmar, Git mostra un error explícit:

En algunes configuracions antigues, Git no fallava i endevinava una identitat a partir del nom d'usuari i del nom de la màquina, produint autors com [email protected]. Aquest comportament està desaconsellat i desactivat per defecte en versions modernes, precisament perquè generava historials amb autories inservibles.

L'autor forma part de l'objecte commit, i ja vam veure a El Model de Dades de Git que el hash es calcula sobre aquest contingut. Canviar l'autor d'una confirmació existent significa crear una confirmació nova i reescriure tot l'historial posterior. Si aquest historial ja està compartit, el problema es multiplica.

Traducció pràctica: configura la identitat abans de la teva primera confirmació, no després.

Si publiques a GitHub i no vols exposar el teu correu real, la plataforma ofereix una adreça de reenviament del tipus [email protected]. Es configura igual:

Les confirmacions continuen vinculant-se al teu compte, però el teu correu real no queda a l'historial públic. Recorda que l'historial és permanent: un correu confirmat i publicat ja no es pot retirar sense reescriure.

Com vam veure a Configurant Git, això es resol amb configuració local o, millor, amb includeIf. L'Ana ja té la seva carpeta ~/personal/ preparada per a això.

Quan es crea un repositori, Git crea automàticament una primera branca. Històricament s'anomenava master; des del 2020 l'estàndard de facto del sector és main, adoptat per GitHub, GitLab i la majoria de projectes nous.

Sense aquest ajust, Git continua fent servir master i mostra un avís llarg cada vegada que es crea un repositori, recordant que el nom per defecte està subjecte a canvi. Fixar-lo elimina l'avís i, sobretot, evita la incoherència de tenir repositoris amb master en local i main al servidor.

Dos matisos importants:

• Només afecta els repositoris nous. Els ja existents conserven el nom que tinguessin.
• No reanomena res. Si treballes en projectes antics amb master, continuaran dient-se així i no hi ha cap problema.

Git obre un editor de text en diverses situacions: en escriure un missatge de confirmació llarg, en resoldre un rebase interactiu, en editar la configuració amb --edit. Si no es configura, fa servir el valor de les variables d'entorn GIT_EDITOR, VISUAL o EDITOR, i a manca de totes elles, Vim a la majoria de sistemes Unix.

Aquest últim cas és un clàssic: un principiant executa una ordre, apareix una pantalla blava incomprensible i no aconsegueix sortir-ne. (Per si et passa: se'n surt amb Esc, després :q! i Retorn per descartar, o :wq per desar.)

Configura l'editor que ja sàpigues fer servir:

La part crítica en els editors gràfics és l'opció d'espera:

• --wait a VS Code, -w a Sublime.
• Sense ella, l'editor s'obre i retorna el control a Git immediatament, així que Git creu que has acabat i rep un fitxer buit. El resultat és un missatge de confirmació en blanc i l'operació avortada.

L'Ana fa servir VS Code per programar, així que:

Requisit a macOS per a VS Code. L'ordre code ha d'estar disponible al PATH. S'activa des del mateix VS Code amb la paleta d'ordres (Cmd+Shift+P) → Shell Command: Install 'code' command in PATH.

Aquest és l'ajust que més problemes causa en equips amb sistemes operatius mixtos, i gestor-tasques és exactament aquest cas: l'Ana a Linux, en Bruno a macOS i la Carla a Windows.

Els sistemes operatius marquen el final de línia de manera diferent:

Per a Git, que compara continguts byte a byte, un fitxer amb LF i el mateix fitxer amb CRLF són continguts diferents, amb hashos diferents. Sense tractament, passa això: la Carla clona el projecte a Windows, el seu editor converteix els finals de línia en desar i de sobte Git li indica que els quatre fitxers estan modificats de dalt a baix, encara que no hagi canviat ni una paraula. La seva confirmació següent canviarà el 100 % de les línies i farà il·legible qualsevol revisió de codi.

La convenció universal és desar sempre LF dins del repositori i convertir al vol als sistemes que ho necessitin.

Què fa cada valor exactament:

Amb aquesta configuració, el repositori sempre conté LF, la Carla veu CRLF al seu disc com espera Windows, i l'Ana i en Bruno veuen LF. Ningú no percep canvis falsos.

És un ajust complementari que defineix quin final de línia s'escriu al disc per als fitxers marcats explícitament com a text:

Valors possibles: lf, crlf o native (el del sistema, que és el valor per defecte). Només entra en joc quan core.autocrlf és false i hi ha atributs de fitxer definits.

core.autocrlf és una configuració personal: depèn que cada membre de l'equip l'hagi posada bé a la seva màquina. La solució robusta és un fitxer .gitattributes versionat dins del projecte, que imposa la norma a tothom independentment de la seva configuració:

Aquest fitxer es tracta en profunditat al mòdul 8, a la lliçó Atributs de Fitxer amb .gitattributes. Menciona'l aquí com la meta a la qual arribar; core.autocrlf és la xarxa de seguretat individual mentrestant.

Quan descarregues canvis del remot i la teva branca local també ha avançat, Git ha d'integrar les dues línies. Hi ha tres maneres de fer-ho, i des de la versió 2.27 Git es nega a triar per tu: mostra un avís i exigeix que configuris quina prefereixes.

Recomanació per començar: pull.ff only. És l'opció més conservadora: quan no hi ha conflicte de línies de desenvolupament, integra sense soroll; quan n'hi ha, s'atura i et diu que decideixis. Així aprens a reconèixer la situació en lloc que Git prengui una decisió silenciosa que encara no entens.

Molts equips experimentats prefereixen pull.rebase true per mantenir l'historial lineal. És una elecció legítima, però implica entendre el rebase i els seus riscos, que es tracten al mòdul 5. Quan hi arribis podràs canviar el valor amb coneixement de causa.

Ajust complementari, molt recomanable si més endavant actives el rebase automàtic:

Desa temporalment els canvis sense confirmar abans del rebase i els restaura després, evitant l'error "no pots fer rebase amb canvis pendents". El desament temporal (stash) es tracta al mòdul 5.

Determina quines branques s'envien quan executes git push sense arguments.

simple és el valor per defecte des de Git 2.0 i el recomanat: envia només la branca actual, i únicament si el seu nom coincideix amb el de la branca remota que segueix. És el comportament menys sorprenent.

Un complement molt pràctic:

Disponible des de Git 2.37, fa que en enviar per primer cop una branca nova, Git configuri automàticament la seva branca de seguiment en lloc de fallar amb el missatge fatal: The current branch X has no upstream branch. Estalvia escriure git push --set-upstream origin <branca> cada vegada que es crea una branca, cosa que en un flux de treball per branques passa a diari.

Els remots i l'enviament de canvis són el contingut del mòdul 4; aquí només deixem el terreny preparat.

Quan treballis amb repositoris remots per HTTPS, Git demanarà usuari i contrasenya —en realitat, un token d'accés— a cada operació. Un gestor de credencials les desa de manera segura per no haver-les de repetir.

Advertència sobre store. Desa les credencials sense xifrar, en text llegible. Apareix en molts tutorials per ser la més senzilla i és una mala pràctica de seguretat. El mòdul 8 dedica una lliçó a les millors pràctiques de seguretat.

L'alternativa a tot això és fer servir SSH en lloc d'HTTPS, amb claus criptogràfiques en lloc de contrasenyes. És el que solen preferir els equips, i es tracta al mòdul 4, a la lliçó d'autenticació amb repositoris remots.

auto activa el color quan la sortida va a un terminal i el desactiva quan va a un fitxer o a un altre programa, evitant que apareguin codis d'escapada als bolcats. Sol venir actiu per defecte a Git modern, però fixar-lo explícitament no està de més.

Es pot afinar per ordre:

I personalitzar colors concrets, amb la sintaxi <color de text> <color de fons> <atribut>:

És opcional i qüestió de gust; amb color.ui auto n'hi ha prou per treballar còmodament.

Git tradueix els seus missatges a l'idioma del sistema si la traducció està disponible. En un sistema en català veuràs missatges com:

Aquí hi ha una decisió pràctica a prendre. La recomanació d'aquest curs és deixar la sortida de Git en anglès, per tres raons concretes:

1. Gairebé tota la documentació, els manuals i les respostes que trobaràs en cercar un missatge d'error són en anglès. Cercar el text exacte d'un error traduït rarament dona resultats.
2. Les traduccions són parcials: veuràs missatges barrejats en dos idiomes.
3. Els exemples d'aquest curs i de qualsevol material tècnic mostren la sortida en anglès.

Per forçar-ho:

Si prefereixes mantenir la resta del sistema en català i afectar només Git, existeix una variable específica:

A Windows, Git Bash fa servir l'idioma de l'instal·lador; la variable d'entorn funciona igualment si es defineix al fitxer d'arrencada del shell.

L'Ana decideix deixar-ho en anglès perquè els missatges coincideixin amb la documentació.

Aquest és el conjunt complet que l'Ana aplica al seu portàtil, amb la justificació de cadascun:

I aquí està tot junt, tal com l'Ana ho executa al seu portàtil Linux. Pots copiar aquest bloc canviant el nom, el correu i l'editor:

El fitxer ~/.gitconfig resultant:

Dotze línies de configuració que eviten la majoria de les ensopegades habituals dels primers mesos.

Abans de donar l'equip per llest, l'Ana verifica que tot sigui al seu lloc. Aquestes són les ordres de comprovació, amb la sortida esperada.

Si algun dels dos no retorna res, falta per configurar i Git no permetrà confirmar.

Mostra cada clau amb el fitxer del qual procedeix. És el moment de detectar errates: repassa que els noms de clau siguin exactament els de la taula de l'apartat 9.

S'ha d'obrir el teu editor amb el contingut de ~/.gitconfig. Tanca'l sense desar. Si s'obre Vim en lloc del teu editor, o si l'ordre retorna el control instantàniament sense obrir res, revisa core.editor i comprova que inclou l'opció d'espera (--wait, -w).

Amb les set caselles marcades, el portàtil de l'Ana està llest.

• Començar a confirmar sense configurar la identitat. És l'error més costós del mòdul, perquè corregir l'autor de confirmacions ja fetes obliga a reescriure l'historial. Configura user.name i user.email abans de crear el teu primer repositori.
• Configurar un editor gràfic sense l'opció d'espera. code en lloc de code --wait fa que Git rebi un missatge buit i avorti l'operació. El símptoma és "l'editor s'obre i Git diu que el missatge està buit".
• Ignorar els finals de línia fins que l'equip és mixt. Quan la Carla entra al projecte des de Windows sense core.autocrlf, la seva primera confirmació apareix canviant el 100 % de les línies de tots els fitxers. Configura-ho des del principi i, tan bon punt hi hagi un projecte compartit, afegeix-hi un .gitattributes (mòdul 8).
• Fer servir credential.helper store. Desa les contrasenyes en text pla a la teva carpeta personal. Fes servir el gestor natiu del teu sistema o, millor, SSH.
• Escriure la configuració al nivell local sense voler. Com vam veure a la lliçó anterior, ometre --global escriu a .git/config. Per a la identitat i les preferències personals, el nivell correcte és sempre el global.
• Copiar blocs de configuració d'internet sense entendre'ls. Apareixen ajustos exòtics que canvien comportaments importants i després produeixen efectes difícils d'explicar. Afegeix opcions d'una en una, sabent què fa cadascuna.
• Consell: revisa la configuració en canviar de màquina o d'empresa. Un portàtil corporatiu pot portar valors al nivell de sistema (proxies, gestors de credencials, plantilles) que no esperes. git config --list --show-origin --show-scope és el primer que convé mirar.
• Consell: versiona el teu ~/.gitconfig. És un fitxer de text petit que representa molts ajustos acumulats. Desar-lo en un repositori propi et permet replicar el teu entorn en qualsevol màquina nova en un minut.

Aplica a la teva màquina la configuració completa recomanada, adaptant-la al teu cas:

1. Fixa la teva identitat amb el teu nom real i el teu correu.
2. Fixa main com a branca per defecte.
3. Configura l'editor que sàpigues fer servir, amb l'opció d'espera si és gràfic.
4. Configura core.autocrlf amb el valor correcte per al teu sistema operatiu.
5. Fixa pull.ff only, push.default simple i color.ui auto.
6. Executa les cinc comprovacions de l'apartat 10 i anota la sortida de cadascuna.
7. Mostra el contingut resultant del teu ~/.gitconfig i compara'l amb el de l'Ana.

L'equip de gestor-tasques és heterogeni:

• Ana: Ubuntu, editor VS Code, correu [email protected].
• Bruno: macOS, editor Vim, correu [email protected]. A més vol que les credencials HTTPS es desin al Clauer del sistema.
• Carla: Windows 11 amb Git Bash, editor Notepad++, correu [email protected]. Treballa també en projectes d'una altra empresa que desa a C:\Users\carla\empresa\ i que han de fer servir el correu [email protected].

Escriu la seqüència d'ordres de configuració per a cadascun. Presta especial atenció a core.autocrlf a cada sistema i, per a la Carla, resol el cas dels dos correus fent servir el que has après a la lliçó Configurant Git.

Un company acabat d'incorporar es queixa de tres problemes diferents i t'ensenya el resultat de git config --global --list:

Les seves queixes són:

1. "Git no em deixa fer commits, diu que no sap qui soc."
2. "Quan escric un missatge llarg, s'obre VS Code però Git diu immediatament que el missatge està buit."
3. "En integrar canvis del remot, les meves confirmacions canvien d'identificador i el meu company diu que li he esguerrat l'historial."

Per a cada queixa: identifica la causa exacta en aquesta configuració, escriu l'ordre que la corregeix i explica breument el perquè. Indica també si hi ha alguna cosa en aquesta llista que no sigui un problema encara que ho sembli.

Solució a l'Exercici 1

Exemple de resolució per a una usuària a Linux anomenada Marta Pons:

El punt 4 és el que més varia: a Windows ha de ser true, no input. El punt 3 només necessita l'opció d'espera si l'editor és gràfic (code --wait, subl -n -w); els editors de terminal com nano o vim bloquegen per naturalesa.

Solució a l'Exercici 2

Ana — Ubuntu

Bruno — macOS

core.autocrlf és input igual que a Linux, perquè macOS també fa servir LF. Vim no necessita opció d'espera.

Carla — Windows 11

I per al segon correu, editant ~/.gitconfig (que a Windows és a C:\Users\carla\.gitconfig) per afegir-hi al final:

Amb el fitxer ~/.gitconfig-altraempresa:

Tres detalls importants a la solució de la Carla:

• Es fa servir gitdir/i: en lloc de gitdir: perquè el sistema de fitxers de Windows no distingeix majúscules i la variant insensible evita fallades per diferències de capitalització a la ruta.
• La ruta s'escriu amb barres normals (/), no invertides, encara que sigui Windows: Git fa servir sempre barres normals als seus fitxers de configuració.
• La ruta acaba en /, requisit perquè la coincidència sigui recursiva.

Comprovació des de qualsevol repositori de C:\Users\carla\empresa\:

Solució a l'Exercici 3

Queixa 1 — "no sap qui soc"

• Causa: la clau està mal escrita. Diu user.emial en lloc de user.email. Com que Git no valida els noms de clau, la va desar sense protestar i user.email continua sense estar definit.
• Correcció:

Queixa 2 — "el missatge està buit"

• Causa: core.editor=code no porta l'opció --wait. VS Code s'obre i retorna el control a Git immediatament, així que Git llegeix el fitxer de missatge abans que s'hi hagi escrit res i avorta per missatge buit.
• Correcció:

Queixa 3 — "li he esguerrat l'historial"

• Causa: pull.rebase=true reaplica les confirmacions locals sobre les descarregades, cosa que crea confirmacions noves amb hash diferent, com vam veure a El Model de Dades de Git. Si aquestes confirmacions ja estaven compartides, el company es troba amb historials divergents. No és un valor "incorrecte" en si mateix —molts equips el fan servir deliberadament— però no és apropiat per a algú que comença i encara no distingeix quan és segur.
• Correcció per a un principiant:

Així, si en integrar apareix divergència, Git s'atura i avisa en lloc de reescriure res. Quan el company arribi al mòdul 5 podrà tornar a activar el rebase amb criteri.

El que NO és un problema: la línia init.defaultbranch=main. Les claus de configuració no distingeixen majúscules ni a la secció ni al nom, així que init.defaultbranch i init.defaultBranch són exactament la mateixa clau. De fet, Git normalitza el nom a minúscules en llistar la configuració, així que aquesta línia apareixerà així encara que s'escrivís amb la majúscula. Funciona perfectament.

El portàtil de l'Ana està llest. Hem fixat els dos valors obligatoris —user.name i user.email, que identifiquen l'autor a cada confirmació i que convé encertar abans de la primera, perquè corregir-los després obliga a reescriure l'historial— i una dotzena d'ajustos molt recomanables: init.defaultBranch=main per alinear-se amb l'estàndard del sector, core.editor per no quedar atrapat en un editor desconegut, core.autocrlf perquè un equip amb Linux, macOS i Windows no generi canvis falsos a cada fitxer, pull.ff only perquè Git no integri mai de manera inesperada, push.default i push.autoSetupRemote perquè enviar canvis sigui predictible, un gestor de credencials segur i el color de la sortida.

Amb això tanquem el mòdul 1. En aquestes sis lliçons hem recorregut el camí complet des del desconeixement fins a un entorn preparat:

• Per què existeix Git i què el diferencia dels sistemes centralitzats, amb gestor-tasques com a projecte guia.
• Com instal·lar-lo a Linux, macOS i Windows, i per què farem servir la línia d'ordres.
• El vocabulari: tres zones, tres estats, referències, remots, fusió i rebase.
• El model de dades: blobs, arbres, commits i etiquetes enllaçats per hash, i la immutabilitat que se'n deriva.
• El mecanisme de configuració: tres nivells, precedència i perfils condicionals.
• Els valors concrets que deixen l'equip llest per treballar.

Saps què és Git, el tens instal·lat, entens com desa la informació i està configurat a la teva mida. Només falta fer-lo servir.

Al mòdul 2: Operacions Bàsiques de Git comença la feina de veritat. L'Ana convertirà per fi la seva carpeta gestor-tasques en un repositori amb Creant un Repositori, aprendrem a clonar un repositori existent, recorrerem el flux de treball bàsic que connecta les tres zones que ja coneixes, i practicarem a fons com preparar i confirmar canvis, inspeccionar diferències i llegir l'historial. Tot el que has après aquí sobre les tres zones, els objectes i les referències començarà a veure's en acció.