🎥 Git, GitHub e VSCode: guida completa per iniziare
Link al video sul canale: https://youtu.be/nla2TDAtySY
Git, GitHub e VSCode: il trio che uso ogni giorno
Anche se non sono uno sviluppatore di professione, Git è uno strumento che uso costantemente: dagli script di automazione dei miei bot Telegram, alle configurazioni Kubernetes, fino ai file di infrastruttura che gestisco per lavoro. Tenere traccia delle modifiche nel tempo non è un lusso da programmatori — è quello che mi ha salvato più volte da errori di configurazione che altrimenti sarebbero stati difficili da tracciare.
Git vs GitHub: la distinzione che confonde sempre i principianti
Git è lo strumento di version control che gira in locale sul tuo computer: tiene traccia di ogni modifica ai file del progetto, ti permette di tornare indietro se qualcosa va storto, e gestisce i “rami” (branch) per lavorare su funzionalità diverse senza toccare la versione principale.
GitHub è invece il servizio online che ospita i tuoi repository nel cloud — la differenza è la stessa che c’è tra un programma sul tuo PC e un servizio a cui ti colleghi da internet. Puoi usare Git senza GitHub (lavorando solo in locale), ma GitHub diventa indispensabile appena vuoi collaborare con altri o avere un backup remoto del tuo lavoro.
Perché uso VSCode invece del solo terminale
Conosco bene la riga di comando, ma per il lavoro quotidiano con Git preferisco VSCode: la sezione Source Control integrata mi mostra a colpo d’occhio cosa è cambiato, mi permette di fare staging selettivo dei file (utile quando ho modificato più cose ma voglio fare commit separati e puliti), e con estensioni come GitLens vedo subito chi ha modificato una riga e quando — utile soprattutto quando riprendo in mano uno script scritto mesi prima e non ricordo perché avevo fatto una certa scelta.
Il consiglio che do sempre a chi inizia
L’errore più comune che vedo è scrivere messaggi di commit inutili tipo “fix” o “update” — sembra un dettaglio ma quando devi ricostruire la cronologia di un progetto dopo mesi, un commit ben descritto ti fa risparmiare tempo prezioso. La mia regola: il messaggio deve spiegare perché hai fatto una modifica, non solo cosa hai cambiato (quello lo vede già il diff).
Altro consiglio pratico: crea sempre un branch separato per ogni nuova funzionalità o fix, anche nei progetti personali dove lavori da solo. Ti abitua a un flusso di lavoro pulito, e se qualcosa va storto puoi abbandonare il branch senza aver toccato la versione funzionante.
👉 Nel video qui sopra trovi tutto questo mostrato in pratica, dal primo commit al push su GitHub.