Scegli prima un capitolo o un punto di partenza per la voce. Il testo accessibile è disponibile qui sotto; per i PDF l’edizione impaginata conserva pagine e immagini dell’originale.

progetto. GitHub è la bacheca condivisa: riceve una copia del tuo lavoro, la mostra ad altri, la rende accessibile da dispositivi diversi e offre strumenti per discutere e integrare contributi. Se usi solo Git, puoi lavorare benissimo da solo anche offline.

Se usi solo GitHub, senza Git, ti ritrovi con un contenitore online, ma non con il sistema che governa il versionamento. Questa differenza conta perché risponde a due bisogni diversi. Il primo è tecnico: salvare in modo ordinato la storia del progetto, senza affidarti ai nomi dei file o alle copie sparse.

Il secondo è collaborativo: condividere ciò che hai già stabilizzato, così che un’altra persona possa vedere, scaricare o proporre modifiche. In pratica, Git decide “che cosa è successo al progetto”, mentre GitHub decide “dove il progetto può essere esposto e coordinato”. Mescolare i due livelli crea confusione: ti aspetti che un sito web faccia il lavoro del programma installato sul computer, oppure credi che un commit fatto in locale appaia online senza un passaggio esplicito di pubblicazione.

Un mini-scenario chiarisce tutto. Stai preparando gli appunti di un corso e modifichi il testo per tre giorni consecutivi. Con Git, ogni volta che stabilisci un punto sensato del lavoro, registri quello stato e puoi tornare indietro se una revisione peggiora il risultato.

Con GitHub, puoi caricare la versione che vuoi mostrare al docente o al compagno di studio, mantenere una copia online e, se serve, lavorare da un altro computer senza ricominciare da zero. Il vantaggio non è estetico: è operativo. Tu continui a produrre le modifiche sul tuo computer; GitHub ne conserva una rappresentazione remota, utile per condivisione e sincronizzazione.

Per orientarti bene, tieni a mente questa tabella mentale: 1. Git: lavora sul computer, anche senza rete. 2.

GitHub: ospita il progetto online. 3. Git: registra la cronologia.

4. GitHub: rende il repository accessibile. 5.

Git: serve anche se lavori da solo. 6. GitHub: diventa utile quando vuoi pubblicare o collaborare.

C’è però un limite importante da non trascurare. GitHub non sostituisce Git perché non elimina la necessità di capire cosa stai facendo in locale. Se non sai distinguere una modifica salvata nel file da una modifica registrata da Git, rischi di credere che l’upload online basti a mettere ordine.

In realtà, GitHub riceve solo ciò che tu hai già preparato con Git. Per questo, prima di pensare alla

condivisione, devi saper leggere il tuo repository locale con lucidità. Solo così il passaggio online ha un significato preciso e non diventa un gesto automatico. In sintesi, Git è lo strumento che governa la memoria del progetto; GitHub è il luogo in cui quella memoria può essere pubblicata, consultata e condivisa. Se separi bene questi ruoli, smetti di confondere il motore con la destinazione. E quando arriverai a collegare il tuo progetto al web, saprai esattamente che cosa stai trasferendo, perché lo stai facendo e da quale punto del lavoro stai partendo.

2.3 REPOSITORY LOCALE E REPOSITORY REMOTO: STESSA IDEA, LUOGHI DIVERSI

Un repository locale e un repository remoto rappresentano la stessa idea operativa: una copia del progetto con la sua cronologia. Cambia il luogo in cui vive quella copia, e questo cambia il modo in cui tu la usi. Sul tuo computer il repository locale è il centro del lavoro quotidiano: lì apri i file, fai modifiche, controlli lo stato e registri i progressi.

Su GitHub, invece, il repository remoto è la versione ospitata online, utile per conservare una copia accessibile da più dispositivi, condividerla con altri o pubblicarla in modo visibile. Questa distinzione conta perché ti evita una confusione molto frequente: pensare che il progetto esista “una sola volta”. In realtà, quando lavori bene, hai due istanze dello stesso progetto che dialogano tra loro.

