Gestione del Codice Sorgente

La gestione del codice sorgente (SCM) è la disciplina che consiste nel tracciare, registrare e coordinare ogni modifica apportata al codice sorgente di un progetto nel tempo. Questa pagina spiega cos'è l'SCM, perché ogni team ne dipende, come Git si inserisce in questo contesto, il flusso di lavoro che abilita e le pratiche che mantengono pulita la cronologia di un progetto.

Cos'è la Gestione del Codice Sorgente?

La gestione del codice sorgente è la pratica di tracciare e gestire le modifiche al codice software. Viene quasi sempre implementata con un sistema di controllo versione (VCS) — uno strumento che registra ogni modifica a un repository, la attribuisce a un autore, la marca con un timestamp e permette di spostarsi avanti e indietro nella cronologia del progetto.

Git è il VCS più diffuso oggi. È distribuito, il che significa che ogni sviluppatore conserva una copia completa della cronologia del progetto in locale, così è possibile fare commit, creare branch e consultare la cronologia senza una connessione di rete. Esistono altri sistemi (Subversion, Mercurial, Perforce), ma i concetti di questa pagina si applicano a tutti.

SCM e VCS vengono spesso usati in modo intercambiabile. In senso stretto, SCM è la pratica più ampia (cronologia, branching, politiche di collaborazione, code review), mentre un VCS come Git è lo strumento che la implementa.

Se sei alle prime armi con Git, inizia con l'introduzione a Git e impara a creare il tuo primo repository Git.

Perché la Gestione del Codice Sorgente è Importante

Un VCS risolve problemi che diventano fastidiosi nel momento in cui più di una persona — o più di un giorno di lavoro — tocca una codebase:

• Tracciare le modifiche – Ogni modifica viene registrata automaticamente, attribuita a un autore e documentata con un messaggio di commit, creando un registro storico ricercabile.
• Sincronizzazione – I membri del team recuperano l'ultimo codice da un repository condiviso, così tutti lavorano dalla stessa base di partenza.
• Backup e ripristino – Poiché ogni commit è uno snapshot completo, qualsiasi file può essere ripristinato a uno stato precedente in qualsiasi momento.
• Annullamento delle modifiche – Puoi tornare a qualsiasi stato precedente, dal commit più recente a una versione creata molto tempo fa, senza perdere i passaggi intermedi.
• Branching e merging – Il lavoro avviene su branch isolati e viene unito di nuovo al ramo principale una volta revisionato e approvato.
• Rilevamento dei conflitti – Quando due persone modificano le stesse righe, il VCS si rifiuta di sovrascrivere silenziosamente l'una con l'altra; segnala un conflitto di merge affinché un essere umano possa risolverlo.

Senza SCM, i team ricorrono a comprimere cartelle, inviare file per email e nominare le cose final_v2_REALLY_final.js — perdendo la cronologia e sovrascrivendo il lavoro altrui.

Il Flusso di Lavoro SCM di Base

La maggior parte del lavoro quotidiano in Git segue lo stesso ciclo: modificare i file, metterli in staging, fare un commit dello snapshot e consultare la cronologia. L'esempio seguente esegue un repository autonomo per vedere il ciclo dall'inizio alla fine.

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

La cronologia contiene ora due snapshot, dal più recente al meno recente (gli hash brevi a sinistra vengono generati per ogni commit, quindi i tuoi saranno diversi):

6524bb9 Print world too
88e2f34 Add initial app

Ogni git add sposta le modifiche nell'area di staging, e ogni git commit congela il contenuto in staging in uno snapshot permanente e con un nome. L'output di git log è il registro storico che l'SCM ti fornisce — due righe qui, una per commit, ciascuna con un hash breve e un messaggio. In qualsiasi momento puoi eseguire git status per vedere cosa è stato modificato, messo in staging o non tracciato.

Branching e Merging

La funzionalità che rende l'SCM potente per i team è l'isolamento tramite i branch. Ogni sviluppatore (o ogni funzionalità) ottiene una linea di sviluppo separata; quando il lavoro è revisionato e pronto, viene unito al branch principale.

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

Dopo il merge, notes.txt contiene il lavoro di entrambi i branch:

line 1
line 2 from feature

Il branch feature ha permesso alla nuova linea di lavoro di procedere senza toccare main, e git merge l'ha ricombinata. In un progetto condiviso si eseguirebbe anche git clone del repository e git pull prima di iniziare, in modo da lavorare sul codice più aggiornato.

Best Practice

• Fai commit frequentemente, in unità piccole. Un commit è uno snapshot; commit piccoli e mirati ti offrono molti punti sicuri a cui tornare e rendono la cronologia facile da leggere. I commit correlati possono in seguito essere combinati per mantenere il log pulito.
• Lavora sempre dalla versione più recente. Esegui un pull o un fetch del codice condiviso prima di iniziare, così costruisci sul lavoro corrente e riduci al minimo i conflitti di merge.
• Scrivi messaggi di commit descrittivi. Un messaggio chiaro che spiega cosa è cambiato e perché diventa essenziale man mano che un progetto cresce e altre persone (incluso il te del futuro) leggono il log.
• Revisiona prima di fare il commit. L'area di staging ti permette di raccogliere e ispezionare le modifiche prima di trasformarle in uno snapshot — rivedi il diff affinché ogni commit sia intenzionale.
• Usa i branch per l'isolamento. Sviluppa ogni funzionalità o correzione sul proprio branch e uniscila solo dopo la revisione, mantenendo stabile il branch principale.
• Concordate un flusso di lavoro condiviso. Stabilite convenzioni di team per il branching, la revisione e il merging. I pattern più comuni sono trattati in Git workflows.

Pratica