Git e GitHub per principianti: la guida passo passo, dal primo commit alla pull request

Pubblicato il Aggiornato il
Git e GitHub per principianti: la guida passo passo, dal primo commit alla pull request
Guida
Tempo40 minuti
DifficoltàFacile
Ti serveUn PC Windows o Mac e un indirizzo email per creare l'account GitHub

GitHub per principianti, in due righe: Git è il programma che salva sul computer le versioni dei tuoi file, GitHub è il sito dove le tieni anche online, al sicuro.

Chiedi all’assistente AI di rendere più moderna la pagina dei servizi, e lui cambia sei file in un minuto.

La pagina è più bella. Però il numero di telefono è sparito, dal cellulare il menu non si apre più, e una copia di com’era stamattina non ce l’hai.

Git serve a non trovarti mai lì.

Ti spiego Git e GitHub partendo da zero. Git tiene la storia di un progetto, cioè di una cartella di file su cui lavori, come un piccolo sito.

Ogni volta che glielo chiedi, Git scatta una fotografia dei tuoi file e la mette in un album. Così puoi sempre tornare a com’erano.

GitHub è il sito dove tieni quell’album anche online, al sicuro e da condividere con chi lavora con te.

Il percorso è questo: installi Git, salvi le prime versioni di un piccolo sito di prova e le mandi su GitHub. Poi provi una modifica in una brutta copia e impari a tornare indietro.

Non serve aver mai usato un terminale: ogni comando è pronto da copiare, con accanto quello che vedrai dopo.

Claude Code e Codex sono assistenti AI che scrivono e modificano da soli i file di un progetto. Se li lasci lavorare sul tuo, Git è la rete di sicurezza: prima di ogni modifica c’è una fotografia a cui tornare con un comando.

In agenzia lo usiamo così su ogni progetto.

Provato da noi: 7 ottobre 2026, Windows 11 con Git 2.55. Le schermate del terminale sono le uscite vere dei comandi, lanciati in una cartella di prova chiamata sito-prova.

Prima di iniziare

  • Un indirizzo email per creare l’account su GitHub. Il piano gratuito basta per tutto quello che trovi in questa guida.
  • Un computer Windows o un Mac. Sul Mac Git spesso è già installato.
  • Non serve preparare cartelle o file: la cartella di prova e i suoi file li crei al passo 3.
  • Il terminale: su Windows usi Git Bash, che si installa insieme a Git. Sul Mac usi il Terminale, che c’è già. Al passo 2 trovi come si aprono.
  • Niente conoscenze di programmazione: basta saper copiare e incollare.

Le parole da sapere

In questa guida incontri sette parole nuove, quasi tutte in inglese, perché Git e GitHub parlano inglese.

Per capirle, pensa a un documento importante e a un fotografo. Ogni volta che glielo chiedi, il fotografo scatta una fotografia del documento e la mette in un album.

Repository: la cartella con il suo album

Il repository, o repo, è la cartella del progetto insieme al suo album: tutti i file e tutte le fotografie scattate, in ordine.

Il repository sta in due posti: sul tuo computer e su GitHub.

Commit: una fotografia

Il commit è una fotografia del progetto in un certo momento.

Sul retro c’è una nota scritta da te che dice cosa è cambiato, per esempio «Aggiunta la sezione contatti». Da qualsiasi fotografia dell’album puoi ripartire.

Push e pull: mandare e scaricare

Con il push mandi le fotografie nuove dal tuo computer all’album su GitHub.

Con il pull fai il contrario. Scarichi sul computer le fotografie che stanno su GitHub e che tu non hai ancora, per esempio quelle di un collega.

Branch e merge: brutta copia e bella copia

Il branch, in italiano ramo, è una brutta copia.

Quando vuoi provare una modifica, Git ti fa lavorare su una copia del progetto, con le sue fotografie. La bella copia, che in Git si chiama main, intanto resta com’è.

Se la prova va bene, la ricopi in bella: questo è il merge, l’unione.

Se va male, butti la brutta copia, e la bella è rimasta com’era.

Pull request: la bella copia passa da un controllo

La pull request è la richiesta di ricopiare in bella passando da un controllo.

Prima di unire la brutta copia, su GitHub qualcuno la rilegge, vede cosa cambia e decide se va bene.

