1. Il problema senza controllo delle versioni: perché copiare semplicemente i file è una pessima idea
Cominciamo con una situazione reale. Immagina di lavorare al tuo progetto Java. Tutto procede bene, finché arriva il momento degli "esperimenti". Decidi di cambiare qualcosa, ma hai paura di rompere la versione funzionante. Che fare? Ovviamente, copiare il progetto!
Alla fine sul tuo disco appaiono capolavori del genere:
MyProject/
├── Main.java
├── Main_backup.java
├── Main_final.java
├── Main_final2.java
├── Main_tochno_final.java
├── Main_tochno_tochno_final.java
Suona familiare? Ora immagina che un amico si unisca al progetto. Anche a lui piace copiare i file — ma a modo suo. Come capire qual è la versione più recente e funzionante? Come sapere chi ha cambiato cosa? Come tornare indietro se l'esperimento fallisce?
Senza controllo delle versioni:
- È facile perdere o confondere il codice funzionante.
- Non è possibile "rollback" a una versione precedente.
- Difficile lavorare in due o tre persone contemporaneamente.
- Caos e paura di sperimentare.
Proprio questi problemi risolvono i sistemi di controllo delle versioni — come Git.
2. Perché a uno sviluppatore serve Git?
Git — è un potente sistema di versioning, usato per tracciare le modifiche al codice sorgente durante lo sviluppo del software. Permette agli sviluppatori di salvare diverse versioni dei file e coordinare il lavoro di più persone su uno stesso progetto.
Concetti principali di Git:
Repository
Il repository (o "repo") è il posto dove è conservata tutta la storia del progetto, incluse tutte le modifiche e le versioni dei file.
Commit
commit — è uno stato salvato del progetto. Ogni commit in Git contiene informazioni su quali cambiamenti sono stati fatti al progetto, da chi e quando. I commit formano la storia del progetto e permettono di tornare a qualunque 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 sequenza di modifiche.
Branch
branch — è una linea indipendente di sviluppo. Per default Git crea il branch main. Puoi creare nuovi branch per sviluppare nuove feature o fix e poi 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 "biforca" il branch develop per sviluppi paralleli. Dopo aver finito il lavoro, le modifiche da develop vengono merge-ate di nuovo in main.
3. Comandi principali di Git (quello che succede sotto il cofano)
Qui sotto trovi la lista dei comandi base per lavorare con Git tramite terminale. È importante capire quali comandi stanno alla base di tutte le operazioni. Tuttavia useremo soprattutto l'approccio GUI e impareremo a fare tutte queste azioni con l'interfaccia grafica comoda di IntelliJ IDEA. Considera questi comandi come ciò che succede "sotto il cofano".
| Comando | Descrizione |
|---|---|
git init |
Inizializza un nuovo Git-repository nella directory corrente. |
git clone |
Clona un repository da un URL in una nuova directory. |
git add |
Aggiunge 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 le modifiche del branch specificato nel branch corrente. |
Questi comandi rappresentano gli strumenti principali per lavorare con Git, permettendo di gestire le modifiche al codice, i branch e le merge in progetti di qualsiasi dimensione.
sequenceDiagram
participant Directory_di_lavoro
participant Area_di_index (Staging)
participant Repository_locale
participant Repository_remoto
Directory_di_lavoro ->> Area_di_index (Staging): git add (Preparare)
Area_di_index (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 posti dove il codice viene conservato
Quando usi un sistema di controllo delle versioni per il tuo codice, grossolanamente parlando, viene conservato in tre posti:
1. Repository remoto
Questo è il posto centralizzato dove viene conservato il tuo codice, di solito ospitato su servizi come GitHub, GitLab o Bitbucket. Forniscono storage centralizzato del codice e sono la base per il lavoro collaborativo. Il repository remoto serve come punto di integrazione per processi automatizzati come build, test e deploy delle applicazioni.
2. Repository locale
Il repository locale è la tua copia personale del codice, conservata sul tuo computer. In questo repository puoi eseguire tutte le operazioni di Git (commit, branching, merge) senza bisogno di essere connesso a Internet.
3. Directory di lavoro
La directory di lavoro sul tuo computer contiene i file attuali del progetto su cui stai lavorando in questo momento. È il posto dove puoi vedere e modificare i file, aggiungere nuove funzionalità o correggere bug.
Questi componenti insieme forniscono una solida infrastruttura per la gestione del codice sorgente, permettendo agli sviluppatori di gestire la storia del progetto e collaborare.
5. GitHub — il tuo portfolio
GitHub — è la principale piattaforma web per l'hosting del codice sorgente, che utilizza il sistema di controllo versioni Git. Fondata nel 2008, è rapidamente diventata uno degli strumenti chiave per gli sviluppatori in tutto il mondo.
GitHub permette 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 GitHub è una parte importante del portfolio da mostrare ai potenziali datori di lavoro.
6. Creare il tuo primo repository su GitHub
Passo 1. Vai su https://github.com e registrati.
Passo 2. Clicca sul pulsante New repository per creare un nuovo repository.
Passo 3. Imposta i parametri del repository:
- Nome del repository: scegli un nome significativo.
- Pubblico o privato: per progetti didattici è meglio scegliere "Public", così gli altri possono vederlo.
- Add a README file: assicurati di spuntare questa casella. README è la "faccia" del tuo progetto.
- Add .gitignore: apri il menu a tendina e scegli il template per il tuo linguaggio.
- Choose a license: puoi saltarlo.
- Clicca
Create repository.
Passo 4. Congratulazioni, il tuo primo repository remoto è stato creato!
7. Installazione e configurazione di Git
Anche se le basi di Git si possono imparare tramite i comandi in console (come mostrato nel video), nel lavoro quotidiano il 99% degli sviluppatori usa gli strumenti integrati nell'IDE. Il nostro obiettivo è insegnarti a lavorare come fanno i professionisti.
L'interfaccia per lavorare con Git in tutte le IDE moderne di JetBrains — sia che si tratti di IntelliJ IDEA per Java/Kotlin, Rider per C# o PyCharm per Python — è praticamente identica. Questo significa che imparando a usare Git in un ambiente potrai applicare le stesse competenze facilmente in un altro. Perciò useremo IntelliJ IDEA come esempio universale. Tutto ciò che vedrai qui avrà lo stesso aspetto e funzionerà allo stesso modo nella tua IDE preferita.
Per lavorare con Git sul tuo computer, devi prima installarlo. Se usi IntelliJ IDEA, molto probabilmente ti proporrà di installare Git automaticamente se non viene trovato nel sistema. Ti consigliamo di accettare questa proposta — è la via più semplice.
Chiudi il progetto corrente scegliendo File > Close Project, e clicca su Clone Repository.
Se invece vuoi installarlo manualmente, usa 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 principali piattaforme, incluso GitHub, sono passate a un termine più neutro — main.
È importante saperlo, perché in alcuni articoli o progetti vecchi potresti ancora trovare il riferimento a master. Nelle nostre lezioni e nei progetti moderni il branch principale sarà sempre main.
Per saperne di più sulla transizione a main puoi consultare i seguenti link:
GO TO FULL VERSION