Il locale è dove produci il contenuto; il remoto è dove lo depositi o lo sincronizzi. Se mescoli i due piani, rischi di credere di aver pubblicato qualcosa che in realtà è ancora solo sul tuo computer, oppure di aspettarti di trovare online una modifica che non hai ancora inviato. Per orientarti, tieni ferma questa regola mentale: 1.

Il locale è immediato, veloce, sotto il tuo controllo diretto. 2. Il remoto è condiviso, accessibile via rete, dipendente da sincronizzazione esplicita.

3. La cronologia può esistere in entrambi, ma non si aggiorna da sola in modo magico. Immagina un piccolo progetto di studio, per esempio una cartella con appunti in Markdown.

Tu modifichi il testo sul computer, salvi il file e poi registri il cambiamento con Git nel repository locale. Fin qui, nessuno al di fuori del tuo dispositivo vede la modifica.

Solo quando invii i commit al repository remoto, GitHub riceve quella nuova versione e la mostra online. Se apri la pagina web prima di quell’invio, continuerai a vedere la versione precedente: non è un errore, è il comportamento normale del sistema. Dal punto di vista pratico, il repository locale ti serve per lavorare senza attrito.

Puoi fare prove, correggere un refuso, riscrivere una sezione o dividere un file in modo ordinato senza dipendere dalla connessione. Il repository remoto, invece, ti serve come punto di scambio e di sicurezza: rende il progetto consultabile da un altro computer e crea un riferimento stabile fuori dalla macchina su cui stai lavorando. Per un principiante, questo è il primo vero salto di qualità: smetti di trattare il progetto come un file “sparso” e inizi a trattarlo come un sistema con una copia operativa e una copia pubblicata.

Prima di passare alla parte operativa, verifica mentalmente questi quattro controlli: 1. Sto lavorando nella cartella giusta sul mio computer? 2.

Il progetto che vedo localmente è davvero quello che voglio pubblicare? 3. Il repository remoto esiste già su GitHub?

4. So distinguere tra ciò che ho solo salvato sul disco e ciò che ho già sincronizzato online? Un errore tipico del principiante è credere che “avere GitHub” equivalga ad avere già il lavoro al sicuro.

Non è così. GitHub non sostituisce il repository locale, e il repository locale non sostituisce quello remoto. Hanno ruoli diversi: uno ti permette di produrre e controllare il lavoro con precisione, l’altro di ospitarlo e distribuirlo.

Se tieni ferma questa separazione, i comandi che imparerai dopo avranno un significato chiaro, invece di sembrare gesti astratti da memoria meccanica. ”. Quando questa distinzione ti entra in testa, il flusso di lavoro smette di essere confuso e diventa leggibile.

Da qui in avanti, ogni passo avrà un obiettivo preciso: il locale per costruire, il remoto per condividere, e tu in mezzo a coordinare le due cose con ordine.

2.4 PUSH, PULL E PULL REQUEST VISTI PRIMA IN PAROLE SEMPLICI

Se vuoi capire il flusso senza perderti nei termini, pensa a tre azioni distinte che lavorano in momenti diversi. Il push porta i tuoi commit dal computer a GitHub, il pull prende gli aggiornamenti da GitHub e li integra nel tuo repository locale, la pull request è la proposta formale con cui dici: “Ho finito questa modifica, valutatela e, se va bene, uniamola al progetto principale”. Non sono sinonimi, e confonderli ti fa perdere il controllo del lavoro.

Il push serve quando sul tuo computer hai già registrato un progresso valido e vuoi renderlo visibile online. Non carichi un file a caso: invii una sequenza di commit già costruiti in locale. Questo dettaglio conta perché GitHub non inventa la storia del progetto; la riceve.

Per esempio, se stai lavorando a un esercizio di corso e hai corretto il README, migliorato un esempio e salvato due commit separati, un push trasferisce proprio quei commit, nell’ordine in cui li hai creati. Prima del push, GitHub non vede ancora quelle modifiche; dopo il push, la cronologia remota si allinea con quella del tuo computer. Il pull è l’operazione speculare dal punto di vista del risultato, ma non è una copia cieca.