Illustrazione di una linea di commit con un ramo che si stacca e si riunisce
La bella copia va avanti dritta. La brutta copia si stacca per una prova e poi ci rientra.

Esistono alternative a GitHub, come GitLab o Gitea. Sono altri siti che ospitano gli album e funzionano con lo stesso Git: quello che impari qui vale anche lì.

Crea l’account GitHub

GitHub è in inglese: le voci da cliccare le trovi scritte qui come compaiono sullo schermo.

  1. Vai su github.com e premi Sign up, che vuol dire «registrati».
  2. Inserisci email, password e nome utente.
  3. Conferma con il codice che ricevi per email.

Il nome utente compare negli indirizzi dei tuoi progetti, per esempio github.com/nome-utente/sito-prova.

Sceglilo pensando che lo vedranno clienti e colleghi.

Consiglio: attiva subito l’autenticazione a due fattori: per entrare nell’account, oltre alla password, serve un codice che ti dà il telefono. La trovi cliccando sulla tua immagine del profilo in alto a destra, poi su Settings e su Password and authentication. GitHub la chiede comunque a chi pubblica codice, e un account con dentro il lavoro dei clienti deve averla dal primo giorno.

Installa Git e presentati

Su Windows vai su git-scm.com, scegli Windows e scarica il programma di installazione.

Aprilo e installa con le opzioni predefinite: a ogni schermata premi Next senza cambiare niente, poi Install, e alla fine Finish.

Insieme a Git si installa Git Bash, il terminale che usi in questa guida.

Il terminale è una finestra dove, al posto di cliccare, si scrivono comandi.

Per aprirlo premi il tasto Windows, scrivi Git Bash e premi Invio. Si apre una finestra scura con una riga che finisce con il simbolo $ e un cursore che lampeggia.

Sul Mac apri invece Terminale dalla cartella Applicazioni, sotto Utility.

Come si incolla un comando

Ogni comando di questa guida sta in un riquadro con il pulsante Copia. Premi Copia, poi in Git Bash fai clic con il tasto destro dentro la finestra e scegli Paste, cioè incolla.

Funzionano anche i tasti Maiuscole+Ins.

Se Ctrl+V non incolla niente non preoccuparti: in Git Bash spesso non funziona.

Sul Mac si incolla con Cmd+V.

Dopo aver incollato, premi Invio.

Prova con questo comando, che chiede a Git quale versione hai:

git --version

Se compare una riga che comincia con git version seguita da un numero, Git è installato.

Sul Mac, se Git manca, si apre una finestra che propone di installare gli strumenti per sviluppatori. Accetta, aspetta che finisca e rilancia il comando.

Presentati a Git

Prima di scattare la prima fotografia, Git vuole sapere chi sei: nome ed email finiscono sul retro di ogni fotografia. Usa la stessa email dell’account GitHub.

Questi due comandi li scrivi tu, perché contengono i tuoi dati.

Il primo è git config --global user.name "Nome Cognome". Scrivilo con il tuo nome e cognome al posto di Nome Cognome, lasciando le virgolette, e premi Invio.

Il secondo è git config --global user.email "[email protected]". Scrivilo con la tua email al posto di [email protected], sempre tra virgolette, e premi Invio.

Dopo questi due comandi Git non scrive niente. È normale: vuol dire che ha preso nota.

Si fa una volta sola per computer.

Avvia Git nella cartella del progetto

Sul Desktop crea una cartella nuova e chiamala sito-prova: è il tuo progetto di prova.

Ora apri Git Bash dentro questa cartella:

  • su Windows entra nella cartella, fai clic con il tasto destro in uno spazio vuoto e scegli Open Git Bash here. Su Windows 11 la voce può stare sotto Mostra altre opzioni;
  • sul Mac apri il Terminale, scrivi cd seguito da uno spazio, trascina la cartella dentro la finestra e premi Invio.

In Git Bash, nella riga sopra il simbolo $, ora leggi il percorso della cartella, che finisce con sito-prova. Sei nel posto giusto.

Adesso trasforma la cartella in un repository, cioè chiedi a Git di cominciare l’album:

git init -b main

Git risponde «Initialized empty Git repository», cioè «ho creato un repository vuoto», seguito dal percorso della cartella.

In Git Bash, accanto al percorso, compare anche (main). Da qui in poi ti dice sempre su quale copia stai lavorando.

