Chi lavora ogni giorno con Git conosce bene la “danza dello stash”: arriva una richiesta urgente — un hotfix in produzione, una revisione da completare al volo — mentre si è nel mezzo di una feature con decine di file modificati e non ancora pronti per un commit. Le opzioni classiche sono due, ed entrambe scomode: fare git stash e sperare di non perdere il contesto mentale, oppure clonare di nuovo l’intero repository in un’altra cartella, con il relativo spreco di spazio su disco e di tempo per il restore dei pacchetti.

Da qualche mese Visual Studio 2026 offre una soluzione nativa a questo problema, portando in interfaccia grafica una funzionalità di Git che esiste da anni a riga di comando ma che pochi sviluppatori .NET usano davvero: i worktree. Con gli aggiornamenti successivi, inoltre, l’intera esperienza Git dell’IDE si è arricchita di strumenti che vale la pena conoscere: dai submodule alla risoluzione massiva dei conflitti di merge.

Cos’è un git worktree

Un worktree è, in sostanza, una seconda directory di lavoro collegata allo stesso repository Git. Non è un clone: la cronologia, gli oggetti e le configurazioni restano condivisi con il repository principale, ma ogni worktree ha il proprio branch attivo e la propria copia dei file sul disco. Si possono quindi avere due (o più) branch “aperti” contemporaneamente, ognuno nella sua cartella, senza duplicare il repository e senza dover fare stash di nulla.

Da riga di comando, la funzionalità esiste dalla versione 2.5 di Git (2015) ed è semplice da usare:

# crea un worktree per il branch hotfix/123 in una cartella dedicata
git worktree add ../progetto-hotfix hotfix/123

# elenca tutti i worktree collegati al repository
git worktree list

# rimuove un worktree non più necessario
git worktree remove ../progetto-hotfix

Fino a poco tempo fa, però, questa funzionalità era riservata a chi si sentiva a proprio agio con la riga di comando. Visual Studio 2026 (a partire dalla versione 18.9, rilasciata ad agosto 2026) l’ha integrata direttamente nella finestra Git Repository.

Worktree nell’interfaccia di Visual Studio 2026

Il flusso di lavoro è pensato per essere immediato:

1. Nella finestra Git Repository, clic destro su un branch e selezione di New Worktree From.
2. Si può creare il worktree da un branch nuovo, da un branch esistente o da un commit specifico selezionato nel grafico della cronologia.
3. Il worktree si può aprire nella finestra corrente di Visual Studio oppure in una nuova istanza, per avere entrambi i branch visibili side-by-side sullo schermo.
4. I worktree compaiono insieme ai branch nella finestra Git Repository, nel branch picker e nel repository picker, così resta sempre chiaro quale working directory corrisponde a quale branch.
5. Per liberare lo spazio, clic destro sul worktree e selezione di Delete Worktree.

Il caso d’uso più tipico per un team di sviluppo .NET è esattamente quello descritto in apertura: si sta lavorando su una feature con build e test ancora instabili, arriva una segnalazione critica da sistemare subito. Invece di fare stash o clonare da zero (con conseguente dotnet restore e ricompilazione completa), si crea un worktree dal branch di produzione, si apre in una nuova finestra di Visual Studio, si risolve il bug, si fa il commit e il push, e si torna alla finestra originale esattamente nello stato in cui era stata lasciata.

Le altre novità Git arrivate nei mesi successivi

La versione 18.9 non si è fermata ai worktree. Nello stesso rilascio è arrivato anche il primo supporto nativo ai submodule: una sezione dedicata nella finestra Git Repository permette di aggiungere, aggiornare e rimuovere submodule, che per impostazione predefinita sono di sola lettura. Per renderli modificabili occorre andare in Tools > Options > Source Control > Git e impostare Automatically activate multiple repositories su Yes, include submodules.

Nei rilasci seguenti (versioni 18.10 e 18.11, tra settembre e ottobre 2026) si sono aggiunti altri strumenti utili nella gestione quotidiana del codice:

• Confronto file e commit con il working tree: clic destro su un commit nella cronologia di un file e selezione di Compare with Working Tree, utile per capire rapidamente cosa è cambiato rispetto a una versione passata senza dover fare checkout.
• Diff multi-file riassuntivo: una vista unificata che mostra le righe modificate in più file contemporaneamente, comoda per revisionare pull request estese senza aprire ogni file singolarmente.
• Risoluzione massiva dei conflitti di merge: clic destro su un file, una cartella o la radice del repository nella sezione Unmerged Changes e scelta di Keep All Current oppure Take All Incoming, per chiudere in un colpo i conflitti su interi set di file generati, ad esempio, da rigenerazioni automatiche di codice.
• Autocomplete e timeline delle pull request direttamente nella tab Overview, per seguire lo stato di una PR senza uscire dall’IDE.

Perché interessa a sistemisti e team DevOps

Oltre al vantaggio ovvio per chi scrive codice, i worktree sono utili anche in scenari di infrastruttura e automazione. Un sistemista che gestisce pipeline CI/CD locali per debug, o che deve testare uno script di provisioning su più branch di configurazione (ad esempio main e staging) senza interferire con l’ambiente di lavoro principale, può sfruttare lo stesso meccanismo per tenere aperte più versioni del repository di infrastructure-as-code in parallelo, con un consumo di disco molto inferiore rispetto a clonare l’intero repository più volte.

Vale anche la pena ricordare che, nello stesso periodo, Visual Studio ha esteso il supporto al debug dei container anche a Podman (oltre a Docker): da Debug > Attach to Process, impostando il Connection type su Podman, l’IDE individua automaticamente i container in esecuzione e permette di collegare il debugger sia per applicazioni .NET che C++, senza configurazione aggiuntiva — una notizia che interessa direttamente chi, per motivi di sicurezza o di policy aziendale, ha scelto Podman come runtime di container al posto di Docker.

Conclusione

I worktree non sono una funzionalità nuova di Git, ma la loro integrazione in Visual Studio 2026 le rende finalmente accessibili a tutta la base di sviluppatori .NET che finora le ignorava, semplicemente perché non volevano uscire dall’IDE per usarle. Insieme ai submodule, al diff multi-file e alla risoluzione massiva dei conflitti, compongono un pacchetto di miglioramenti che, aggiornamento dopo aggiornamento, rendono la gestione di repository complessi molto più fluida. Chi usa Visual Studio 2026 e non ha ancora aggiornato alle ultime versioni (18.9 o successive) farebbe bene a farlo solo per queste funzionalità.

Fonte: Visual Studio Blog – Visual Studio August update: Work smarter across models and branches, Visual Studio Blog – Keep your investigation between sessions e note di rilascio ufficiali Visual Studio 2026.