Tu chiedi a Git di recuperare i commit presenti online che ancora non esistono in locale, poi li integra nella tua copia. In pratica lo usi quando hai aperto il progetto da un altro computer, oppure quando qualcun altro ha pubblicato aggiornamenti sul repository remoto. Se sul telefono non c’entra nulla, qui vale la stessa logica: il tuo repository locale può essere “indietro” rispetto a GitHub, e il pull serve proprio a riallinearli.

Se esegui un pull senza prima controllare il lavoro che hai in sospeso, rischi di sovrapporre cambiamenti non ancora registrati e di complicarti la vita. La pull request è diversa, perché non sposta dati da sola: apre una discussione tecnica sul cambiamento. La usi quando hai lavorato in un branch separato e vuoi proporre che quel lavoro venga integrato in un altro branch, di solito quello principale.

Su GitHub la pull request mostra che cosa hai modificato, da quale branch parti, verso quale branch vuoi arrivare e lascia uno spazio per revisione, commenti e approvazione. In un

piccolo progetto di studio può servire anche solo a te, per controllare con ordine ciò che stai per unire; in un contesto condiviso, permette agli altri di leggere il lavoro prima dell’integrazione. Puoi memorizzare la differenza con questa sequenza pratica: 1. Lavori in locale e fai commit.

2. Usi il push per pubblicare quei commit su GitHub. 3.

Usi il pull per riportare nel tuo computer i commit nuovi che arrivano da GitHub. 4. Usi la pull request quando vuoi chiedere che una branch venga incorporata in un’altra.

Un mini-scenario chiarisce tutto. Immagina un progetto di appunti per un corso. Tu modifichi il file delle note, fai un commit con un messaggio chiaro, poi esegui il push: la versione aggiornata compare su GitHub.

Il giorno dopo, da casa, apri il repository su un secondo computer e trovi una modifica fatta prima da te o da un compagno; esegui il pull e ricevi quell’aggiornamento. Se invece hai creato una branch chiamata miglioramento-note, hai lavorato lì dentro e vuoi riportare la modifica nella linea principale, apri una pull request. Hai tre gesti diversi, tre obiettivi diversi, tre risultati diversi.

Il punto da non perdere è questo: push e pull descrivono il movimento dei commit tra locale e remoto; la pull request descrive la proposta di fusione tra branch. Se li tieni separati fin dall’inizio, capisci meglio ogni messaggio di GitHub e riduci gli errori di interpretazione. Prima controlli dove sono i tuoi commit, poi decidi se inviarli, recuperarli o proporli per l’integrazione.

CAPITOLO 3: PREPARARE L’AMBIENTE DI LAVORO SENZA ANSIA DA TERMINALE

Prima di toccare il terminale, devi mettere in ordine tre cose: avere Git installato, sapere dove si trova il progetto e configurare un’identità minima che Git userà nei primi salvataggi. Questo capitolo non serve a “imparare comandi a memoria”, ma a togliere attrito al lavoro vero: se l’ambiente è confuso, ogni istruzione sembra più difficile di quanto sia. Qui ti concentri solo sulla preparazione pratica, così nei passaggi successivi potrai eseguire le operazioni senza inciampare in errori evitabili.

Il primo controllo è tecnico, non teorico: verifica che Git sia davvero presente nel sistema e che il terminale risponda in modo coerente. In ogni guida o schermata che consulti, tieni presente che versioni, nomi dei pulsanti e messaggi possono cambiare; prima di seguire una procedura, controlla sempre che la documentazione sia aggiornata rispetto al tuo sistema operativo. Fatta questa verifica, il resto del percorso diventa molto più lineare, perché lavori su un ambiente reale e non su un’ipotesi.