La parte -b main del comando dà il nome main alla bella copia, lo stesso nome che usa GitHub.

Da questo momento nella cartella c’è una sottocartella nascosta che si chiama .git. Lì dentro Git tiene l’album con tutte le fotografie: non toccarla e non cancellarla.

Crea i file del progetto

Ogni file si crea allo stesso modo:

  1. apri il Blocco note: premi il tasto Windows, scrivi Blocco note e premi Invio;
  2. copia il testo del riquadro con il pulsante Copia e incollalo nel Blocco note con Ctrl+V;
  3. scegli File e poi Salva con nome, e vai nella cartella sito-prova;
  4. nella tendina Salva come scegli Tutti i file e scrivi il nome esatto del file, punto compreso;
  5. premi Salva.

Attenzione: se lasci la tendina su «Documenti di testo», il Blocco note aggiunge .txt al nome e Git vede un file diverso. Sul Mac usa TextEdit: prima di salvare scegli Formato e poi Converti in formato solo testo, e al salvataggio togli la spunta che aggiunge .txt al nome. Se il Mac avvisa che i nomi che iniziano con un punto sono riservati al sistema, conferma di voler usare il punto: il file diventa solo invisibile nel Finder.

Il primo file è la pagina del sito di prova. Chiamalo index.html: .html è la terminazione dei file delle pagine web.

index.html
<h1>Studio Bianchi</h1>
<p>Consulenza per le aziende.</p>

Il secondo è il README.md, la scheda di presentazione del progetto: cosa fa e come si usa. GitHub la mostra come prima pagina del repository.

README.md
# Sito di prova

La pagina di presentazione dello studio.

Il terzo è il .gitignore, la lista delle cose che non devono mai finire nelle fotografie. È il file più importante per la sicurezza.

Password, chiavi API e dati dei clienti non devono mai andare online, nemmeno in un repository privato.

Le chiavi API sono i codici segreti con cui un programma usa un servizio online a tuo nome. API è la sigla inglese di «interfaccia di programmazione».

.gitignore
.env
node_modules/

La prima riga tiene fuori i file che si chiamano .env, dove di solito si scrivono le password.

La seconda tiene fuori node_modules, una cartella di pezzi scaricati da internet che si trova in molti progetti per il web. Nel tuo progetto non c’è, ma averla nella lista non fa danni.

Nel nostro esempio c’è anche un file .env con una password finta. Per vedere il .gitignore all’opera crealo anche tu, con una riga inventata come PASSWORD=prova.

Grazie al .gitignore, Git non lo vedrà mai.

Tre file nella cartella, più il .env? Allora puoi scattare la prima fotografia.

Salva la prima versione: status, add, commit

Il ciclo di Git è sempre lo stesso, in tre mosse: guardi, scegli, scatti. Conviene impararlo a memoria.

Prima guardi cosa è cambiato nella cartella:

git status

Sotto la scritta «Untracked files», cioè file che Git non segue ancora, compaiono in rosso i tre file nuovi: .gitignore, README.md e index.html.

Il file .env non c’è, perché il .gitignore lo tiene fuori.

Poi scegli cosa far entrare nella fotografia. Il punto alla fine del comando vuol dire «tutto quello che è cambiato in questa cartella»:

git add .

Questo comando di solito non risponde niente. Su Windows possono comparire delle righe che cominciano con warning e parlano di LF e CRLF: sono normali, e le spieghiamo nella sezione «Se qualcosa non va».

Infine scatti la fotografia, con la sua nota tra virgolette:

git commit -m "Prima versione della pagina"

Git risponde con il nome della bella copia (main), un codice e la tua nota. Poi con «3 files changed, 7 insertions»: tre file salvati, sette righe aggiunte.

Il codice, nel nostro caso 1624b14, è il numero di quella fotografia.

Il tuo sarà diverso.

Per guardare l’album, cioè la storia del progetto, usa questo comando, che mostra una riga per ogni fotografia:

git log --oneline

Per ora c’è una riga sola: il codice e la nota della fotografia appena scattata.

Terminale con git init, git status, git add, git commit e git log nella cartella sito-prova
Quello che abbiamo visto noi. Il file .env non compare nell’elenco: lo tiene fuori il .gitignore.

