@@ -1198,6 +1198,32 @@ Això converteix una convenció organitzativa en una restricció tècnica. La ma
Per a equips de 2 persones amb molta comunicació, un procés formal pot semblar excessiu. Però com que github i gitlab ofereixen les pull/merge requests gairebé sense fricció, avui és habitual fer-les servir fins i tot en equips petits: combinades amb la validació automàtica (CI), són una de les pràctiques que més millora la qualitat del codi sense complicar gaire el flux de treball. A mesura que l'equip creix, passen de recomanables a imprescindibles.
### Rebase per mantenir la branca al dia
Tant el merge com el rebase combinen feina, però d'una manera molt diferent: el merge **conserva** les dues històries i les uneix amb un commit nou amb dos pares; el rebase **reescriu** els teus commits perquè quedin com si els haguessis escrit a sobre d'una altra base.
La intuïció: imagina els teus commits enganxats amb post-it. El merge els deixa on són i hi pinta una línia que els connecta amb l'altra branca. El rebase els despenja, mou la base de la branca fins a un altre punt, i els torna a enganxar a sobre. Com que el resultat són commits "nous" (mateix contingut, hashes diferents), val la regla d'or de [reescriure història](#per-què-reescriure-la): només sobre feina que encara **no has compartit**.
L'ús més habitual a la indústria és **posar al dia la teva branca de feina amb `main` sense merges intermedis**, abans de demanar-ne la revisió. Treballes a `feature/nova-funcio` i, mentrestant, `main` avança amb la feina d'altres companys. Si vas fent merge de `main` a la teva branca per estar al dia, deixes una bombolla de merge cada cop ("Merge branch 'main' into feature/nova-funcio") i acabes amb una història enrevessada que costa de revisar.
El rebase ho evita:
```bash
git switch feature/nova-funcio
git fetch
git rebase origin/main
```
És com si despengessis els teus commits, mouguessis la base de la branca fins a l'últim `main`, i els tornessis a aplicar un a un per damunt. El resultat és una història lineal i neta, com si haguessis començat la feature ara mateix.
**Per què val la pena**: hi ha tres beneficis que es combinen.
***Revisió neta**: el revisor veurà la teva feina com una llista de commits per damunt del `main` actual, sense soroll de manteniment.
***Integració primerenca**: desenvolupes contra el codi real d'ara, així que si `main` ha canviat el nom d'una funció, ha modificat una signatura o ha introduït un bug, ho descobreixes immediatament en local i no el dia del merge. _Compte_: el rebase només resol conflictes textuals; els [conflictes semàntics](#què-és-realment-un-conflicte) no els detecta, així que cal **tornar a passar els tests** després del rebase per confirmar que tot encaixa.
***Conflictes més suaus**: la quantitat total no canvia (vénen de tocar les mateixes línies), però l'experiència sí: els resols a poc a poc, amb el context d'un sol commit, i no en un únic xoc gran el dia del merge final. Quan el PR finalment s'integra, el merge a `main` és un fast-forward net.
> **Compte**: després d'un rebase, els commits són nous. Si ja havies pujat la branca, el següent push caldrà fer-lo amb `--force-with-lease`. Per això la regla d'or: si algun company ja treballa sobre la branca, parla-hi abans de reescriure-la.
## Bones pràctiques
### Missatges de commit
@@ -1338,7 +1364,7 @@ git pull origin main
Quan la teva branca local i la remota han divergit, `git pull` ha de combinar les dues històries, i pot fer-ho de dues maneres:
***Merge** (comportament per defecte): crea un commit de merge que uneix les dues línies. Conserva l'historial exacte, però hi deixa "bombolles" de merge com les que hem vist a l'[escenari amb conflicte](#escenari-amb-conflicte).
***Rebase**: reaplica els teus commits locals a sobre dels remots, deixant un historial lineal i més net.
***Rebase**: reaplica els teus commits locals a sobre dels remots, deixant un historial lineal i més net. És la mateixa idea que [Rebase per mantenir la branca al dia](#rebase-per-mantenir-la-branca-al-dia), aplicada al `pull`.
Des de git 2.27, si no has triat estratègia, `git pull` mostra un avís demanant-te que en configuris una. Les opcions habituals:
