Git worktree: più branch in checkout contemporaneamente
Guida a Git worktree
Git worktree: add, list, remove e prune, con esempi | We.Inc
Crea il comando git worktree add esatto per un nuovo branch, un branch esistente o un commit detached, poi elenca, blocca, sposta, rimuovi e pulisci i worktree in sicurezza.
git worktree permette a un unico repository di avere più cartelle di lavoro, ognuna sul proprio branch, che condividono un solo object store. Esegui git worktree add ../hotfix -b hotfix per creare una nuova cartella su un nuovo branch, git worktree list per vederle tutte e git worktree remove ../hotfix quando hai finito. Non serve un secondo clone.
I comandi worktree che ti servono ogni giorno
Operazione
Comando
Nuova cartella su un nuovo branch
git worktree add ../app-fix -b fix/login
Nuova cartella su un branch esistente
git worktree add ../app-review feature/cart
Cartella usa e getta su un commit
git worktree add --detach ../app-old v1.4.0
Vedere tutti i worktree
git worktree list
Eliminare un worktree
git worktree remove ../app-fix
Ripulire le cartelle eliminate a mano
git worktree prune
Fare stash, cambiare branch e ricompilare ogni volta che qualcuno chiede una correzione veloce è una perdita di tempo. Un worktree ti dà un secondo checkout dello stesso repo in un'altra cartella, così una lunga esecuzione dei test, una code review e una patch urgente possono vivere ciascuna nella propria directory. Usa il generatore per ottenere i comandi, poi consulta il riferimento per i sottocomandi meno comuni.
Scrivi la cartella che vuoi e il nome del branch, poi scegli nuovo branch, branch esistente o commit detached.
Copia il comando add ed eseguilo dall'interno del tuo checkout principale.
Lavora nella nuova cartella come in qualsiasi clone: lì fai commit, push e pull.
Quando il branch è stato fatto il merge, esegui il comando remove che mostra il generatore, e prune se ti è capitato di eliminare una cartella a mano.
Tieni i worktree come cartelle sorelle, per esempio ../app-fix, così non finiscono mai dentro l'albero del checkout principale.
Ogni worktree ha bisogno delle proprie dipendenze installate e del proprio output di build. Metti in conto lo spazio su disco per node_modules in ogni cartella.
Un branch può essere in checkout in un solo worktree alla volta. Se add si rifiuta, controlla con git worktree list dove è già aperto.
Blocca un worktree che si trova su un disco rimovibile con git worktree lock --reason "usb disk" così prune non lo cancella mentre è scollegato.
Domande frequenti
Qual è la differenza tra un worktree e un clone?
Un clone copia l'intero repository, cronologia compresa. Un worktree collegato condivide gli oggetti e i ref del repository originale e aggiunge solo una nuova cartella di lavoro più pochi metadati, quindi i commit fatti in uno sono subito visibili dagli altri senza fare fetch.
Due worktree possono usare lo stesso branch?
Non di default. git worktree add rifiuta un branch che è già in checkout altrove, perché due cartelle che spostano lo stesso branch sovrascriverebbero il lavoro l'una dell'altra. --force aggira il blocco, ma un HEAD detached o un secondo branch è quasi sempre la scelta migliore.
Perché git worktree remove fallisce?
Si rifiuta quando la cartella contiene file tracciati modificati o file non tracciati, così non perdi lavoro. Prima fai commit o ripulisci la cartella, oppure passa --force. Un worktree bloccato richiede --force due volte.
Cosa fa git worktree prune?
Elimina i record residui che git conserva per i worktree le cui cartelle non esistono più, per esempio dopo averne rimosso uno con rm -rf. Aggiungi -n per vedere prima cosa rimuoverebbe.
Come rinomino o sposto la cartella di un worktree?
Usa git worktree move <worktree> <new-path> così git aggiorna i suoi record. Se l'hai già spostata con il file manager, esegui git worktree repair dalla nuova posizione per ricollegarla.
Buoni motivi per usare i worktree
Fare la review di una pull request senza toccare il lavoro a metà, tenere una suite di test lenta in esecuzione su un branch mentre programmi su un altro e confrontare due versioni di un'app fianco a fianco sono i casi classici.
Sono adatti anche agli strumenti che eseguono più sessioni di sviluppo su un unico repository: ogni sessione ha la propria cartella e il proprio branch, così i file non committati di una sessione non finiscono mai nella build di un'altra.
Cosa è condiviso e cosa no
Tutti i worktree condividono commit, branch, tag, remote e gran parte della configurazione. Ognuno ha il proprio HEAD, il proprio index e i propri file di lavoro, quindi lo staging in una cartella non ha effetto sulle altre.
I file ignorati come .env, node_modules e le cartelle di build non vengono copiati in un nuovo worktree. Copia tu il file env e installa le dipendenze prima di eseguire qualsiasi cosa.