Lezione 19 di 35

Git 19

🔀 Git & GitHub · Modulo 4 · Lezione 19

Fork e open source 🍴

Contribuire ai progetti degli altri · Fork · Upstream · Il workflow dell’open source contributor

⏱️ Durata stimata: 75–90 min 📊 Livello: Intermedio-Avanzato (Modulo 4) 🔧 Strumenti: Browser · Terminale · Account GitHub 📋 Prerequisiti: Modulo 3 (PR, push, pull, review)

🍴 Finora hai collaborato su repository a cui avevi accesso diretto. Ma come contribuisci a un progetto di cui non sei collaboratore? Ad esempio un progetto open source, il repository del prof, o il progetto di un’altra classe? La risposta è il fork: crei una copia personale del repository, ci lavori sopra, e poi proponi le tue modifiche tramite una Pull Request. È il meccanismo che ha reso GitHub la piattaforma dell’open source.

🎯 Obiettivi della lezione

Capire la differenza tra fork e clone
Creare un fork di un repository
Configurare il remoto upstream per restare sincronizzato con il progetto originale
Eseguire il workflow completo: fork → clone → branch → push → PR
Mantenere il fork aggiornato con il repository originale
Conoscere le basi della cultura open source

📖 1. Teoria

1.1 — Il problema: non hai i permessi di push

Nel Modulo 3 hai lavorato su repository dove sei collaboratore — hai i permessi per fare push e creare branch. Ma ci sono migliaia di progetti su GitHub a cui vorresti contribuire e dove non hai i permessi: librerie che usi, strumenti open source, il template del prof.

Collaboratore diretto (Modulo 3)

Hai i permessi sul repository. Puoi creare branch direttamente e fare push. Il repo è il tuo o sei stato aggiunto come collaboratore.

git push origin feature/x ✅

Contributore esterno (con fork)

Non hai permessi sul repository. Non puoi fare push direttamente. Devi prima creare una copia personale (fork), lavorarci sopra, e poi proporre le modifiche con una PR dall’esterno.

fork → clone → branch → push (al fork) → PR (al repo originale)

1.2 — Cos’è un fork

Un fork è una copia completa di un repository nel tuo account GitHub. Il fork è un repository a tutti gli effetti: ha la stessa storia, gli stessi file, gli stessi branch — ma è tuo, quindi puoi fare push, creare branch, modificare quello che vuoi senza toccare il progetto originale.

Fork: la relazione tra i repository

👤

Repository originale

prof/progetto-classe
Tu non hai i permessi di push

fork →

← PR

🍴

Il tuo fork

tuousername/progetto-classe
Hai tutti i permessi

clone ↓

💻

Il tuo computer

Lavori qui, poi push al fork

Fork vs Clone: non sono la stessa cosa

	Fork	Clone
Dove vive	Su GitHub (nel tuo account)	Sul tuo computer (locale)
Cosa copia	L’intero repository su GitHub	L’intero repository in locale
Chi può farlo	Chiunque (su repo pubblici)	Chiunque (su repo pubblici)
Permette push	Sì — è un tuo repository	Solo se hai i permessi sul remoto
Collegamento con l’originale	GitHub mostra “forked from…”	Nessun collegamento speciale

In pratica: fai fork su GitHub (crea la copia remota), poi fai clone del fork (scarichi la copia in locale). Sono due operazioni diverse che si usano insieme.

1.3 — I due remoti: origin e upstream

Quando lavori con un fork, hai due remoti da gestire: il tuo fork (origin) e il repository originale (upstream).

origin

Il tuo fork su GitHub. Qui fai push del tuo lavoro. È il repository che hai creato con il fork.

git@github.com:tuousername/progetto.git

upstream

Il repository originale. Da qui scarichi gli aggiornamenti. Non puoi fare push qui (non hai i permessi).

git@github.com:proprietario/progetto.git

  # Dopo aver clonato il fork, aggiungi upstream

  $ git remote add upstream git@github.com:proprietario/progetto.git

  # Verifica: ora hai 2 remoti

  $ git remote -v

  origin    git@github.com:tuousername/progetto.git (fetch)

  origin    git@github.com:tuousername/progetto.git (push)

  upstream  git@github.com:proprietario/progetto.git (fetch)

  upstream  git@github.com:proprietario/progetto.git (push)

1.4 — Il workflow completo del fork

Fork workflow: 7 passi

1. FORK

Su GitHub: clicca “Fork”
Crea la copia nel tuo account

2. CLONE

