Vai al contenuto principale

Le 25 migliori domande e risposte sui colloqui Git per tutti i livelli

Ripassa i comandi, i concetti e i confronti di Git che compaiono più spesso nei colloqui tecnici
Aggiornato 2 giu 2026  · 13 min leggi

Git è uno strumento essenziale nel kit di un moderno sviluppatore, noto per le sue potenti funzionalità di controllo versione. Creato da Linus Torvalds nel 2005 per supportare lo sviluppo del kernel Linux, Git è diventato la spina dorsale di innumerevoli progetti software in tutto il mondo. La sua efficienza e flessibilità nella gestione delle versioni dei progetti, unite a un solido supporto per la collaborazione, lo rendono indispensabile per team di ogni dimensione.

Questo articolo ha lo scopo di prepararti ai colloqui tecnici trattando le 20 principali domande sui colloqui Git, che spaziano dal livello principiante a quello avanzato. Che tu sia nuovo a Git o voglia approfondire la tua comprensione, queste domande e risposte ti aiuteranno a dimostrare la tua competenza e a superare il colloquio.

Domande di base su Git

Se sei relativamente alle prime armi con Git, è probabile che alcune domande di base del colloquio riguardino concetti e utilizzi per principianti. Se hai bisogno di ripassare, dai un'occhiata al corso Introduction to Git di DataCamp.

Che cos'è un repository Git?

Un repository Git conserva i file di un progetto e la cronologia delle revisioni e facilita il controllo versione tracciando le modifiche apportate nel tempo. Può trovarsi in locale all'interno di una cartella sul tuo dispositivo o su una piattaforma online come GitHub. Questo permette agli utenti di collaborare, tornare a versioni precedenti e gestire in modo efficiente lo sviluppo del progetto usando comandi come commit, push e pull.

Come funziona Git?

Git opera registrando le modifiche apportate a file e directory in un progetto, catturando istantanee del suo stato in evoluzione. Gli utenti possono gestire le modifiche, creare branch per sviluppi in parallelo, effettuare merge tra branch e tornare a stati precedenti se necessario. Favorisce inoltre la collaborazione e garantisce un controllo versione efficace nei progetti software.

Che cos'è git add?

Il comando git add in Git viene usato per mettere in stage le modifiche da includere nel commit successivo. Prepara modifiche, aggiunte o eliminazioni apportate ai file nella working directory, contrassegnandole per l'inclusione nella prossima istantanea di commit. Nota che questo comando non effettua il commit delle modifiche, ma le prepara per lo staging.

Che cos'è git push?

Il comando git push in Git viene utilizzato per caricare il contenuto del repository locale su un repository remoto. Trasferisce le modifiche già committate dal repository locale a uno remoto, tipicamente su un server come GitHub o GitLab. Questo comando abilita la collaborazione permettendo agli utenti di condividere le proprie modifiche con altri che lavorano allo stesso progetto.

Puoi approfondire git push e pull nella nostra guida dedicata.

Che cos'è git status?

Il comando git status mostra lo stato corrente del repository in Git. Fornisce informazioni su quali file sono stati modificati, quali sono in stage per il prossimo commit e quali non sono tracciati. Aiuta gli utenti a monitorare l'avanzamento del lavoro e a identificare eventuali modifiche da committare o da mettere in stage.

Che cos'è un commit in Git?

Un commit rappresenta un'istantanea delle modifiche apportate ai file in un repository in un determinato momento. Quando effettui un commit in Git, salvi di fatto lo stato attuale dei tuoi file e puoi fornire un messaggio descrittivo che spieghi le modifiche effettuate (cosa consigliata).

Ogni commit crea un identificatore univoco, permettendoti di tracciare la cronologia delle modifiche nel repository. I commit svolgono un ruolo cruciale nel controllo versione, perché consentono di tornare a stati precedenti del progetto, rivedere la cronologia delle modifiche e collaborare con altri condividendo gli aggiornamenti.

Git cheat sheet

Dai un'occhiata alla Git Cheat Sheet di DataCamp per prepararti al colloquio

Che cos'è il branching in Git?

Il branching indica la pratica di deviare dalla linea principale di sviluppo (tipicamente chiamata main e in passato master) per lavorare su nuove funzionalità, correzioni o esperimenti senza influenzare la codebase principale. Consente a più linee di sviluppo parallele di coesistere nello stesso repository.

Ogni branch rappresenta una linea di sviluppo separata con il proprio set di commit, consentendo agli sviluppatori di lavorare contemporaneamente su funzionalità o fix differenti. Il branching facilita collaborazione, sperimentazione e organizzazione all'interno di un progetto, poiché le modifiche apportate in un branch possono essere fuse nella codebase principale una volta completate e testate.