Nella schermata, dopo git add, abbiamo usato git status –short, la versione corta del comando. La A davanti a ogni file vuol dire che è stato aggiunto alla fotografia.

Un file che non hai scelto con git add resta fuori dalla fotografia.

E la fotografia resta solo sul tuo computer finché non la mandi su GitHub, con il push del passo 6.

Consiglio: scrivi note che diranno qualcosa anche tra sei mesi. «Aggiunta la sezione contatti» serve, «modifiche» no. Quando cercherai la fotografia a cui tornare, leggerai solo quelle.

Crea il repository su GitHub

Ora prepari su GitHub l’album online, ancora vuoto, che riceverà le tue fotografie:

  1. su GitHub premi il + in alto a destra e scegli New repository;
  2. in Repository name scrivi il nome: quello della cartella, sito-prova, va benissimo;
  3. alla voce Choose visibility la pagina propone Public, cioè pubblico: cambialo in Private, privato, se il progetto non deve vederlo nessuno a parte te;
  4. lascia spento l’interruttore Add README e il menu del .gitignore su «No .gitignore»: quei due file li hai già nella cartella;
  5. in fondo premi Create repository.
Pagina di GitHub per creare un nuovo repository, con nome e visibilità
La pagina New repository: la visibilità proposta è Public, da cambiare in Private se il progetto è riservato. Abbiamo sfocato il nome del nostro account.

Attenzione: un repository Public lo vede chiunque, con tutto il suo album. Se per sbaglio hai messo una password in una fotografia vecchia, rendere pubblico il repository la mostra a tutti, anche se nell’ultima versione l’hai cancellata. Nel dubbio, privato.

Collega la cartella e manda tutto online

Appena creato il repository, GitHub ti mostra una pagina con dei comandi già pronti, che contengono l’indirizzo del tuo album.

Cerca la sezione «…or push an existing repository from the command line». Vuol dire «oppure manda dal terminale un repository che hai già».

Seleziona con il mouse la prima riga, quella che comincia con git remote add origin, e copiala con Ctrl+C (sul Mac Cmd+C). Incollala in Git Bash e premi Invio.

Questo comando collega la tua cartella all’album su GitHub. E dà a quell’indirizzo un soprannome, origin, così non devi riscriverlo ogni volta.

Non risponde niente, ed è normale. Ora manda le fotografie su GitHub con il primo push:

git push -u origin main

Vuol dire: «manda la bella copia, main, all’album che si chiama origin».

Al primo push su Windows si apre una finestra del Git Credential Manager, il programma che conserva l’accesso a GitHub. Scegli di accedere dal browser, entra nel tuo account e autorizza.

Da lì in poi il computer è riconosciuto. La parte -u del comando lega la bella copia del computer a quella online, così le volte successive basta scrivere git push.

Attenzione: sul Mac la finestra di accesso dal browser di solito non c’è. Git chiede nel terminale nome utente e password, ma come password GitHub non accetta quella del tuo account: vuole un codice apposito, il token. GitHub te lo mostra una volta sola, quindi copialo subito.

Il token lo crei su GitHub così:

  1. dalla tua foto in alto a destra apri Settings, poi Developer settings;
  2. apri Personal access tokens, poi Tokens (classic), e premi Generate new token;
  3. dagli un nome, spunta la casella repo e premi il pulsante verde in fondo;
  4. copia il token e incollalo quando Git chiede la password. Mentre lo scrivi il terminale non mostra niente: è normale.

Quando Git ha finito, tra le ultime righe leggi main -> main: le fotografie sono arrivate.

Ricarica la pagina del repository su GitHub. Trovi i tuoi file, il testo del README sotto l’elenco e, nella cronologia dei commit, la fotografia con la tua nota.

Il percorso al contrario: il clone

Se il progetto esiste già su GitHub e lo vuoi sul tuo computer, si fa il percorso al contrario, con il clone.

Nella pagina del repository premi il pulsante verde Code e copia l’indirizzo. Poi in Git Bash scrivi git clone, uno spazio, incolla l’indirizzo e premi Invio.

Git crea una cartella con i file e tutto l’album.

Il clone è meglio dello ZIP che GitHub propone nello stesso menu. Lo ZIP contiene solo i file di oggi, senza album e senza collegamento.