git clone
(del tuo fork)

3. UPSTREAM

git remote add
upstream URL

4. BRANCH

git switch -c
feature/x

↓

5. LAVORA + PUSH

commit…
git push origin feature/x

6. PR

Su GitHub: apri PR
dal tuo fork verso il repo originale

7. ATTENDI

Il maintainer revisiona,
commenta, e (se tutto ok) merge

1.5 — Mantenere il fork aggiornato

Il repository originale continua a evolversi dopo che hai creato il fork. Per non restare indietro, devi periodicamente sincronizzare il fork con l’upstream. Ci sono due modi: da terminale o da GitHub.

Modo 1: da terminale ⭐

          $ git switch main

          $ git fetch upstream

          $ git merge upstream/main

          $ git push origin main

Scarica le novità dall’upstream, le integra nel tuo main locale, poi le pusha al tuo fork. Il tuo fork è aggiornato.

Modo 2: da GitHub (un click)

Sul tuo fork su GitHub, se è indietro rispetto all’upstream, appare un banner: “This branch is N commits behind“. Clicca “Sync fork” → “Update branch”. Poi in locale: git pull.

# Workflow completo di sincronizzazione
$git switch main
$git fetch upstream
remote: Enumerating objects: 12, done.
From github.com:proprietario/progetto
   a1b2c3d..f4e5d6c  main       -> upstream/main

$git merge upstream/main
Updating a1b2c3d..f4e5d6c
Fast-forward

$git push origin main← aggiorna il fork su GitHub
Ora il tuo main locale, il tuo fork su GitHub e il repo originale sono tutti allineati.

📌 Quando sincronizzare? Prima di creare un nuovo branch per lavorare. Se il tuo fork è indietro di settimane, il tuo branch partirà da codice vecchio e la PR avrà conflitti con le modifiche recenti. Regola: sincronizza all’inizio di ogni sessione di lavoro.

1.6 — Aprire una PR dal fork

La PR dal fork funziona come quella normale, con una differenza: la PR va dal tuo fork al repository originale. GitHub lo gestisce automaticamente.

Pusha il tuo branch al tuo fork: git push origin feature/x.

Vai sul tuo fork su GitHub. Appare il banner “Compare & pull request”. Cliccalo.

GitHub imposta automaticamente la direzione: base repository: proprietario/progetto ← head repository: tuousername/progetto. Verifica che sia corretto.

Scrivi titolo e descrizione. Clicca “Create pull request”. La PR appare nel repository originale, non nel tuo fork.

1.7 — La cultura open source: le regole non scritte

Contribuire a un progetto open source non è solo codice — è entrare in una comunità con le sue regole e la sua cultura. Ecco cosa devi sapere prima di fare la tua prima PR a un progetto esterno:

Leggi il CONTRIBUTING.md. La maggior parte dei progetti ha un file che spiega come contribuire: come configurare l’ambiente, come scrivere i messaggi di commit, come strutturare la PR. Leggilo prima di iniziare.

Cerca le issue con “good first issue”. Molti progetti etichettano le issue adatte ai nuovi contributori. Parti da lì — non dalla feature più complessa del progetto.

Chiedi prima di fare. Se vuoi lavorare su un’issue, commenta “Posso lavorarci io?” prima di iniziare. Eviti di duplicare il lavoro di qualcun altro.

PR piccole e focalizzate. Una PR che cambia 3 file è più facile da revisionare di una che ne cambia 30. Un cambiamento per PR.

Sii paziente e gentile. I maintainer sono spesso volontari. Se la tua PR non riceve review subito, aspetta qualche giorno. Non sollecitare aggressivamente. Se la PR viene rifiutata, chiedi feedback e non prenderla sul personale.

💻 2. Esempi guidati

Esempio A — Fork workflow completo

Scenario

