Come usare Git e GitHub (guida pratica)
Guida pratica su come usare Git e GitHub: differenza tra i due, comandi base con esempi, flusso add/commit/push, branch e pull request spiegati semplice.
Git e GitHub sono due strumenti che userai ogni giorno da sviluppatore, eppure all'inizio confondono parecchio. La buona notizia è che ti bastano una manciata di comandi per essere operativo, e li impari in un pomeriggio.
In questo articolo ti spiego come usare Git e GitHub in modo pratico: la differenza tra i due, i comandi base con esempi, il flusso add/commit/push, l'uso dei branch e cosa sono le pull request.
Cos'è Git in parole semplici
Git è un sistema di controllo di versione: tiene traccia di ogni modifica al tuo codice, ti permette di tornare indietro nel tempo e di lavorare in team senza pestarvi i piedi. GitHub, invece, è un servizio online dove ospiti i tuoi repository Git e collabori con altri.
In breve: Git è lo strumento che gira sul tuo computer; GitHub è la piattaforma (di proprietà di Microsoft) dove i progetti vivono online. Puoi usare Git senza GitHub, ma insieme diventano potentissimi.
Installazione e configurazione iniziale
Scarica Git da git-scm.com. Subito dopo, configura nome ed email che compariranno nei tuoi salvataggi:
git config --global user.name "Il Tuo Nome"
git config --global user.email "[email protected]"
Lo fai una sola volta. Da quel momento Git ti riconosce.
I concetti fondamentali
Git lavora su tre "aree":
- Working directory: i file su cui stai lavorando.
- Staging area: i file che hai selezionato per il prossimo salvataggio.
- Repository: la cronologia dei salvataggi (i commit) salvata definitivamente.
Capire questo passaggio (modifica → staging → commit) ti chiarisce metà dei comandi.
Il flusso base: add, commit, push
Questo è il ciclo che ripeterai migliaia di volte.
1. Inizializza un repository nella cartella del progetto:
git init
2. Controlla cosa è cambiato in qualsiasi momento:
git status
3. Aggiungi i file alla staging area (il punto seleziona tutto):
git add .
4. Crea un commit, una "fotografia" del progetto con un messaggio:
git commit -m "Aggiunta pagina di login"
5. Collega il repository a GitHub e invia il codice online. Dopo aver creato un repository vuoto su GitHub:
git remote add origin https://github.com/tuonome/mio-progetto.git
git push -u origin main
Da qui in avanti, per inviare nuovi commit ti basta git push. Per scaricare le novità da GitHub usi git pull.
Lavorare con i branch
Un branch (ramo) è una linea di sviluppo separata. Ti permette di lavorare a una nuova funzionalità senza toccare il codice stabile. È una delle cose più potenti di Git.
git branch login # crea un branch chiamato "login"
git checkout login # ci si sposta sopra
# ...lavori e fai commit...
git checkout main # torni al ramo principale
git merge login # fondi le modifiche del branch login in main
In pratica: sviluppi in tranquillità sul tuo ramo, e quando la funzionalità è pronta la unisci al ramo principale. Se qualcosa va storto, main è rimasto intatto.
Cosa sono le pull request
Le pull request (PR) sono una funzione di GitHub, non di Git. Servono a proporre le modifiche di un branch perché vengano riviste e poi unite. Il flusso tipico in un team è:
- Crei un branch per la tua funzionalità.
- Fai commit e
git pushdel branch su GitHub. - Apri una pull request dalla pagina del repository.
- Un collega rivede il codice, lascia commenti, eventualmente chiede modifiche.
- Una volta approvata, la PR viene unita (merge) in
main.
È il cuore della collaborazione moderna: nessuno scrive direttamente sul ramo principale, tutto passa da una revisione.
Comandi che userai spesso
| Comando | Cosa fa |
|---|---|
git status | Mostra lo stato dei file |
git add . | Aggiunge tutto alla staging area |
git commit -m "..." | Salva una fotografia del progetto |
git push | Invia i commit su GitHub |
git pull | Scarica le novità da GitHub |
git log | Mostra la cronologia dei commit |
git branch | Elenca i branch |
git checkout <nome> | Si sposta su un branch |
git clone <url> | Scarica un repository esistente |
Errori comuni da evitare
- Messaggi di commit inutili come "fix" o "aggiornamento". Descrivi cosa hai fatto.
- Commit enormi con cento file cambiati. Meglio commit piccoli e frequenti.
- Caricare file che non dovrebbero stare lì (password,
node_modules). Usa un file.gitignore. - Lavorare sempre su
main. Prendi l'abitudine dei branch.
In sintesi
Git tiene la cronologia del tuo codice, GitHub lo ospita online e ti fa collaborare. Il flusso base è sempre lo stesso: add, commit, push. Aggiungi i branch per lavorare in sicurezza e le pull request per collaborare, e hai tutto ciò che serve nel quotidiano.
Git e GitHub sono solo una delle competenze che ti accompagnano da sviluppatore. Se vuoi un percorso guidato che le inserisca nel contesto giusto insieme a tutto il resto, dai un'occhiata ai miei corsi.