Il clone resta collegato a GitHub e si aggiorna con git pull.

Sei a metà guida, e hai già quello che mancava nella scena dell’inizio: una copia del lavoro, al sicuro su GitHub.

Adesso viene la parte più utile, le prove senza rischi.

Prova una modifica su un ramo separato e uniscila

Ecco il punto in cui Git ti salva la vita.

Vuoi aggiungere una sezione contatti senza rischiare la versione buona? Crea una brutta copia, cioè un ramo, e spostati lì:

git switch -c nuova-sezione-contatti

Git risponde «Switched to a new branch», cioè «sei passato a un ramo nuovo».

In Git Bash, accanto al percorso, ora leggi (nuova-sezione-contatti) al posto di (main). La parte -c del comando vuol dire «crealo».

Adesso modifica il file come faresti sempre. Fai clic con il tasto destro su index.html, scegli Apri con e poi Blocco note.

Sostituisci tutto il testo con questo e salva:

index.html
<h1>Studio Bianchi</h1>
<p>Consulenza per le aziende.</p>
<h2>Contatti</h2>
<p>Tel. 089 000 0000</p>

Prima di scattare la fotografia, guarda cosa è cambiato riga per riga:

git diff

Le righe aggiunte compaiono in verde con un + davanti, quelle tolte in rosso con un -. Qui vedi in verde le due righe della sezione contatti.

Poi il solito ciclo: scegli il file e scatta la fotografia.

git add index.html
git commit -m "Aggiunta la sezione contatti"

Quando sei soddisfatto, torna sulla bella copia per ricopiarci la brutta. Prima chiudi il Blocco note, poi:

git switch main

Git risponde «Switched to branch ‘main’».

Se adesso riapri index.html, la sezione contatti non c’è: sei sulla bella copia, che non è ancora cambiata. Ricopia la brutta copia in bella con il merge:

git merge nuova-sezione-contatti
Terminale con git switch, git diff, git commit e git merge del ramo nuova-sezione-contatti
La brutta copia creata, le differenze controllate, la fotografia scattata e la brutta copia ricopiata in bella.

Nel nostro caso Git scrive Fast-forward, cioè «avanti veloce». Sulla bella copia nel frattempo non era cambiato niente, e Git l’ha aggiornata da solo.

Riapri index.html e la sezione contatti c’è.

Se Git si ferma con un conflitto

Può andare diversamente se, mentre lavoravi sulla brutta copia, qualcuno ha cambiato le stesse righe anche sulla bella.

Git non sa quale versione tenere e si ferma con un conflitto. Nel file trovi le due versioni una sopra l’altra, separate da righe di segni come <<<<<<< e >>>>>>>.

Tieni la versione giusta, cancella i segni, salva e scatta la fotografia con git add e git commit, come al passo 4.

Se usi VS Code, un programma per scrivere codice, ti mostra i conflitti con dei pulsanti per scegliere la versione con un clic.

Consiglio: quando chiedi a Claude Code o a Codex una modifica corposa, faglielo fare su un ramo. Se il risultato non ti piace, torni su main e la brutta copia la butti. Se ti piace, la ricopi in bella.

Fai controllare le modifiche con una pull request

Al passo 7 hai ricopiato in bella da solo, dal terminale.

Quando si lavora in due, o quando vuoi rileggere con calma il lavoro dell’AI, conviene farlo su GitHub con una pull request. Per prima cosa manda online anche la brutta copia:

git push -u origin nuova-sezione-contatti

Poi, su GitHub:

  1. nella pagina del repository compare un avviso giallo con il pulsante Compare & pull request, cioè «confronta e chiedi l’unione»: premilo;
  2. scrivi due righe su cosa fa la modifica e premi Create pull request.

Chi controlla vede le differenze file per file, come con git diff, e può lasciare commenti sulle singole righe.

Se va bene, preme Merge pull request e poi Confirm merge: la brutta copia è ricopiata nella bella, su GitHub.

Per avere la bella copia aggiornata anche sul tuo computer, in Git Bash torna su main con git switch main. Poi scarica le novità con git pull.

La pull request è anche il posto dove fermare il codice che non ti convince. Se arriva da qualcuno che non conosci, leggilo prima di unirlo.

Illustrazione di due rami che confluiscono passando da un controllo con una lente
La pull request: prima si rilegge la brutta copia, poi la si ricopia in bella.

