Anteprima della lezione

Lavoro di squadra: fork, feature branch e pull request

Questa sezione descrive come funziona il 90% dei team open-source e aziendali. Seguiremo l'intero ciclo: fork → feature branch → commit → pull request → code review → merge. Analizzeremo separatamente come scrivere la descrizione di una PR affinché il revisore comprenda immediatamente il contesto e quali errori nella PR tradiscono subito un principiante.

fork pull request code review
Cosa imparerai in questa lezione
  • Sarai in grado di contribuire a qualsiasi progetto open-source seguendo il ciclo standard fork → PR.
  • Imparerai a creare una pull request in modo che il revisore capisca il compito senza ulteriori domande.
  • Capirai come reagire correttamente ai commenti durante il code review, sia dal punto di vista tecnico che comunicativo.

Inizio della lezione

Fork: la tua sandbox personale

  • Fork: la tua copia personale del repository su GitHub
  • Controllo completo senza rischi per l'originale
  • Mantiene la connessione con il progetto originale
  • Ideale per esperimenti e contributi open-source

Immagina di aver trovato un libro interessante in biblioteca, ma di non poterci fare annotazioni. Il fork risolve questo problema creando una tua copia personale del repository su GitHub. Ora puoi sperimentare con il codice senza rischiare di danneggiare il progetto originale. Questo è particolarmente utile quando devi testare un'idea o contribuire a un progetto altrui. Il tuo fork rimane collegato al repository originale, semplificando il tracciamento degli aggiornamenti e l'invio delle modifiche all'autore.

Come creare un fork su GitHub

  • Clicca il pulsante Fork nell'angolo in alto a destra
  • Scegli il tuo account come destinazione
  • Aspetta la creazione della copia
  • Clona il tuo fork sulla macchina locale

Apri il repository desiderato su GitHub e trova il pulsante 'Fork' nell'angolo in alto a destra. Dopo aver cliccato, scegli il tuo account come destinazione. In pochi secondi GitHub creerà una copia esatta del repository nel tuo profilo. Ora puoi clonarlo sul tuo computer con il comando git clone e iniziare a lavorare. Ricorda di verificare di clonare il tuo fork, non il repository originale.

# Clonazione del tuo fork sul computer
git clone https://github.com/tuo-username/repository.git

# Spostati nella directory del progetto
cd repository

# Verifica dei repository remoti
git remote -v

Fork vs Clone: qual è la differenza?

  • Clone: copia locale sul tuo computer
  • Fork: copia remota nel tuo account GitHub
  • Il fork mantiene la connessione con il repository originale
  • Comodo per sincronizzare le modifiche

Sebbene entrambi i processi creino una copia del repository, c'è una differenza sostanziale. Il clone scarica il codice sul tuo computer, mentre il fork crea una copia remota nel tuo account GitHub. Il fork mantiene la connessione con il progetto originale, permettendo di sincronizzare facilmente le modifiche. Questo è un punto chiave quando partecipi a progetti open-source: lavori nel tuo fork e poi proponi le modifiche all'autore tramite una pull request. Ora che hai creato la tua copia del progetto, è il momento di portarla sulla macchina locale e imparare a lavorarci.

La lezione completa è disponibile con l'abbonamento

30 altre slide nella versione completa.

Video, tutte le slide, appunti, test, tutor AI e intervista si sbloccano dopo l'accesso e l'abbonamento.

Accedi o registrati Attiva l'abbonamento

Contenuti della lezione

  1. Fork: la tua sandbox personale
  2. Come creare un fork su GitHub
  3. Fork vs Clone: qual è la differenza?
  4. Cloniamo il fork sul computer
  5. Aggiungiamo upstream per la sincronizzazione
  6. Verifica dei repository remoti
  7. Perché servono branch separati?
  8. Creare un ramo feature
  9. Come nominare correttamente i rami
  10. Perché servono commit atomici
  11. Scrivere il messaggio di commit perfetto
  12. Errori comuni nei commit
  13. Perché pubblicare un ramo nel fork
  14. Comando git push per pubblicare un ramo
  15. Verifica del ramo pubblicato
  16. Pull Request come richiesta di modifiche
  17. Titolo della PR: sintetico e pertinente
  18. Descrizione della PR: cosa, perché e come verificare
  19. Errori tipici nelle PR
  20. Il mostro delle PR: perché le pull request grandi uccidono la revisione
  21. Descrizione della PR: la tua occasione per spiegare, non per scusarti
  22. Una PR, un compito, ovvero come non mescolare modifiche non correlate
  23. Code Review come dialogo con un editor
  24. Rispondi a ogni commento
  25. Fissa le correzioni con commit separati
  26. Perché sorgono conflitti durante il merge
  27. Aggiorniamo il ramo prima del merge
  28. Troviamo e risolviamo i conflitti
  29. Completiamo la risoluzione del conflitto
  30. Pulizia dopo un merge riuscito
  31. Eliminiamo il ramo feature su GitHub
  32. Aggiorniamo il repository locale
  33. Maestro del lavoro di squadra: dal fork al merge

Articoli su questa lezione

Tutte le lezioni del corso

  1. Introduzione: Git da zero a sviluppatore fiducioso
  2. Perché serve Git — e perché senza non ti assumono
  3. Installazione e configurazione: prepariamo Git al primo avvio
  4. Primo repository: init, add, commit e la magia dell'indice
  5. Leggiamo la storia: log, diff, show e navigazione nel passato
  6. Branch: la realtà parallela del tuo codice
  7. Annullare gli errori: restore, reset, revert — correttamente e con cautela
  8. GitHub e repository remoti: il tuo codice nel cloud
  9. Lavoro di squadra: fork, feature branch e pull request
  10. Conflitti di unione: niente panico — analizziamo e risolviamo
  11. Processi Git nei team reali: quale workflow scegliere
  12. Strumenti avanzati: rebase, stash, cherry-pick e tag
  13. Progetto finale: simuliamo uno sviluppo di gruppo reale