1. Il problema senza controllo delle versioni: perché copiare semplicemente i file è una cattiva idea
Partiamo da una situazione reale. Immaginate di lavorare al vostro progetto Java. Tutto procede bene finché non arriva il momento degli «esperimenti». Decidete di cambiare qualcosa, ma temete di rompere la versione funzionante. Che fare? Ovviamente, copiare il progetto!
Di conseguenza sul vostro disco compaiono questi capolavori:
MyProject/
├── Main.java
├── Main_backup.java
├── Main_final.java
├── Main_final2.java
├── Main_tochno_final.java
├── Main_tochno_tochno_final.java
Vi suona familiare? E adesso immaginate che al progetto si unisca anche un amico. Anche lui ama copiare i file — ma a modo suo. Come capire qual è la versione più aggiornata e funzionante? Come sapere chi ha cambiato cosa? Come ripristinare tutto se l’esperimento non è riuscito?
Senza controllo delle versioni:
- È facile perdere o confondere il codice funzionante.
- È impossibile «tornare indietro» a una versione precedente.
- È difficile lavorare in due o in tre.
- Caos e paura degli esperimenti.
Proprio questi problemi vengono risolti dai sistemi di controllo versione — come Git.
2. Perché uno sviluppatore ha bisogno di Git?
Git è un potente sistema di controllo versione, usato per tracciare le modifiche al codice sorgente durante lo sviluppo del software. Permette agli sviluppatori di salvare diverse versioni dei file e di coordinare il lavoro di più persone su un progetto comune.
Concetti di base di Git:
Repository
Il repository (o «repo») è il luogo in cui è conservata tutta la storia del progetto, inclusi tutti i cambiamenti e le versioni dei file.
Commit
commit è lo stato salvato del progetto. Ogni commit in Git contiene informazioni su quali modifiche sono state apportate al progetto, da chi e quando. I commit formano la storia del progetto e permettono di tornare a qualsiasi versione precedente.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
Ogni commit è uno «snapshot» del progetto, che segue il precedente, formando una storia sequenziale delle modifiche.
Branch
branch è una linea di sviluppo indipendente. Per impostazione predefinita Git crea il branch main. Potete creare nuovi branch per sviluppare nuove funzionalità o correzioni, quindi unirli di nuovo al branch principale.
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
Dal branch principale main si dirama il branch develop per lo sviluppo in parallelo. Al termine del lavoro, le modifiche da develop vengono fuse di nuovo in main.
3. Comandi principali di Git (ciò che c’è «sotto il cofano»)
Di seguito trovate un elenco dei comandi principali per lavorare con Git tramite terminale. È importante capire quali comandi stanno alla base di tutte le operazioni. Tuttavia, seguiremo un approccio GUI e impareremo a eseguire tutte queste azioni tramite la comoda interfaccia grafica di IntelliJ IDEA. Considerate questi comandi come ciò che accade «sotto il cofano».
| Comando | Descrizione |
|---|---|
git init |
Inizializza un nuovo repository Git nella directory corrente. |
git clone |
Clona un repository da un URL in una nuova directory. |
git add |
Aggiunge i file all’index per il prossimo commit. |
git commit |
Registra le modifiche preparate nel repository. |
git push |
Invia le modifiche dal repository locale a quello remoto. |
git pull |
Aggiorna il branch corrente con l’ultima versione dal repository remoto. |
git branch |
Mostra, crea o elimina branch. |
git merge |
Unisce (merge) le modifiche del branch specificato nel branch corrente. |
Questi comandi rappresentano gli strumenti di base in Git, permettendo di gestire le modifiche al codice, i branch e i merge in progetti di qualsiasi dimensione.
sequenceDiagram
participant Directory di lavoro
participant Area di staging (Staging)
participant Repository locale
participant Repository remoto
Directory di lavoro ->> Area di staging (Staging): git add (Preparare)
Area di staging (Staging) ->> Repository locale: git commit (Salvare localmente)
Repository locale ->> Repository remoto: git push (Inviare al server)
Repository remoto ->> Directory di lavoro: git pull (Scaricare aggiornamenti)
4. Tre luoghi di conservazione del codice
Quando userete un sistema di controllo versione per il vostro codice, in sostanza verrà conservato in tre luoghi:
1. Repository remoto
È il luogo centralizzato per la conservazione del vostro codice, di solito ospitato su servizi come GitHub, GitLab o Bitbucket. Forniscono l’archiviazione centralizzata del codice e sono alla base della collaborazione. Il repository remoto funge da punto di integrazione per l’automazione di processi come build, test e distribuzione delle applicazioni.
2. Repository locale
Il repository locale è la vostra copia personale del codice, conservata sul vostro computer. In questo repository potete eseguire tutte le operazioni Git (commit, branch, merge) senza necessità di connessione a Internet.
3. Directory di lavoro
La directory di lavoro sul vostro computer contiene i file attuali del progetto su cui state lavorando in questo momento. È il posto in cui potete vedere e modificare i file, aggiungere nuove funzionalità o correggere bug.
Questi componenti insieme forniscono un’infrastruttura potente per la gestione del codice sorgente, permettendo agli sviluppatori di gestire la storia del progetto e collaborare.
5. GitHub — il vostro portfolio
GitHub è la principale piattaforma web per l’hosting del codice sorgente, che utilizza il sistema di controllo versione Git. Fondata nel 2008, è rapidamente diventata uno degli strumenti chiave per gli sviluppatori di tutto il mondo.
GitHub consente agli utenti di creare repository per gestire i progetti, controllare e tracciare le modifiche al codice e collaborare con altri sviluppatori. Per uno sviluppatore moderno, il profilo su GitHub è una parte importante del portfolio da mostrare ai potenziali datori di lavoro.
6. Creazione del vostro primo repository su GitHub
Passo 1. Andate su https://github.com e registratevi.
Passo 2. Fate clic sul pulsante New repository per creare un nuovo repository.
Passo 3. Impostate i parametri per il repository:
- Nome del repository: scegliete un nome significativo.
- Pubblico o privato: per i progetti didattici è meglio scegliere «Public», così che altri possano vederlo.
- Add a README file: spuntate assolutamente questa casella. Il README è il «biglietto da visita» del vostro progetto.
- Add .gitignore: fate clic sull’elenco a discesa e scegliete il template per il vostro linguaggio.
- Choose a license: si può saltare.
- Fate clic su
Create repository.
Passo 4. Congratulazioni, il vostro primo repository remoto è stato creato!
7. Installazione e configurazione di Git
Sebbene le basi di Git possano essere studiate tramite comandi da console (come mostrato nel video), nel lavoro quotidiano il 99% degli sviluppatori utilizza strumenti comodi integrati nell’ambiente di sviluppo. Il nostro obiettivo è insegnarvi a lavorare come fanno i professionisti.
L’interfaccia per lavorare con Git in tutte le moderne IDE di JetBrains — che si tratti di IntelliJ IDEA per Java/Kotlin, Rider per C# o PyCharm per Python — è praticamente identica. Ciò significa che, una volta imparato a lavorare con Git in un ambiente, potrete applicare facilmente queste competenze in qualsiasi altro. Per questo useremo IntelliJ IDEA come esempio universale. Tutto ciò che vedrete qui avrà lo stesso aspetto e funzionerà allo stesso modo anche nella vostra IDE preferita.
Per lavorare con Git sul vostro computer, Git deve essere prima installato. Se usate IntelliJ IDEA, molto probabilmente vi proporrà di installare Git automaticamente se non viene trovato nel sistema. Vi consigliamo di accettare questa proposta — è la via più semplice.
Chiudete il progetto corrente scegliendo File > Close Project e fate clic su Clone Repository.
Se invece desiderate installarlo manualmente, utilizzate il sito ufficiale: https://git-scm.com/downloads.
8. Un po’ di storia: main vs master
In passato il branch predefinito in Git si chiamava master. Tuttavia, nel 2020 la comunità degli sviluppatori e le maggiori piattaforme, tra cui GitHub, sono passate all’uso di un termine più neutro — main.
È importante saperlo, poiché in alcuni articoli o progetti più vecchi potete ancora trovare il branch master. Nelle nostre lezioni e nei progetti moderni il branch principale sarà sempre main.
Potete saperne di più sul passaggio a main ai seguenti link:
GO TO FULL VERSION