Che cos'è un conflitto in Git?

I conflitti si verificano quando vengono apportate modifiche in contrasto alla stessa parte di un file (o di più file) da parte di diversi contributori, in genere durante un'operazione di merge o rebase. Git non può risolvere automaticamente queste discrepanze, richiedendo un intervento manuale dell'utente per risolverle.

Per risolvere un conflitto, apri il file interessato — Git contrassegnerà le sezioni in conflitto con i marcatori <<<<<<<, ======= e >>>>>>>. Modifica il file mantenendo la versione corretta, rimuovi i marcatori, quindi:

git add <resolved-file>
git commit
Strumenti come VS Code, IntelliJ e git mergetool possono rendere questo processo visivo e più semplice da gestire.

Che cos'è il merge in Git?

Il merge è un'operazione fondamentale in Git che facilita la collaborazione e l'integrazione delle modifiche tra branch diversi di un progetto. In pratica, un merge è il processo di combinazione delle modifiche di branch diversi in un unico branch, tipicamente quello principale (ad esempio, master o main).

Un merge integra le modifiche apportate in un branch con un altro, producendo un nuovo commit che combina le storie di entrambi i branch. Puoi saperne di più su come risolvere i conflitti di merge in Git nella nostra guida dedicata.

Domande intermedie su Git

Che cos'è un remote in Git?

Un remote è un repository ospitato su un server o su un altro computer per collaborare e condividere codice con altri. Funziona come una posizione centralizzata dove gli sviluppatori possono effettuare push delle modifiche locali e fare pull delle modifiche apportate da altri.

I remote sono in genere configurati su piattaforme di hosting come GitHub, GitLab o Bitbucket e abilitano lo sviluppo distribuito, facilitando il lavoro di squadra fornendo una posizione comune in cui memorizzare e sincronizzare il codice del progetto tra più contributori.

Come si fa a revertare un commit già pushato e reso pubblico?

Il comando git revert <commit-hash> può essere utilizzato per revertare un commit che è già stato pushato e reso pubblico.

Il processo passo passo è il seguente:

1. Identifica il commit a cui vuoi tornare trovandone l'hash. Puoi farlo usando il comando git log per visualizzare la cronologia dei commit e trovare l'hash del commit da revertare.

2. Una volta ottenuto l'hash, usa il comando git revert seguito dall'hash per creare un nuovo commit che annulla le modifiche introdotte dal commit specificato. Per esempio:

git revert <commit-hash>

3. Git aprirà un editor di testo per creare il messaggio di commit del revert. Puoi modificarlo se necessario, quindi salva e chiudi l'editor.

4. Dopo aver salvato il messaggio, Git creerà un nuovo commit che annulla di fatto le modifiche introdotte dal commit specificato. Questo nuovo commit verrà aggiunto alla cronologia, revertando le modifiche del commit originale.

5. Infine, effettua il push del nuovo commit sul repository remoto per rendere pubblico il revert usando il seguente comando:

git push origin <branch-name> 

Usare git revert crea un nuovo commit che annulla le modifiche introdotte dal commit originale, revertando le modifiche senza alterare la cronologia. Questo approccio è più sicuro di git reset o git amend, che possono modificare la cronologia e causare problemi ai collaboratori che hanno già fatto pull delle modifiche.

Che cos'è git stash?

git stash è un comando Git che memorizza temporaneamente le modifiche nella working directory che non sono pronte per essere committate. Consente agli sviluppatori di salvare le proprie modifiche senza committarle nel repository.

Lo stash è utile quando cambi branch ma non vuoi committare o perdere le modifiche. In seguito, puoi applicare le modifiche accantonate alla working directory o rimuoverle dallo stack dello stash per continuare a lavorarci.

Che cos'è git reflog?

git reflog è un comando Git utilizzato per visualizzare i log dei riferimenti, che registrano i cambiamenti del puntatore HEAD e la cronologia dei commit che sono stati checkouttati nel repository. Fornisce un elenco cronologico delle azioni recenti eseguite nel repository, inclusi commit, checkout, merge e reset.

Il reflog è utile per recuperare commit o branch persi e per comprendere la sequenza delle azioni intraprese nel repository.

Come fai a far tracciare a un branch Git esistente un branch remoto?

Per far tracciare a un branch Git esistente un branch remoto, puoi usare il comando git branch con l'opzione --set-upstream-to o -u, seguito dal nome del branch remoto.

La sintassi è la seguente:

git branch --set-upstream-to=<remote-name>/<branch-name>

