Ti è mai capitato di ritrovarti con una cartella piena di file chiamati progetto_finale, progetto_finale_2, progetto_finale_VERO? È il modo artigianale di tenere le versioni di un lavoro. Git fa la stessa cosa, ma bene: registra ogni modifica ai file di un progetto e ne conserva la cronologia, così puoi confrontare due versioni, tornare a quella di tre settimane fa o lavorare in due sullo stesso materiale senza cancellarvi il lavoro a vicenda.
Su Windows però Git non c’è: va scaricato e configurato a mano, ed è qui che chi parte da zero si blocca, perché l’installazione fa una decina di domande tecniche di fila. Questa guida segue tre tappe: le opzioni dell’installer che contano, i cinque comandi di tutti i giorni, e cosa cambia quando lavori con altre persone.
Git e GitHub non sono la stessa cosa
Sono due parole quasi sempre appaiate, e confonderle è il primo ostacolo. Git è il programma installato sul tuo computer: funziona offline, senza account da nessuna parte, anche se non pubblichi niente. GitHub è un sito che ospita online i progetti gestiti con Git — nato nel 2008 e acquistato da Microsoft nel 2018 — e serve a condividerli e a lavorarci in più persone.
La distinzione è pratica: puoi usare Git da solo per anni senza toccare GitHub, e puoi caricare file su GitHub dal browser senza sapere un comando. Qui li usiamo insieme, che è il caso più comune. Del solo lato online — aprire un account, le issue, le pull request, la scelta tra progetto pubblico e privato — si occupa la guida su cos’è GitHub e come si crea un repository.
Un’ultima parola da chiarire subito, perché tornerà in continuazione: repository è la cartella del progetto insieme a tutta la sua cronologia. Quella sul tuo computer è il repository locale, la copia online quello remoto. Nel gergo quotidiano diventa spesso repo.
Scaricare Git e attraversare l’installer
Il file si prende dal sito ufficiale di Git, sezione download per Windows: quasi sempre serve la versione a 64 bit (esiste anche una variante Portable, che non si installa). Chi ha Winget, il gestore di pacchetti di Windows, salta il giro dal Prompt dei comandi aperto come amministratore: winget install –id Git.Git -e –source winget.
Insieme a Git arriva Git Bash, un terminale che riproduce su Windows l’ambiente a riga di comando tipico di Linux: è da lì che darai i comandi.
Poi comincia la sfilata di schermate. La regola generale: lascia i valori predefiniti e tocca solo quello che capisci. Tre schermate però meritano attenzione.
La prima è l’editor di testo, quello che Git aprirà per far scrivere i messaggi che accompagnano ogni salvataggio. L’installer propone spesso Vim, un editor storico e potentissimo che per un principiante è una trappola: si apre e non è ovvio nemmeno come uscirne. Se nell’elenco compare qualcosa che già conosci — Visual Studio Code, Notepad++, Nano — scegli quello. Più avanti vedrai comunque come non farlo aprire affatto.
La seconda è il PATH, l’elenco delle cartelle in cui Windows cerca i programmi quando scrivi un comando. Conviene tenere l’opzione che rende Git disponibile sia dalla riga di comando sia ai programmi esterni. Senza, lo useresti soltanto dentro Git Bash; con, risponde ovunque: PowerShell, il Prompt dei comandi, il terminale incorporato nel tuo editor.
La terza riguarda i caratteri di fine riga, che Windows e i sistemi Unix scrivono in modo diverso. Non lo noti finché lo stesso progetto non passa tra computer con sistemi operativi differenti: a quel punto Git segnala come modificate righe che nessuno ha toccato. L’opzione adatta a chi sta su Windows preleva i file con i fine riga in stile Windows e li registra in stile Unix.
Sulle altre schermate si tira dritto: OpenSSH, OpenSSL per il trasporto HTTPS, MinTTY come terminale di Git Bash e main come nome del ramo iniziale, lo stesso che GitHub assegna oggi ai nuovi progetti. I collegamenti simbolici si attivano solo se sai di averne bisogno. Poi Install, e si attende.
Ha funzionato?
Da un terminale qualsiasi — PowerShell, Git Bash, il Prompt — la verifica è git –version. Vedere un numero stampato significa che è andata. Se invece il comando risulta sconosciuto, riavvia il terminale, o il computer, e riprova; quando nemmeno questo basta, reinstalla tenendo d’occhio la schermata del PATH.
Le due righe da scrivere prima di tutto il resto
Ogni salvataggio porta il nome di chi lo ha fatto, quindi Git vuole sapere chi sei prima di lasciartene creare uno:
- git config –global user.name “Il tuo nome”
- git config –global user.email “[email protected]”
La parola global qui significa “per tutti i progetti di questo utente Windows”, non “per tutto il mondo”: la scrivi una volta e vale ovunque (git config –global –list te la rilegge). Il nome può differire dal tuo nome utente GitHub; l’email invece conta, perché la piattaforma attribuisca i salvataggi al tuo profilo deve essere un indirizzo verificato nel tuo account, o quello riservato che GitHub stesso fornisce.
Portare il progetto sul computer
Con un repository già aperto su GitHub, la copia sul computer si fa con la clonazione: scarica non solo i file, ma l’intera cronologia e i riferimenti che tengono allineate le due copie.
Sulla pagina del progetto premi il pulsante Code, scegli tra HTTPS e SSH, copia l’indirizzo. Nel terminale raggiungi la cartella dove vuoi tenere il progetto — si cambia cartella con cd seguito dal percorso tra virgolette — e lanci git clone con l’indirizzo copiato, per esempio git clone https://github.com/nomeutente/progetto.git. Git crea una cartella col nome del progetto e ci entri con cd progetto.
Da lì git remote mostra a quale copia online sei collegato, e comparirà quasi certamente la parola origin: è solo il soprannome che Git assegna in automatico al repository da cui hai clonato. Con -v vedi anche gli indirizzi, su due righe: una per lo scaricamento (fetch), una per l’invio (push).
Perché la tua password GitHub non funziona
Sul repository privato, o al primo tentativo di inviare qualcosa, GitHub vuole sapere chi sei. Con un indirizzo HTTPS interviene Git Credential Manager, installato insieme a Git: apre una finestra del browser dove accedi e autorizzi, e la questione è chiusa.
Il punto che disorienta quasi tutti: se ti viene chiesta una password a mano, quella normale dell’account GitHub non vale per le operazioni Git su HTTPS. Serve invece un token di accesso personale — una password generata dalla piattaforma per una singola applicazione — o un altro metodo supportato, per esempio SSH con una coppia di chiavi registrata nel proprio account.
Il giro quotidiano: cinque comandi e nient’altro
Qui sta il cuore della faccenda, ed è una buona notizia: il lavoro di ogni giorno gira attorno a cinque comandi. Modifichi i file con l’editor che preferisci — Git non te ne impone nessuno e non devi scrivere codice nel terminale — poi controlli, selezioni, salvi e invii.
git status è quello che userai di più: dice su quale ramo sei, quali file hai toccato, quali Git non ha mai visto prima (li elenca come untracked files) e quali sono già pronti per il salvataggio. Nel dubbio, lancialo.
Poi si scelgono le modifiche da salvare, in un passaggio chiamato staging che è il concetto meno intuitivo di Git: prima di registrare qualcosa metti da parte esattamente le modifiche che vuoi in quel salvataggio, lasciando fuori le altre. Il comando è git add col nome del file; un punto al posto del nome prende tutta la cartella corrente (git add .), e un file messo da parte per sbaglio esce dalla selezione con git restore –staged nomefile, senza sparire dal disco.
Il salvataggio vero e proprio è il commit: fotografa nel repository locale ciò che avevi selezionato, con un messaggio che spiega cosa hai fatto. Il messaggio si scrive sulla riga di comando con l’opzione -m, per esempio git commit -m “Aggiunto il primo file di esempio”. Senza -m si apre l’editor scelto in fase di installazione, ed è lì che si finisce intrappolati in Vim: se capita, premi Esc, digita :wq e Invio per salvare e uscire, oppure :q! per uscire buttando via.
Attenzione alla cosa che confonde quasi tutti all’inizio: dopo il commit il lavoro è al sicuro solo sul tuo computer, e su GitHub non c’è ancora niente. Ci arriva con git push. La prima volta su un ramo nuovo può servire indicare dove — git push -u origin main — perché la -u stabilisce il collegamento una volta per tutte: da lì in poi basta git push secco.
Il quinto comando è git pull, che va nel senso opposto: scarica quello che gli altri hanno pubblicato e lo integra nel tuo lavoro. Conviene come abitudine prima di inviare le proprie modifiche, perché se online c’è qualcosa che sul tuo computer manca, Git può rifiutare il push finché non ti sei allineato. Ha un parente stretto, git fetch, che scarica solo le informazioni e lascia intatti i file nella tua cartella: è la scelta prudente quando vuoi guardare prima e decidere dopo.
Per rivedere cosa è successo c’è git log, o meglio git log –oneline, che comprime tutto a una riga per commit. Ogni commit porta un codice identificativo univoco chiamato hash, oltre ad autore, data e messaggio.
I branch: lavorare senza rompere quello che funziona
Un branch — o ramo — è una linea di sviluppo separata dal progetto principale. Serve per provare qualcosa che potrebbe non funzionare: una funzione nuova, la correzione di un errore, un lavoro lungo che nel frattempo lascerebbe instabile la versione buona. Ci lavori isolato e, quando è pronto, lo riunisci al ramo principale.
Il modo attuale di crearne uno ed entrarci nello stesso momento è git switch -c nome-branch; i comandi di vecchia scuola, che troverai in mezza Internet e funzionano ancora, sono git branch nome-branch seguito da git checkout nome-branch. Da lì git branch elenca i rami segnando con l’asterisco quello attivo, git switch nome-branch ti sposta tra quelli esistenti e git switch main riporta al principale. Il ramo creato sul tuo computer resta invisibile agli altri finché non lo pubblichi con git push -u origin nome-branch.
La riunione si chiama merge: torni su main, lo aggiorni con git pull, unisci con git merge nome-branch, invii con git push. A lavoro concluso il ramo si elimina con git branch -d nome-branch in locale e git push origin –delete nome-branch su GitHub — due cancellazioni indipendenti, perché togliere la copia online non tocca quella locale.
Quando due modifiche si scontrano
Il conflitto di merge spaventa più di quanto meriti. Succede quando due persone cambiano lo stesso punto dello stesso file in modi che Git non sa conciliare da solo. A quel punto Git si ferma, non decide al posto tuo, e scrive dentro il file dei marcatori che delimitano le due versioni in competizione.
La risoluzione è manuale: apri quei file, tieni il contenuto giusto, togli i marcatori. Poi riparte il giro normale — git add ., un commit che dica cosa hai risolto, git push — mentre git status tiene il conto dei file ancora aperti e di quelli già sistemati. Su progetti grossi si può passare a un programma di confronto visuale, il merge tool, richiamato con git mergetool.
I cinque intoppi che incontrerai davvero
Sono sempre gli stessi, e hanno tutti una soluzione breve.
- “git non è riconosciuto come comando” — chiudi e riapri il terminale; se insiste, reinstalla controllando che Git finisca nel PATH.
- Il push viene rifiutato — online c’è qualcosa che a te manca. git pull, risolvi eventuali conflitti, riprova.
- GitHub rifiuta la password — su HTTPS non si usa quella dell’account: Git Credential Manager, accesso via browser, token personale o SSH.
- Un file non compare nel commit — quasi sempre manca il git add: chiedilo a git status. L’altra ipotesi è che a escluderlo sia un .gitignore, il documento dove si elencano i file che Git deve saltare.
- Il ramo main non esiste — molti progetti nati anni fa lo chiamano master. git branch mostra i nomi locali, git branch -a anche quelli online.
Riga di comando o interfaccia grafica
Esistono programmi che fanno tutto questo a colpi di mouse, e sono comodi. Il motivo per imparare comunque i comandi è che guide, documentazione e risposte che troverai cercando un errore sono scritte in comandi: chi conosce solo i pulsanti resta senza appigli quando qualcosa si inceppa. Il compromesso che usano in molti: il codice si scrive nell’editor di sempre, il terminale resta aperto per le cinque operazioni ricorrenti. Il resto arriva quando serve, un pezzo alla volta.
Lascia un commento