Il secondo controllo riguarda il contesto: prima di eseguire qualunque comando, devi sapere in quale cartella ti trovi e su quale progetto stai operando. Molti errori iniziali nascono proprio qui, non da Git in sé, ma dal fatto che il terminale sta lavorando nella directory sbagliata. Se impari a riconoscere con precisione il punto di partenza, riduci subito la possibilità di creare repository nel posto errato, modificare il progetto sbagliato o confondere file di prova con file del lavoro vero.

Infine, c’è una preparazione minima dell’identità che Git associa ai tuoi commit. Non è un dettaglio ornamentale: serve a rendere leggibili le registrazioni del lavoro e a evitare ambiguità quando, più avanti, guarderai la cronologia. In questa fase non devi pensare a configurazioni complicate o a scenari avanzati; ti basta impostare ciò che è necessario per partire in modo ordinato.

Se queste basi sono corrette, il resto del manuale ti chiederà meno energia e ti restituirà subito risultati più chiari.

3.1 INSTALLARE GIT E VERIFICARE CHE FUNZIONI DAVVERO

Installare Git non significa ancora usare Git bene, ma ti mette nelle condizioni di farlo senza inciampi. Qui il tuo obiettivo è molto concreto: avere il programma sul computer, aprire il terminale con sicurezza minima e controllare che il sistema risponda nel modo giusto. Se questo passaggio non è pulito, tutto il resto diventa confuso, perché non saprai mai se un errore dipende da te o dall’installazione.

Prima di procedere, verifica tre cose. Primo: il sistema operativo del tuo computer, perché il comando o il pacchetto da usare cambia tra Windows, macOS e Linux. Secondo: se hai già un terminale disponibile, come Prompt dei comandi, PowerShell, Terminale o una shell Linux.

Terzo: se disponi dei permessi per installare software, soprattutto su computer gestiti da scuola, università o ufficio. Le interfacce dei programmi possono cambiare nel tempo, quindi conviene controllare la documentazione aggiornata del sistema che stai usando prima di seguire istruzioni molto specifiche. Il metodo corretto è questo: 1.

Installa Git con il canale previsto per il tuo sistema. 2. Apri il terminale.

3. Verifica che il comando risponda. 4.

Controlla che la versione sia riconosciuta. 5. Fai un primo test minimale, senza toccare ancora un progetto reale.

Su Windows, in genere puoi usare l’installer ufficiale di Git e accettare le opzioni di base se non sai ancora cosa modificare. Su macOS, spesso Git è già presente o viene proposto tramite gli strumenti di sviluppo del sistema; se manca, puoi installarlo dal pacchetto ufficiale o tramite il gestore che usi normalmente. Su Linux, di solito lo installi dal gestore pacchetti della tua distribuzione.

Non serve inseguire configurazioni sofisticate: in questa fase ti basta che il comando sia disponibile e che la shell lo riconosca. A installazione conclusa, apri il terminale e digita: git --version Questo comando non modifica nulla. Ti dice solo se Git è raggiungibile dal sistema e quale versione hai installato.

Z, hai superato il primo controllo. Se invece compare un messaggio che dice che il comando non è riconosciuto, il problema non è il tuo progetto: o Git non è installato, oppure non è stato aggiunto al

percorso di sistema, cioè alla lista di programmi che il terminale sa trovare. Se il comando funziona, passa a un secondo controllo utile: git help oppure, se preferisci, git status più avanti, quando avrai una cartella di lavoro. Per ora ti interessa solo vedere che il programma risponde.

Non devi memorizzare i dettagli dell’aiuto a schermo; devi solo abituarti a un fatto: il terminale non è un nemico, è un interprete preciso. Scrivi un comando, ricevi una risposta. Se la risposta è chiara, sei in controllo.

Per capire se l’installazione è davvero utile, fai un test mentale molto semplice. Immagina di dover iniziare un piccolo esercizio di studio. Se Git è installato correttamente, potrai in seguito creare una cartella di progetto, registrare le modifiche e recuperare la cronologia.

