Modulo 14 — Workflow di collaborazione

1. Workflow centralizzato

“Tutti su master/main” — il workflow più elementare possibile: un solo branch su cui lavora tutto il team.

Come va in pratica

Scenario con tre sviluppatori (Pamela, Forrest, David) che clonano lo stesso repo:

1. Forrest lavora sulla sua feature e pusha su GitHub senza problemi.

2. Pamela lavora sulla sua feature; quando prova a pushare:

   Failed to push. Updates were rejected because the tip of your
   current branch is behind its remote counterpart.
   Merge the remote changes (e.g. 'git pull') before pushing again.

3. Pamela fa pull, mergia il lavoro di Forrest, e solo dopo riesce a pushare.

4. David, prima di condividere i suoi commit (anche quelli “incerti” per una discussione), deve prima pullare e mergiare, poi pushare.

I problemi

• Tantissimo tempo in merge e conflitti, che crescono con la dimensione del team.
• Nessuno può sperimentare senza disturbare la codebase principale.
• Per collaborare su una feature insieme, l’unica via è pushare codice incompleto su master — e gli altri ereditano codice rotto.

2. Feature branches

“Non lavorare su master!” — tutto lo sviluppo nuovo avviene su branch separati:

• master/main viene trattato come la storia ufficiale del progetto;
• più persone possono collaborare sullo stesso feature branch condividendosi il lavoro;
• master resta pulito (finché qualcuno non combina pasticci).

Il feature branch parte da master e procede in parallelo: il branch principale non lo sente finché non viene mergiato.

Naming dei feature branch

Convenzione diffusa: nomi con slash, es. bug/fix-scroll, feature/login-form, feat/button/enable-pointer-events. Ogni team di solito ha le sue regole.

Scenario tipo

• David lavora su add-dark-theme (branch, non master).
• Per farla vedere a Pamela, pusha il feature branch su GitHub.
• Pamela (che lavora su animated-scroll) pulla il branch di David, guarda il codice, apporta miglioramenti, committa sullo stesso branch e pusha.
• David pulla le novità e continua.
• A lavoro finito, David mergia il branch in master e pusha: gli altri pullano gli aggiornamenti.

(In un’azienda reale non si mergia “quando sei contento”: esistono meccanismi di approvazione e revisione.)

3. Pull request

Le pull request sono una funzionalità di piattaforme come GitHub e Bitbucket, non di Git. Permettono di:

• segnalare al team che c’è lavoro da revisionare;
• approvare o rifiutare il lavoro di un branch;
• discutere e dare feedback sui commit.

Nella sostanza: “ho questa roba da mergiare in master… che ne dite?”

Il workflow

1. Lavora in locale su un feature branch.
2. Pusha il feature branch su GitHub.
3. Apri una pull request da quel branch.
4. Attendi approvazione e merge, discutendo sulla PR secondo le regole del team.

Conflitti nelle PR

Come per ogni merge possono esserci conflitti. Opzioni:

• risolverli nell’editor interattivo di GitHub;
• oppure in locale: git fetch origin → git switch my-new-feature → git merge master → risolvere i conflitti → git switch master → git merge my-new-feature → git push origin master.

GitHub fornisce comunque le istruzioni step-by-step nel caso le dimentichi.

Varianti di merge

• Squash & merge: riduce tutti i commit del feature branch a un singolo commit su master.
• Si può anche semplicemente chiudere la PR senza mergiare.

4. Fork & clone

Il workflow dei grandi progetti open source: migliaia di contributori, pochi maintainer.

L’idea

Invece di un unico repo centralizzato, ogni sviluppatore ha la propria copia su GitHub (il fork) oltre al repo principale. Si lavora sul fork e si aprono pull request verso l’originale.

Il fork non è una feature di Git: è implementata da GitHub (il pulsante “Fork” chiede alla piattaforma: “fammi la mia copia di questo repo”).

Il flusso completo

1. Fork del progetto originale su GitHub.

2. Clone del fork in locale — Git aggiunge automaticamente il remote origin puntato al tuo fork.

3. Aggiungi un remote al repo originale, di solito chiamato upstream:

   git remote add upstream https://github.com/progetto/originale.git

4. Lavora in locale (idealmente su un feature branch).

5. Push su origin (il fork): a upstream non hai i permessi di scrittura!

6. Apri una pull request dal fork verso il progetto originale.

7. I maintainer revisionano: chiedono modifiche o approvano e mergiano.

Restare aggiornati

Il progetto originale avanza (altri contributori): per recuperare, pull da upstream. Poi si continua a lavorare da al passo con tutti.

Riassunto in due parole

FORK → CLONE → REMOTE upstream → LAVORO → PUSH su origin → PR

---

Immagini: documentazione ufficiale di Git (git-scm.com, dal libro Pro Git di Scott Chacon), licenza CC BY-NC-SA 3.0.