oppure

git branch -u <remote-name>/<branch-name>

Domande avanzate su Git

Come gestisci configurazioni multiple per progetti diversi in Git?

Per gestire varie configurazioni, utilizza il comando git config insieme ai flag --global, --system o --local per modificare le impostazioni a livelli distinti. In alternativa, usa includeIf nella configurazione Git per includere setup specifici in base al percorso del repository.

Come gestisci i file di grandi dimensioni con Git?

Gestire file di grandi dimensioni con Git può essere impegnativo a causa dell'impatto sulle dimensioni del repository e sulle prestazioni. Usa Git LFS per archiviare i file grandi al di fuori del repository Git, mantenendo nel repository solo puntatori leggeri. Questo riduce la dimensione del repository e migliora le prestazioni. Git LFS supporta vari provider di storage e si integra perfettamente con i workflow Git.

A cosa serve git submodule e come si aggiorna?

Il comando git submodule gestisce le dipendenze esterne all'interno di un repository Git. Ti consente di includere repository esterni come sottomoduli all'interno del tuo repository principale. È utile quando vuoi incorporare codice da sorgenti esterne mantenendolo separato dalla codebase del progetto principale.

Per aggiornare un sottomodulo in Git, puoi seguire questi passaggi:

  1. Vai nella directory del sottomodulo all'interno del tuo repository principale.

  2. Usa git fetch per recuperare le ultime modifiche dal repository remoto del sottomodulo.

  3. Se vuoi aggiornare all'ultimo commit del branch tracciato dal sottomodulo, puoi usare git pull.

  4. In alternativa, se vuoi aggiornare a un commit o a un branch specifico, puoi usare git checkout seguito dall'hash desiderato o dal nome del branch.

  5. Una volta aggiornato il sottomodulo allo stato desiderato, devi committare le modifiche nel repository principale per riflettere lo stato aggiornato del sottomodulo.

Che cos'è git cherry-pick e quando lo useresti?

git cherry-pick ti permette di applicare uno specifico commit da un branch a un altro, senza fare il merge dell'intero branch.

git cherry-pick <commit-hash>
 
Un caso d'uso comune è il backport di una correzione di bug. Supponiamo che un bug sia stato corretto sul branch main ma che tu abbia bisogno della stessa correzione anche su un branch release — puoi cherry-pickare solo quel commit invece di fare il merge di tutto main in release.

È utile anche quando un commit è stato fatto per errore sul branch sbagliato: esegui il cherry-pick sul branch corretto, quindi revertalo da dove non dovrebbe essere.

Che cos'è git bisect e a cosa serve?

git bisect è uno strumento di debugging che usa la ricerca binaria per trovare il commit specifico che ha introdotto un bug. Invece di fare checkout manualmente dei commit uno a uno, indichi a Git quale commit è "buono" (senza bug) e quale è "cattivo" (contiene il bug), e Git farà il checkout dei commit intermedi, dimezzando ogni volta lo spazio di ricerca finché non trova il colpevole.

git bisect start
git bisect bad                # il commit corrente contiene il bug
git bisect good <commit-hash> # questo commit più vecchio era ok
# Git fa il checkout di un commit intermedio; lo testi, poi:
git bisect good   # oppure git bisect bad
# ripeti finché Git non identifica il primo commit difettoso
git bisect reset  # torna allo stato originale quando hai finito

È molto più veloce della ricerca manuale in repository grandi con centinaia di commit.

Cosa sono gli hook di Git e come si usano?

Gli hook di Git sono script che vengono eseguiti automaticamente in punti specifici del workflow Git. Si trovano nella directory .git/hooks/ di un repository e possono essere scritti in qualsiasi linguaggio di scripting.

Ne esistono di due tipi:

  • Hook lato client eseguiti sulla tua macchina locale — ad esempio, pre-commit (viene eseguito prima della creazione del commit) o commit-msg (valida il formato del messaggio di commit).

  • Hook lato server eseguiti sul server remoto — ad esempio, pre-receive (viene eseguito prima che i commit pushati vengano accettati).

Un caso d'uso comune è usare un hook pre-commit per eseguire automaticamente un linter o una suite di test prima di consentire un commit. Questo impone standard di qualità del codice in tutto il team.

Nota che gli hook non vengono copiati quando cloni un repository, perciò i team che vi fanno affidamento in genere li condividono tramite uno script separato o uno strumento come pre-commit (il pacchetto Python).

Domande su concetti Git spesso confusi

Qual è la differenza tra git fetch e git pull?

La principale differenza tra git fetch e git pull sta in ciò che fanno e in come aggiornano il repository locale.