Se non lo è, ogni passaggio successivo si fermerà subito, spesso con un errore secco e poco amichevole. Per questo il controllo iniziale ti fa risparmiare tempo e frustrazione. Tieni a mente anche alcuni errori comuni: - Installare Git ma chiudere e riaprire male il terminale, poi pensare che il comando non funzioni.

- Confondere Git con GitHub e cercare online una pagina web invece di verificare il programma locale. - Saltare la verifica della versione e accorgersi del problema solo quando provi il primo comando su un progetto reale. - Usare istruzioni vecchie trovate in rete senza controllare se il tuo sistema richiede un passaggio diverso.

Il criterio di riuscita è netto: il comando git --version restituisce una versione leggibile, il terminale non segnala errori di riconoscimento e tu sai distinguere tra installazione riuscita e semplice apertura del programma. Quando arrivi qui, hai già tolto di mezzo la prima fonte di ansia. Da questo momento puoi lavorare sapendo che Git esiste davvero sul tuo computer e che il prossimo passo non sarà un salto nel buio, ma una costruzione ordinata sopra una base verificata.

3.2 CONFIGURARE NOME UTENTE ED EMAIL PER I PRIMI COMMIT

Git usa il nome e l’email per firmare ogni commit con un’identità leggibile. Non serve a proteggere il repository né a pubblicare qualcosa online: serve a fare in modo che, quando

rileggi la cronologia, tu capisca chi ha registrato un cambiamento e con quale configurazione di base. Se trascuri questo passaggio, i commit restano validi, ma risultano anonimi o poco chiari, e in un progetto piccolo questo basta già a creare confusione. Il punto non è “riempire campi”, ma dare a Git una firma coerente prima di iniziare a salvare lavoro vero.

email. Il primo è il nome che comparirà nei commit; il secondo è l’indirizzo associato a quell’identità. In molti ambienti puoi usare il tuo nome reale oppure un nome professionale stabile, purché sia lo stesso che userai con continuità.

Per l’email, conviene scegliere un indirizzo che riconosci e che puoi mantenere nel tempo, perché GitHub e altri servizi possono usarlo per collegare i commit al tuo account. Prima di scrivere i comandi, controlla di trovarti nel terminale già aperto, in una qualunque cartella, e verifica se stai lavorando con una configurazione globale o solo per il repository corrente. La configurazione globale è quella più adatta al principiante, perché imposta i dati per tutti i repository sul computer.

I comandi essenziali sono questi: 1. name "Il tuo nome" 2. com" Dopo averli eseguiti, Git non mostra sempre un messaggio vistoso: il silenzio, in questo caso, non è un errore.

Per controllare subito che il valore sia stato salvato, usa: 1. name 2. email Se il terminale restituisce esattamente i valori inseriti, la configurazione è a posto.

Se non compare nulla, hai probabilmente digitato male una chiave, omesso le virgolette in un nome con spazi oppure scritto il comando in un terminale diverso da quello che stai usando davvero. Questo controllo immediato è importante perché ti evita di scoprire il problema solo dopo il primo commit. C’è anche un caso diverso, utile quando vuoi usare un’identità distinta solo in un progetto specifico, per esempio un repository di studio o un lavoro condiviso.

In quel caso puoi omettere l’opzione globale e impostare i valori dentro la cartella del progetto: 1. name "Il tuo nome" 2. com" Questa scelta sovrascrive solo quel repository, senza cambiare gli altri.

È una soluzione da ricordare

se, in futuro, lavorerai con più identità o con indirizzi differenti. Per ora, però, ti basta sapere che globale significa “su tutto il computer”, mentre senza global significa “solo qui”. Questa distinzione pratica vale più di qualsiasi definizione astratta, perché ti impedisce di modificare la configurazione nel posto sbagliato.

Immagina di aprire il tuo repository di esercizio e di fare due piccoli commit: uno per aggiungere un titolo a un file di appunti e uno per correggere una frase. Se hai configurato nome ed email prima, la cronologia mostrerà una firma coerente e riconoscibile. Se non lo hai fatto, Git userà comunque un’identità già presente nel sistema oppure una configurazione incompleta, e tu rischierai di non capire subito perché i commit non riportano i dati attesi.