Il prof ha un repository prof-rossi/sito-classe. Tu vuoi aggiungere la tua pagina personale. Non hai permessi di push — devi usare il fork.

  # === PASSO 1: FORK (su GitHub) ===

  # Vai su github.com/prof-rossi/sito-classe → clicca “Fork” → “Create fork”

  # Ora hai: github.com/tuousername/sito-classe

  # === PASSO 2: CLONE (del tuo fork) ===

  $ git clone git@github.com:tuousername/sito-classe.git

  $ cd sito-classe

  # === PASSO 3: AGGIUNGI UPSTREAM ===

  $ git remote add upstream git@github.com:prof-rossi/sito-classe.git

  $ git remote -v

  origin    git@github.com:tuousername/sito-classe.git (fetch)

  origin    git@github.com:tuousername/sito-classe.git (push)

  upstream  git@github.com:prof-rossi/sito-classe.git (fetch)

  upstream  git@github.com:prof-rossi/sito-classe.git (push)

  # === PASSO 4: CREA UN BRANCH ===

  $ git switch -c feature/pagina-mario

  # === PASSO 5: LAVORA ===

  $ echo “<h1>Mario Rossi</h1><p>Appassionato di coding</p>” > studenti/mario.html

  $ git add . && git commit -m “Aggiunta pagina personale di Mario”

  # === PASSO 6: PUSH (al tuo fork, NON all’upstream) ===

  $ git push -u origin feature/pagina-mario

  # === PASSO 7: APRI PR (su GitHub) ===

  # Vai su github.com/tuousername/sito-classe

  # Clicca “Compare & pull request”

  # Verifica: base repo = prof-rossi/sito-classe ← head repo = tuousername/sito-classe

  # Titolo: “Aggiunta pagina personale di Mario Rossi”

  # Descrizione: “Aggiunta la mia pagina nella cartella studenti/”

  # Clicca “Create pull request”

Esempio B — Sincronizzare il fork prima di un nuovo lavoro

  # Una settimana dopo, vuoi aggiungere un’altra modifica.

  # Prima: sincronizza il fork con l’upstream.

  $ git switch main

  $ git fetch upstream

  From github.com:prof-rossi/sito-classe

     a1b2c3d..g7h8i9j  main       -> upstream/main

  $ git merge upstream/main

  Updating a1b2c3d..g7h8i9j

  Fast-forward

   studenti/giulia.html | 1 + ← Giulia ha aggiunto la sua pagina!

  $ git push origin main ← aggiorna il tuo fork su GitHub

  # Ora crea il nuovo branch dal main aggiornato

  $ git switch -c feature/aggiorna-pagina-mario

  # …lavora…commit…push…PR

🏋️ 3. Esercizi

🟢 Esercizio 1 — Il tuo primo fork (Facile)

a) Trova un repository pubblico su GitHub (può essere quello di un compagno, un progetto di esempio, o cerca “hello-world” su GitHub).
b) Clicca “Fork” per creare la tua copia.
c) Clona il fork sul tuo computer.
d) Aggiungi il remoto upstream: git remote add upstream URL-originale.
e) Verifica con git remote -v: vedi sia origin che upstream?
f) Vai su GitHub: il tuo fork mostra “forked from…” in alto?

🔵 Esercizio 2 — PR dal fork (Medio)

a) Dal fork dell’Esercizio 1, crea un branch feature/contributo.
b) Aggiungi un file (es. contributi/tuonome.md) con il tuo nome e un messaggio.
c) Committa e pusha al tuo fork: git push -u origin feature/contributo.
d) Su GitHub, apri una Pull Request dal tuo fork al repository originale.
e) Nella descrizione spiega cosa hai aggiunto e perché.
f) Se il repository originale è di un compagno, chiedigli di revisionare e fare merge.

🟠 Esercizio 3 — Sincronizzare il fork (Medio)

Questo esercizio funziona meglio se il repository originale ha ricevuto modifiche dopo il tuo fork (es. un compagno ha fatto merge della tua PR o di quella di altri).

a) Controlla se il tuo fork è indietro: su GitHub, il fork mostra “This branch is N commits behind”?
b) Da terminale, sincronizza: git fetch upstream → git merge upstream/main → git push origin main.
c) Verifica su GitHub: il banner “behind” è sparito?
d) Prova anche il Modo 2: su GitHub, clicca “Sync fork” → “Update branch”.
e) In locale, fai git pull per allinearti.

🟣 Esercizio 4 — Simula un progetto open source di classe (Difficile)

Questo esercizio simula un progetto open source all’interno della classe:

a) Il “maintainer” (uno studente o il prof) crea un repository libro-di-classe con un README.md, un CONTRIBUTING.md con le regole e un file capitoli/indice.md.

b) Ogni studente:
— Fa fork del repository.
— Clona il proprio fork e configura upstream.
— Crea un branch capitolo/nome-argomento.
— Scrive un breve capitolo in capitoli/nome-argomento.md (es. “capitoli/storia-di-internet.md”).
— Pusha e apre una PR al repository originale.

c) Il maintainer revisiona ogni PR, chiede modifiche se necessario, e fa merge.

d) Ogni studente sincronizza il fork dopo ogni merge per vedere i capitoli degli altri.