Il comando git fetch recupera le modifiche da un repository remoto a quello locale. Aggiorna i branch di tracking remoto (ad esempio, origin/master) nel repository locale per riflettere lo stato del repository remoto, ma non aggiorna la working directory né effettua merge nel branch corrente. Questo significa che dopo il fetch puoi rivedere le modifiche presenti nel remoto senza influenzare il tuo lavoro locale.

Il comando git pull recupera anch'esso le modifiche da un repository remoto, ma fa un passo in più: effettua il fetch e fa il merge nel branch corrente in un'unica operazione. In sostanza esegue un git fetch seguito da un git merge per incorporare le modifiche del repository remoto nel branch corrente.

Cosa fa git reset?

Il comando git reset reimposta l'HEAD corrente a uno stato specificato. Ciò significa che può essere usato per annullare modifiche, rimuovere file dallo staging o spostare il puntatore HEAD a un commit diverso. Nota, esistono tre modalità principali di git reset:

  • --soft: Reimposta il puntatore HEAD a un commit specifico, mantenendo le modifiche in stage. I file restano modificati nella working directory, consentendoti di ri-committarli.
  • --mixed: Reimposta il puntatore HEAD a un commit specifico, rimuovendo le modifiche dallo staging. I file restano modificati nella working directory, ma le modifiche non sono in stage per il commit.
  • --hard: Reimposta il puntatore HEAD a un commit specifico, scartando tutte le modifiche nella working directory e nell'area di staging. Usare con cautela, perché elimina definitivamente le modifiche non committate.

Importante: Non usare mai git reset --hard su commit che sono già stati pushati su un branch remoto condiviso. Riscrive la cronologia e causerà seri problemi ai colleghi che hanno già fatto pull di quei commit. Per i commit pubblici usa invece git revert.

Qual è il significato di git push --force-with-lease rispetto a git push --force?

Il comando git push --force-with-lease è un approccio più cauto al force-push di modifiche verso un repository remoto rispetto a git push --force, perché impedisce di sovrascrivere accidentalmente modifiche apportate da altri sul repository remoto.

Quando usi git push --force, forzi il push delle tue modifiche sul repository remoto indipendentemente dal fatto che altri lo abbiano aggiornato dopo il tuo ultimo fetch. Questo può portare alla perdita involontaria del lavoro di altri sviluppatori.

Al contrario, git push --force-with-lease è un'alternativa più sicura. Verifica se il branch remoto su cui stai pushando è stato aggiornato da altri dopo il tuo ultimo fetch. Se il branch remoto è stato aggiornato, il push viene rifiutato, evitando di sovrascrivere involontariamente le modifiche altrui.

Che cos'è git rebase e in cosa differisce da git merge?

Sia git rebase sia git merge integrano modifiche da un branch a un altro, ma lo fanno in modo diverso.

  • git merge combina le storie di due branch creando un nuovo "merge commit". Questo preserva l'intera cronologia di quando i branch sono divergi e poi si sono riuniti, utile per audit trail e trasparenza nel team.

  • git rebase sposta o riproduce i commit da un branch sopra un altro, producendo una cronologia lineare e pulita senza merge commit. Rende il log più facile da leggere, ma riscrive la cronologia dei commit. Per questo la regola d'oro del rebase è: non fare mai rebase di un branch su cui stanno lavorando anche altri.

Qual è la differenza tra git clone e git fork?

Clonare crea una copia locale di un repository remoto sulla tua macchina. Sei ancora collegato allo stesso repository e puoi effettuare push delle modifiche (se hai i permessi).

git clone https://github.com/user/repo.git
Forkare crea una copia lato server del repository di qualcun altro sotto il tuo account — in genere su GitHub o GitLab. Il fork è tuo e puoi farci push liberamente. Quando le tue modifiche sono pronte, invii una pull request al repository originale.

Il fork è il workflow standard per contribuire a progetti open source nei quali non hai accesso in scrittura diretto al repository originale.

Prepararsi a un colloquio su Git

Presentare la tua conoscenza ed esperienza con Git durante i colloqui è fondamentale per mostrare la tua padronanza del controllo versione e della collaborazione all'interno dei team di sviluppo software.

Vediamo alcuni consigli da seguire quando ti prepari al colloquio tecnico per comunicare efficacemente le tue competenze su Git:

Comprendi i fondamenti di Git

Assicurati di avere una solida comprensione dei fondamenti di Git, inclusi repository, branching, merge, commit e comandi di base come pull, push, clone e commit. Queste basi costituiranno il filo conduttore della tua discussione durante il colloquio. Aiuta anche comprendere a fondo principi essenziali come il controllo versione, distinguendo le differenze tra Git e altri sistemi di versionamento.