Per questo conviene eseguire questo passaggio all’inizio, una sola volta bene, invece di rincorrerlo dopo. Prima di passare oltre, fai questo controllo rapido: 1. hai scelto un nome stabile e scritto senza errori; 2.

hai inserito un’email che riconosci e che non cambierai a breve; 3. hai verificato il risultato con git config; 4. sai se la configurazione è globale o limitata alla cartella corrente.

Se questi quattro punti tornano, puoi iniziare i commit con una base pulita. Da qui in avanti Git saprà a chi attribuire ogni salvataggio della cronologia, e tu avrai un riferimento chiaro già dal primo progetto.

3.3 APRIRE TERMINALE O PROMPT NELLA CARTELLA GIUSTA SENZA PERDERTI

Il terminale non è un luogo misterioso: è solo il punto in cui dai istruzioni precise al sistema operativo, invece di passare da menu e finestre. Qui ti serve per un obiettivo molto concreto: aprire la sessione giusta dentro la cartella del progetto, così ogni comando di Git agisce proprio su quel repository e non su un’altra directory qualsiasi. Se sbagli cartella, il problema non è Git: sei tu che stai parlando con il posto sbagliato. La regola da fissare subito è questa: prima ti posizioni nella cartella del progetto, poi controlli dove sei, solo dopo inizi a lavorare. Non invertire l’ordine. Un principiante spesso apre il terminale “a caso”, esegue comandi e si accorge troppo tardi di aver modificato la cartella utente, il

Desktop o un vecchio esercizio. Per evitarlo, tu devi trattare la cartella come un indirizzo preciso, non come un concetto vago. Fai così, in ordine.

1. Apri il terminale o il prompt che usi sul tuo sistema. 2.

Porta la cartella del progetto in una posizione facile da raggiungere, per esempio Documenti o una cartella di lavoro dedicata. 3. Apri il terminale dentro quella cartella, oppure spostati lì con il comando di cambio directory previsto dal sistema.

4. Verifica la posizione corrente prima di digitare altro. Il passaggio più importante è il quarto, perché ti dà un controllo immediato.

Se il terminale mostra il percorso della cartella corretta, hai un punto di partenza affidabile. Se invece vedi un’altra directory, fermati e correggi subito. Non continuare “sperando” di essere nel posto giusto: con Git, la precisione iniziale evita correzioni inutili dopo.

Sul piano pratico hai tre strade comuni, e puoi usare quella che ti è più comoda. 1. Aprire il terminale direttamente nella cartella con il file manager, quando il sistema lo permette.

2. Aprire il terminale e usare il comando per entrare nella cartella desiderata. 3.

Aprire un editor di testo o un ambiente di sviluppo e usare il terminale integrato, purché tu controlli comunque il percorso attivo. La logica non cambia: il comando che userai per cambiare cartella deve portarti esattamente dentro il repository, non in una cartella vicina. Per questo il nome della cartella da raggiungere va scritto con attenzione, compresi eventuali spazi, maiuscole o sottocartelle.

Se il percorso è lungo, evita di andare a memoria: copia il percorso corretto dal file manager o dal sistema, così riduci gli errori di battitura. Dopo lo spostamento, controlla sempre tre segnali: 1. Il percorso visualizzato dal terminale corrisponde al progetto.

2. La cartella contiene i file che ti aspetti. 3.

Se eseguirai Git più avanti, i comandi agiranno su quel contenuto e non su altro. Un esempio realistico chiarisce il punto. Hai una cartella chiamata esercizio-git dentro Documenti e dentro ci sono un file di testo e una sottocartella con materiali di studio.

Se apri il terminale nella tua home e lavori lì, Git interpreterà tutto in modo diverso. Se invece entri in Documenti/esercizio-git e lo verifichi prima di procedere, ogni operazione avrà un bersaglio chiaro. Non stai ancora creando repository o commit: stai solo mettendo il tavolo in ordine prima