Torna a una versione precedente

È il motivo per cui usi Git.

Prima guarda l’album:

git log --oneline

Ogni riga è una fotografia, con il suo codice e la sua nota. La più recente è in alto.

Un file rovinato, non ancora fotografato

Hai rovinato un file e non hai ancora scattato la fotografia? Rimettilo com’era nell’ultima fotografia con git restore, seguito dal nome del file.

Nel nostro esempio il file è index.html:

git restore index.html

Il comando non risponde niente, e le modifiche non salvate di quel file spariscono. Se lo lanci adesso non succede nulla, perché non hai modifiche in sospeso.

Una fotografia sbagliata, già scattata

Vuoi annullare una fotografia già scattata, magari già mandata su GitHub? Il modo sicuro è il revert.

Git scatta una fotografia nuova che rimette le cose com’erano prima di quella sbagliata. E dall’album non toglie niente.

HEAD, nel comando, vuol dire «l’ultima fotografia». Al suo posto puoi scrivere il codice di una fotografia qualsiasi, preso da git log.

git revert --no-edit HEAD

La parte –no-edit dice a Git di usare da solo una nota già pronta: «Revert» seguito dalla nota della fotografia annullata. Senza, Git ti aprirebbe un programma per scriverla tu.

Nel nostro caso il revert ha tolto le due righe della sezione contatti. Lanciando di nuovo git log –oneline si vedono tre fotografie: la nuova in cima, le due vecchie ancora al loro posto.

Se invece Git risponde con un errore che contiene «is a merge», trovi la soluzione nella sezione «Se qualcosa non va».

Terminale con git log e git revert che annulla l'ultimo commit
Il revert aggiunge una fotografia che toglie la sezione contatti. Le fotografie di prima restano tutte nell’album.

Attenzione: in giro trovi spesso un altro comando, git reset –hard. È come strappare le pagine dell’album: butta via le fotografie successive e le modifiche non salvate, senza chiedere conferma. Se l’album è già su GitHub e lo usano anche altri, crea un sacco di problemi. Per tornare indietro usa revert.

Git con Claude Code e Codex

Claude Code e Codex conoscono Git molto bene. Puoi chiedere a parole «fai un commit con un messaggio chiaro», «crea un ramo per questa prova», «mostrami cosa hai cambiato».

La regola che usiamo noi è semplice: una fotografia prima di ogni richiesta importante. Così c’è sempre un punto pulito a cui tornare.

Il push lo decidiamo noi, dopo aver guardato le modifiche.

Lo stesso metodo lo applichiamo ai siti, alle automazioni e agli strumenti che costruiamo per i clienti. Se ti interessa come lavoriamo con l’AI in azienda, ne parliamo nell’articolo sulle automazioni AI per le piccole imprese.

E se ti incuriosisce Docker, il programma che fa funzionare altri programmi dentro delle scatole chiuse, la nostra guida a Docker per principianti parte da zero come questa.

Il file compose.yaml che prepari lì può andare in un repository, come hai fatto qui con i tuoi file. Le password vere vanno invece in un file .env, che il .gitignore tiene fuori.

Git ti salva dagli errori, tuoi e dell’AI. Il sito, però, qualcuno lo deve costruire bene fin dal primo giorno.

Vuoi che lo facciamo noi, mentre tu pensi ai clienti? Il sito per la tua attività lo trovi descritto qui, costo compreso.

Se qualcosa non va

«Author identity unknown» al primo commit

Git non sa chi sei, quindi non sa cosa scrivere sul retro della fotografia. Lancia i due comandi git config del passo 2 e ripeti il commit.

Avvisi «LF will be replaced by CRLF»

Ogni riga di un file di testo finisce con un segno invisibile che vuol dire «a capo». Windows e Linux, due sistemi operativi, lo scrivono in modo diverso, e Git su Windows converte dall’uno all’altro.

Questi avvisi te lo segnalano: sono normali, non rompono niente e puoi ignorarli. Noi li abbiamo tolti dalle schermate per renderle leggibili.

«fatal: not a git repository»

Git Bash è aperto nella cartella sbagliata, oppure non hai lanciato git init. Scrivi pwd e premi Invio: Git Bash ti mostra in quale cartella sei.

