Smettetela di trattare il comando ‘git rebase -i’ come se fosse una bomba in uno di quei film d’azione anni ’90, dove basta un respiro troppo forte per far saltare in aria l’intero repository. Siamo onesti: gestire decine di branch paralleli, commit sparsi e modifiche che si intrecciano è un lavoro che farebbe perdere la pazienza anche a un monaco buddista con un setup da hacker professionista.
Negli ultimi mesi, l’hype intorno a ‘jj’ (Jujutsu) ha promesso di rivoluzionare il nostro workflow, risolvendo quel caos che Git ci ha ereditato. Molti di noi hanno provato a saltare sul carro del progresso, ma poi, alla fine della settimana, siamo tornati tutti con la coda tra le gambe a usare il vecchio, fidato Git. Perché? Perché cambiare tutto il proprio paradigma mentale è una fatica bestiale.
Eppure, ecco la bella notizia: Git sta iniziando a integrare da solo delle funzioni che portano un po’ di quella magia senza costringerci a disinstallare tutto. Parliamo del nuovo set di comandi sperimentali ‘git history’ (presenti nelle versioni 2.54 e 2.55). Non è una rivoluzione totale, ma è come se avessero finalmente aggiunto un filtro anti-panico al nostro tool preferito.
Vediamo cosa ci offre questo nuovo kit di sopravvivenza:
Il comando ‘fixup’ è quello che mi ha fatto battere il cuore. Avete presente quando fate un commit, vi accorgete di aver dimenticato una virgola o un commento, e dovreste fare tutta la danza rituale del rebase per non sporcare la cronologia? Con ‘git history fixup’, modifichi il commit vecchio e Git si occupa di fare l’autosquash e, cosa fondamentale, di aggiornare automaticamente tutti i branch che derivano da quel commit. È un aggiornamento atomico: o funziona tutto o non succede nulla, niente alberi di commit a metà o stati di errore che ti fanno venire voglia di lanciare il laptop dalla finestra.
Poi c’è ‘reword’. Cambiare un messaggio di commit su un branch che non hai nemmeno checkato è un piacere immenso. Non tocca l’index, non tocca il working tree, lavora solo sul grafo. Pulito, veloce, senza drammi.
Infine, il ‘split’. Se avete mai committato due modifiche completamente slegate (sì, parlo di voi, non fate gli sognatori) nello stesso commit, sapete quanto sia un incubo separarle. ‘git history split’ ti permette di smontare un commit in due o più pezzi in modo interattivo, molto simile a un ‘git add -p’ ma senza tutte quelle acrobazie mentali tipiche del rebase.
Certo, non è ancora il paradiso. Non abbiamo ancora la gestione dei conflitti ‘first-class’ di jj o quel log delle operazioni che ti permette di fare ‘undo’ come se fossi in un videogioco. Però, per essere parte del core di Git e già utilizzabile senza installare pacchetti strani, è un passo avanti enorme. Se Git continua su questa strada, potremmo finalmente smettere di temere il comando rebase e ricominciare a goderti il bello del coding senza l’ansia da prestazione del commit sbagliato.
Source: The git history command