Infine, familiarizza con metodologie Git diverse, come Git Flow, GitHub Flow e GitLab Flow. Valuta i vantaggi e gli svantaggi di ciascun approccio e riconosci le situazioni in cui sono più utili.

La nostra guida completa a Git è un ottimo punto di partenza per familiarizzare con i fondamenti.

Fai esperienza pratica

Più usi Git, più rafforzi le tue conoscenze. La pratica regolare aumenta la familiarità con vari comandi e procedure. Cerca di integrare Git nel tuo flusso di lavoro quotidiano per fare esperienza. Ricordati di sperimentare la creazione di branch, il loro merge e la risoluzione dei conflitti.

Se non sai su quali progetti lavorare per fare esperienza pratica con Git, partecipare a progetti open source tramite piattaforme come GitHub è un ottimo modo per fare esperienza diretta con strumenti e workflow di collaborazione standard del settore.

Impara i problemi comuni e come risolverli

È inevitabile incontrare problemi usando Git. Alcuni problemi comuni includono conflitti di merge, stati di HEAD staccato, revert di modifiche e recupero di commit persi. Diagnosticare i problemi in Git migliora le capacità di troubleshooting e favorisce una comprensione più profonda dei meccanismi interni di Git.

Affrontando attivamente la ricerca guasti e analizzando i messaggi di errore, acquisirai informazioni sul funzionamento interno di Git e svilupperai la capacità di identificare e risolvere i problemi con efficienza. Questo approccio proattivo riduce i rischi potenziali e costruisce in modo efficace fiducia ed esperienza nella gestione dei workflow di controllo versione.

Esercitati con colloqui simulati

Partecipando a colloqui simulati, i candidati possono individuare aree di debolezza nelle conoscenze di Git e nelle capacità comunicative, consentendo di concentrare la preparazione in modo efficace.

Inoltre, i colloqui simulati offrono preziose opportunità per affinare le capacità di problem solving affrontando scenari realistici legati a Git ed esercizi di coding. Questa pratica pratica aiuta a sviluppare fiducia nelle proprie competenze su Git e migliora la capacità di articolare chiaramente i propri pensieri durante il colloquio.

Conclusione

Git è un potente sistema di controllo versione ampiamente utilizzato nello sviluppo software per gestire le modifiche al codice, collaborare con gli altri e mantenere la cronologia dei progetti. La familiarità con Git è essenziale nei colloqui tecnici, perché dimostra padronanza di strumenti e workflow fondamentali per gli sviluppatori, evidenzia le competenze collaborative e la capacità di gestire efficacemente il codice in contesti di team.

Inoltre, comprendere concetti e comandi di Git consente pratiche di controllo versione efficienti, garantendo l'integrità del codice, la continuità del progetto e processi di sviluppo più snelli. Pertanto, la conoscenza di Git è inestimabile per aspiranti software engineer e sviluppatori che affrontano colloqui tecnici e perseguono carriere di successo.

Per approfondire, consulta le seguenti risorse:


Kurtis Pykes 's photo
Author
Kurtis Pykes
LinkedIn
Argomenti

Continua oggi il tuo percorso con Git!

Programma

Ingegnere dei dati in Python

40 h
Acquisisci le competenze più richieste per ingerire, pulire e gestire i dati in modo efficiente e per programmare e monitorare le pipeline, distinguendoti nel campo dell'ingegneria dei dati.
Vedi dettagliRight Arrow
Inizia il corso
Mostra altroRight Arrow
Correlato

blog

I 15 migliori server MCP remoti che ogni AI builder dovrebbe conoscere nel 2026

Scopri i 15 migliori server MCP remoti che stanno trasformando lo sviluppo AI nel 2026. Scopri come migliorano automazione, ragionamento, sicurezza e velocità dei workflow.
Abid Ali Awan's photo

Abid Ali Awan

15 min

blog

Che cos'è Snowflake? Guida per principianti alla piattaforma dati cloud

Esplora le basi di Snowflake, la piattaforma dati cloud. Scopri la sua architettura, le sue funzionalità e come integrarla nelle tue pipeline di dati.
Tim Lu's photo

Tim Lu

12 min

blog

Tokenizzazione nel NLP: come funziona, sfide e casi d'uso

Guida al preprocessing NLP nel machine learning. Copriamo spaCy, i transformer di Hugging Face e come funziona la tokenizzazione in casi d'uso reali.
Abid Ali Awan's photo

Abid Ali Awan

10 min

Mostra altroMostra altro