e) Alla fine: il repository contiene un “libro” scritto collaborativamente da tutta la classe con il workflow open source.

❓ 4. Quiz di verifica

1. Qual è la differenza tra fork e clone?

Mostra risposta

Il fork crea una copia del repository su GitHub, nel tuo account — è un’operazione remota che avviene nel browser. Il clone scarica un repository sul tuo computer — è un’operazione locale che avviene nel terminale. Il fork ti dà un repository su cui hai tutti i permessi di push; il clone ti dà solo una copia locale. Nel workflow tipico, fai prima il fork (su GitHub), poi il clone del fork (sul computer). Il fork mantiene un collegamento con il repository originale, il clone no.

2. Cos’è upstream e a cosa serve?

Mostra risposta

upstream è il nome convenzionale dato al repository originale da cui hai fatto il fork. Lo aggiungi manualmente con git remote add upstream URL. Serve per sincronizzare il fork: puoi scaricare le novità dal repository originale (git fetch upstream) e integrarle nel tuo fork (git merge upstream/main). Senza upstream, il tuo fork resta fermo alla versione del momento del fork e non riceve gli aggiornamenti degli altri contributori. origin punta al tuo fork, upstream punta all’originale.

3. Quando fai git push su un fork, dove vanno i commit?

Mostra risposta

Vanno al tuo fork su GitHub (origin), non al repository originale (upstream). Quando fai git push origin feature/x, i commit arrivano su github.com/tuousername/progetto. Il repository originale non viene toccato — non hai i permessi per fare push lì. Per proporre le tue modifiche al repository originale, apri una Pull Request dal tuo fork al repository originale. È il maintainer del progetto originale che decide se accettarle.

4. Il tuo fork è “5 commits behind” rispetto all’originale. Come ti sincronizzi?

Mostra risposta

Due modi. Da terminale: git switch main → git fetch upstream (scarica le novità) → git merge upstream/main (integra nel tuo main locale) → git push origin main (aggiorna il fork su GitHub). Da GitHub: vai al tuo fork, clicca “Sync fork” → “Update branch” — GitHub aggiorna il main del fork automaticamente. Poi in locale fai git pull per allinearti. Il metodo da terminale è più flessibile e ti dà controllo completo; quello da GitHub è più veloce per sincronizzazioni semplici.

5. Vuoi contribuire a un progetto open source. Qual è la prima cosa da fare?

Mostra risposta

Leggere il file CONTRIBUTING.md (o CONTRIBUTING) del progetto. Questo file spiega le regole della comunità: come configurare l’ambiente di sviluppo, come formattare i commit, come strutturare le PR, quali branch usare. Poi cerca le issue con etichetta “good first issue” — sono pensate per nuovi contributori. Prima di iniziare a lavorare su un’issue, commenta per chiedere se puoi prenderla in carico. Questo evita duplicazioni e mostra rispetto per la comunità.

6. La tua PR è stata rifiutata dal maintainer. Come reagisci?

Mostra risposta

Con maturità: chiedi feedback. Rispondi con qualcosa come “Grazie per aver guardato la PR. Potresti dirmi cosa migliorare per una prossima volta?”. Il rifiuto non è personale — può dipendere da molti fattori: il progetto ha cambiato direzione, la modifica non è nella roadmap, l’implementazione non segue le convenzioni del progetto. Ogni rifiuto è un’occasione per imparare. Non prendertela, non insistere aggressivamente, e non aprire la stessa PR di nuovo senza aver fatto le modifiche richieste. La pazienza e la gentilezza sono le competenze più importanti nell’open source.

📚 Riepilogo della lezione

Cosa hai imparato oggi:

Fork = copia del repo nel tuo account GitHub — hai tutti i permessi
origin = il tuo fork · upstream = il repository originale
Workflow: fork → clone → upstream → branch → lavora → push (origin) → PR (verso upstream)
Sincronizzare: fetch upstream → merge upstream/main → push origin main
Da GitHub: “Sync fork” per aggiornare con un click
PR dal fork: GitHub imposta automaticamente base = originale ← head = tuo fork
Cultura open source: leggi CONTRIBUTING.md, cerca “good first issue”, chiedi prima, PR piccole, sii paziente

Prossima lezione →

Lezione 20 — Branch protection e required reviews
Proteggere main da push diretti. Richiedere approvazioni obbligatorie.
Configurare le regole per un progetto di gruppo sicuro.

Corso Git & GitHub · Per studenti e insegnanti · Lezione 19 di 45