Se non è quella del progetto, chiudilo e riaprilo dentro la cartella giusta, come al passo 3.

Il push viene rifiutato con «rejected» e «fetch first»

Su GitHub c’è una fotografia che tu non hai, per esempio un README creato dal sito. Scarica prima le novità con git pull, risolvi gli eventuali conflitti come spiegato al passo 7 e ripeti il push.

«remote origin already exists»

Il collegamento all’album su GitHub c’è già. Se l’indirizzo è sbagliato, correggilo con git remote set-url origin seguito dall’indirizzo giusto.

«is a merge but no -m option was given»

Stai annullando con git revert una fotografia che è un’unione, per esempio quella che GitHub crea quando premi Merge pull request al passo 8. Git vuole sapere a quale delle due copie tornare.

Scrivi git revert –no-edit -m 1 HEAD: la parte -m 1 vuol dire «torna alla bella copia com’era prima dell’unione».

Ho messo una password in un commit

Cambia subito la password o la chiave, perché va considerata esposta.

Poi aggiungi il nome del file al .gitignore e scrivi git rm –cached seguito dal nome del file. Git smette di metterlo nelle fotografie, ma il file resta sul tuo computer. Chiudi con un commit, come al passo 4.

Toglierlo anche dalle fotografie vecchie è un lavoro da tecnici, con programmi appositi. Se il repository è pubblico, il cambio della password viene prima di tutto.

Domande frequenti

Che differenza c’è tra Git e GitHub?

Git è il programma che scatta le fotografie e tiene l’album sul tuo computer, e funziona anche senza internet. GitHub è il sito che tiene l’album anche online e ci aggiunge il lavoro in gruppo, le pull request e un posto sicuro fuori dal tuo computer.

GitHub è gratis?

Il piano gratuito permette repository pubblici e privati senza limite di numero, e basta per lavorare da soli o in piccoli gruppi. I piani a pagamento aggiungono funzioni per gruppi di lavoro e aziende.

Meglio GitHub Desktop o il terminale?

GitHub Desktop, il programma di GitHub da installare sul computer, e il pannello Source Control di VS Code, cioè il pannello delle versioni, fanno le stesse cose con i pulsanti. Conviene comunque capire i comandi: sono quelli che usano Claude Code e Codex, e quando qualcosa va storto gli errori compaiono scritti così.

Posso usare Git anche per un sito WordPress?

Sì, per il tema e i plugin che sviluppi tu. Il database, cioè l’archivio dove WordPress salva pagine e articoli, e le immagini caricate non si mettono su Git. Per quelli servono i backup del sito, cioè i salvataggi completi che si fanno a parte.

Con GitHub si può pubblicare un sito?

Sì, con GitHub Pages, che pubblica siti statici: pagine fatte di HTML, CSS e JavaScript prese da un repository. Con il piano gratuito funziona dai repository pubblici. Un sito WordPress invece lì non gira, perché ha bisogno di un database.

Cosa succede se cancello la cartella del progetto?

Se avevi fatto il push, l’album è al sicuro su GitHub: lo riprendi con git clone, come spiegato al passo 6. Se non l’avevi mai mandato online, è perso insieme alla cartella.

Il sito della tua attività, senza terminale

Git tienilo per le tue prove. Se il sito vero preferisci che lo costruisca e lo curi qualcun altro, nella pagina c'è il nostro modo di lavorare, con i costi.

Vedi come lavoriamo

Articoli correlati

Come collegare Meta Ads a Claude con il connettore ufficiale: la guida passo passo

Come collegare Meta Ads a Claude con il connettore MCP ufficiale di Meta: passi con le schermate, permessi giusti e regole contro le spese a sorpresa.

Continua la lettura »
Docker per principianti: cos'è, a cosa serve e come accendere un sito WordPress di prova sul tuo computer

Docker per principianti: cos’è, a cosa serve e come accendere un sito WordPress di prova sul tuo computer in sette passi, con i comandi pronti da copiare.

Continua la lettura »
Guida a Chatpilot per WhatsApp: come attivare i messaggi automatici ai lead dal tuo numero, passo per passo

Guida a Chatpilot per WhatsApp: come attivarlo passo passo, collegare il numero col QR, i moduli di Facebook e del sito, il Bot AI e i problemi comuni.

Continua la lettura »