Git è nato in un’epoca in cui il modello mentale era semplice: un developer, un task, un branch. Oggi, tra AI agent che generano codice in parallelo, review continue, hotfix improvvisi e contesti multipli sovrapposti, quella linearità è diventata un collo di bottiglia.
Se lavori su una codebase di dimensioni non banali, il copione è ormai automatico. Sei nel mezzo di una feature, hai file modificati ovunque, arriva una segnalazione urgente su main. A quel punto esegui git stash, fai checkout del branch corretto, risolvi il bug, torni al branch di sviluppo, applichi git stash pop, e speri che i conflitti siano gestibili. In pratica esegui una sequenza di rattoppi.
dotata sia di interfaccia grafica (GUI) che di interfaccia a riga di comando (CLI), progettata fin dall’inizio per flussi di lavoro basati sull’intelligenza artificiale.
GitButler è una moderna interfaccia di controllo versione basata su Git, dotata sia di interfaccia grafica (GUI) che di interfaccia a riga di comando (CLI), disponibile su Linux, macOS e Windows, che parte da una premessa radicalmente diversa. Invece di obbligarti a lavorare su un branch alla volta, ti permette di mantenere più branch virtuali attive contemporaneamente nella stessa working directory, assegnando ogni modifica a una lane separata. Al momento del commit, ciascuna branch riceve solo le modifiche che le appartengono. Non è un wrapper di git stash: è un cambio di paradigma.
Un dettaglio importante da sapere: GitButler non sostituisce Git, lo usa come base. Ogni lane che crei corrisponde a un branch Git reale nel tuo repository. La differenza è che GitButler si occupa di tutta la gestione manuale che normalmente faresti tu con i comandi da terminale.
A fondarlo è Scott Chacon, co-fondatore di GitHub e autore di Pro Git, il libro di riferimento su Git con decine di milioni di lettori. Ad aprile 2026, GitButler ha chiuso un round Series A da 17 milioni di dollari guidato da Andreessen Horowitz. Non è un progetto hobbystico.
Il modello tradizionale di Git e il prezzo del context switch
Per capire cosa rende GitButler interessante vale la pena partire dal perché il branching tradizionale di Git è strutturalmente inadatto al modo in cui molti developer lavorano oggi.
In Git, la working directory riflette lo stato di un branch alla volta. Qualsiasi modifica non committata è in aria, appartiene a nessuno finché non viene committata o salvata manualmente. Di conseguenza, ogni volta che vuoi lavorare su qualcosa di diverso sei costretto a svuotare la working directory, con stash, con commit WIP e con branch temporanei.
Il context switch in Git richiede una sequenza di operazioni meccaniche che spezzano il flusso di lavoro. Con il tempo, la lista degli git stash cresce e diventa difficile da gestire: dopo qualche giorno non ricordi più cosa hai salvato e perché. I commit temporanei del tipo “work in progress” o “fix da rivedere” si moltiplicano e rendono la cronologia del progetto confusa, difficile da seguire per chiunque debba poi capire cosa è stato fatto e in che ordine.
Se poi stai lavorando su più funzionalità che dipendono l’una dall’altra, la situazione peggiora: le branch si ramificano in modi difficili da tenere a mente, e capire qual è il punto di partenza corretto per ciascuna diventa un problema a sé. Su team numerosi, o in scenari dove un agente AI genera diff in autonomia su più direzioni parallele, il problema si amplifica ulteriormente.
GitButler cambia il modo in cui pensi al problema. Invece di chiederti “su quale branch sono? Devo fare checkout? Cosa ho nello stash?”, ti chiede semplicemente: “questo file a quale lavoro appartiene?”. L’interfaccia divide lo schermo in lanes, cioè corsie separate, una per ogni attività che stai portando avanti.
Quando modifichi un file, lo trascini nella lane giusta, come smistare carte su tavoli diversi. Da quel momento GitButler sa che quella modifica appartiene a quella attività specifica, e non la mescolerà mai con le altre. Non devi cambiare branch, non devi salvare nulla manualmente: l’app tiene tutto separato per te.
Come funzionano le virtual branches nella pratica
Quando apri un progetto in GitButler, la prima cosa che fai è indicare qual è il tuo branch principale, di solito main o master. Questo diventa il punto di partenza da cui si ramificano tutte le attività parallele. Da quel momento, ogni file che modifichi appare nell’interfaccia come “non assegnato“, cioè in attesa di essere collocato da qualche parte.
Facciamo un esempio pratico. Stai lavorando su due cose contemporaneamente: stai sistemando un bug nel modulo di login e stai aggiungendo una nuova sezione alla pagina di navigazione. Con Git standard, gestiresti questi due lavori su branch separate, facendo avanti e indietro con il checkout o accumulando stash. Con GitButler, crei invece due lanes nella stessa schermata, una per ogni attività, senza mai cambiare branch.
Modifichi i file del login e li trascini nella prima lane. Modifichi i file della navigazione e li trascini nella seconda. Quando vuoi salvare il lavoro, ogni lane produce un commit che contiene solo le modifiche che hai assegnato a quella lane, e nient’altro.
L’interfaccia è organizzata in modo intuitivo: un pannello laterale mostra le lane attive, ognuna con il proprio nome, i file coinvolti e i commit già effettuati. I file ancora non assegnati stanno in una zona separata, ben visibile. Tutto si gestisce trascinando con il mouse.
Stacked branches: per chi lavora con PR dipendenti
Alcune funzionalità non si sviluppano in un colpo solo. Supponiamo che tu stia aggiungendo un sistema di pagamento alla tua app: prima devi modificare il database per aggiungere le nuove tabelle, poi aggiornare l’API che le gestisce, poi intervenire sul frontend per mostrare il tutto. Sono tre lavori distinti, che molti team preferiscono far revisionare separatamente tramite tre Pull Request diverse, in modo che chi fa la review possa concentrarsi su una parte alla volta.
Il problema è che queste tre PR non sono indipendenti: la seconda ha senso solo se la prima è già pronta, e la terza si appoggia sulla seconda. In Git, gestire questa catena a mano è noioso. Se durante la review ti chiedono di modificare la prima PR, devi aggiornare manualmente anche tutto quello che viene dopo, perché ogni branch è costruita sopra la precedente.
GitButler gestisce questa catena in automatico. Quando imposti le branch come uno stack, ovvero una sequenza ordinata in cui ognuna dipende dalla precedente, qualsiasi modifica a una PR intermedia viene propagata verso l’alto senza che tu debba fare nulla. GitButler ricalcola i collegamenti e mantiene tutto allineato.
Se poi usi GitHub, GitButler può anche aprire le Pull Request nel modo corretto: ogni PR viene collegata alla precedente nello stack, non direttamente a main. Così i reviewer vedono esattamente il contesto giusto per ogni pezzo, e il flusso di merge resta ordinato e tracciabile dall’inizio alla fine.
Installazione e primo setup
GitButler è disponibile come binario precompilato per tutte le piattaforme principali. Su Linux, il modo più diretto è scaricare il pacchetto .deb o .AppImage dalla pagina ufficiale e installarlo:
# Debian/Ubuntu, sostituisci X.Y.Z con la versione corrente
sudo dpkg -i gitbutler_X.Y.Z_amd64.deb
# In alternativa, con AppImage
chmod +x GitButler_X.Y.Z_amd64.AppImage
./GitButler_X.Y.Z_amd64.AppImageSu Arch Linux e derivate, GitButler è disponibile su AUR:
yay -S gitbutler-binSu macOS, il pacchetto .dmg è disponibile per entrambe le architetture (Intel e Apple Silicon). Su Windows, l’installer .exe segue il classico wizard di installazione.
Dopo il primo avvio, il flusso è semplice: aggiungi un progetto cliccando su Add local project e selezioni la directory del repository Git. GitButler rileva automaticamente lo stato del repository e ti chiede di impostare la integration branch. Da quel momento l’interfaccia è subito operativa.
GitButler dispone anche di una CLI chiamata but, installabile separatamente, utile per chi preferisce il terminale o vuole integrare GitButler in script e pipeline:
# Installa la CLI but tramite cargo
cargo install butLa CLI espone i comandi principali, tra cui list branches, create lane e commit, ed è la stessa engine Rust che usa l’applicazione desktop.
L’Agents Tab e l’integrazione con Claude Code
La direzione più recente di GitButler è quella dell’integrazione con gli agenti AI. Nell’Agents Tab puoi lanciare più istanze di Claude Code in parallelo, ciascuna assegnata a una lane virtuale separata. Ogni agente lavora sulla propria porzione di codebase, in isolamento dagli altri.
Quando si usa un agente AI per generare o modificare codice, le diff prodotte tendono a essere ampie e difficili da separare manualmente in commit logici. Con GitButler, l’agente opera già dentro una lane specifica e i suoi cambiamenti sono automaticamente separati da quelli di altri agenti o da quelli manuali.
Puoi anche installare hook Git che permettono a Claude Code di interagire con GitButler direttamente, creando commit, spostando file tra lane e aggiornando le PR, senza passare per i comandi Git standard.
L’intelligenza artificiale è presente anche nelle funzioni base: GitButler propone automaticamente messaggi di commit basati sulle modifiche rilevate, genera nomi per le branch in base al contesto del codice, e può scrivere la descrizione della Pull Request partendo dalla diff.
Chi dovrebbe usare GitButler ora
GitButler ha senso se lavori su progetti con frequenti interruzioni, se gestisci PR dipendenti su team con review rigorosa, o se stai sperimentando workflow con agenti AI che producono diff in parallelo. Non ha senso se lavori da solo su side project semplici dove il classico git checkout è più che sufficiente, e in quel caso la complessità aggiuntiva dell’interfaccia non porta vantaggi.
Il progetto è open source (licenza FSL, con transizione a MIT dopo due anni), attivamente mantenuto, e la base di codice in Rust e Svelte è ben strutturata.
I limiti attuali sono principalmente nell’esperienza di onboarding, dato che il modello mentale delle lane richiede qualche ora per diventare naturale, specialmente se sei abituato a pensare in termini di checkout. Il supporto a remote non-GitHub è meno rifinito: il supporto GitLab e Bitbucket è presente ma non ha la stessa profondità dell’integrazione nativa.
GitButler non è un wrapper attorno a un client Git esistente con qualche funzione AI messa sopra: è una riprogettazione del workflow di versioning a partire da un’idea precisa di come i developer, umani o AI, lavorano. E in questo senso, è probabilmente il client Git più interessante degli ultimi anni.
