Hai una cartella di codice sul portatile e vuoi sapere chi ha cambiato cosa, oppure cerchi un progetto a cui contribuire? GitHub ospita repository basati su Git e offre strumenti per collaborare, ma il modo in cui ti serve dipende dal fatto che tu voglia tenere il codice privato o condividerlo.
GitHub collega il codice alla sua storia e al lavoro del team
- Git registra le modifiche; GitHub ospita repository Git e aggiunge strumenti online.
- Un repository raccoglie file e cronologia; un branch isola una linea di lavoro.
- Una pull request propone e discute modifiche prima che entrino nel ramo principale.
- Un repository pubblico è visibile, ma per autorizzare riuso e distribuzione serve una licenza.
Git registra le versioni, GitHub le rende accessibili online
Immagina di correggere un sito e di voler confrontare la pagina attuale con quella di ieri. Git tiene traccia delle modifiche nel progetto e permette di recuperare versioni precedenti; GitHub ospita una copia online del repository e aggiunge strumenti per organizzare il lavoro. La distinzione evita un equivoco frequente: puoi usare Git anche senza GitHub, mentre GitHub si appoggia a Git per la cronologia del codice.
Secondo la documentazione ufficiale di Git, ogni repository locale contiene la propria cronologia: quando cloni un progetto, non scarichi soltanto i file più recenti, ma anche i dati necessari a ricostruirne le versioni. GitHub è quindi uno spazio di collaborazione e hosting, non il programma che crea da solo il controllo delle versioni. Se lavori senza connessione, puoi continuare a registrare modifiche in locale e sincronizzarle in seguito.
Repository, branch e commit rispondono a domande diverse
All’inizio le parole sembrano un gergo da imparare a memoria; in pratica, ognuna descrive un pezzo preciso del flusso. Un repository contiene file e cronologia, un branch è una linea di lavoro separata e un commit salva un insieme di modifiche con un messaggio che ne spiega lo scopo.
Per esempio, in un sito personale puoi creare un branch per aggiornare la pagina dei contatti, lasciando intatta la versione principale mentre lavori. Quando le modifiche sono pronte, una pull request le presenta agli altri per revisione e discussione; dopo l’approvazione, possono essere unite al branch principale. Un’issue, invece, descrive un problema, una domanda o un’attività da seguire: non contiene di per sé la correzione.
Se lavori da solo, GitHub serve quando la cronologia ti evita copie confuse
Per un singolo file di testo, una cartella sincronizzata può bastare. Quando un progetto ha più file collegati o cambiamenti da confrontare, GitHub diventa utile se vuoi conservare una cronologia leggibile e raggiungere il progetto da più dispositivi. Io partirei da un repository privato per un progetto personale ancora in costruzione, e lo renderei pubblico solo dopo aver controllato file e impostazioni.
| Situazione | Possibile effetto | Scelta pratica |
|---|---|---|
| Hai una cartella di appunti che cambia poco | La cronologia dettagliata può aggiungere passaggi senza aiutarti molto | Usa la sincronizzazione abituale |
| Modifichi codice e vuoi confrontare o annullare cambiamenti | Senza cronologia, devi affidarti a copie manuali | Avvia un repository Git e collegalo a GitHub se ti serve una copia online |
| Vuoi ricevere contributi da altre persone | Le modifiche vanno esaminate e coordinate | Usa branch e pull request prima di integrare il lavoro |
Questa scelta non trasforma GitHub in un backup completo: se perdi file non ancora registrati o sincronizzati, la piattaforma non può ricostruirli. Per i progetti di lavoro, controlla anche accessi e contenuti prima di condividere il repository, perché la visibilità pubblica espone i file a chiunque.
Un repository pubblico non concede automaticamente una licenza open source
Il lucchetto aperto risponde alla domanda “chi può vedere il progetto?”, non a “che cosa può farci?”. Nei repository pubblici, chi visita la pagina può vedere i contenuti; per stabilire le condizioni di uso, modifica e distribuzione del software occorre indicare una licenza. La documentazione di GitHub chiarisce che le licenze open source definiscono questi permessi.
In assenza di una licenza, non dare per scontato che chiunque possa riutilizzare il codice liberamente. Se vuoi accettare contributi, aggiungi una licenza adatta al progetto e controlla che i file pubblicati non contengano credenziali, chiavi API o dati riservati. Rendere pubblico un repository è una scelta di visibilità, quindi controlla il contenuto prima di cambiare impostazione.
Per iniziare, scegli il repository in base a chi deve vedere il codice
Se stai imparando, crea un repository piccolo e privato, registra una modifica per volta e scrivi messaggi di commit che dicano cosa è cambiato. Quando vuoi mostrare il progetto o chiedere contributi, valuta la visibilità e la licenza prima di aprirlo. Così la cartella di partenza diventa una cronologia comprensibile, senza confondere Git con il servizio che la ospita.
