I disse dager er versjonskontroll mer eller mindre synonymt med Git. Å komme inn i et prosjekt som ikke bruker Git er litt som å oppdage at det brukes tabs istedenfor mellomrom, eller at du er den eneste som bruker Emacs.
Men også innenfor versjonskontroll finnes det forbedringspotensiale, og i dag skal vi se litt nærmere på et versjonskontrollsystem som selv mener det har plukket det beste fra Git, Mercurial og Darcs: Jujutsu.
¶Kompatibelt med Git
Jujutsu (også kalt jj) har ikke bare innebygd støtte for Git, men krever at det ligger et Git-prosjekt i bunn. jj er fortsatt i aktiv utvikling, og istedenfor å bruke mye tid på å utvikle sin egen datamodell så lener det seg inntil videre på Git. I mellomtiden kan du bruke jj og Git om hverandre på samme prosjekt.
Dette betyr også at du kan bruke Github, Gitlab, Bitbucket eller noe annet akkurat som i dag. Det er heller ikke nødvendig at alle på teamet bruker jj over Git. Faktisk er det ingen som trenger å vite at du bruker det, det kan være vår lille hemmelighet.
¶Commit først, skriv koden etterpå
At Jujutsu er mer enn bare en alternativ frontend til Git oppdager før du skriver en eneste linje med kode. Det er nemlig slik at du med jj lager en commit først, og så lager du endringene den commiten skal inneholde. Commitmeldingen kan du også endre når som helst. Personlig liker jeg å beskrive hva det er jeg har tenkt å gjøre først, slik at hvis jeg av en eller annen grunn ikke kommer i gang eller rekker å bli ferdig, så har jeg et hint om hva det er jeg jobber med.
Mens du jobber vil endringene dine innlemmes i den aktive commiten hver gang du kjører en jj kommando, som f.eks. jj status eller jj diff. Dette betyr også at endringer lagrer seg når du hopper mellom forskjellige commits.
For å markere at en commit er ferdig så lager du en ny tom commit med jj new.
En annen interessant detalj med jj er at merge konflikter lagres som commits. Det gjør det mulig for jj å forstå at du ikke nødvendigvis trenger å løse en konflikt hvis en en senere endring uansett sletter eller omskriver hele seksjonen hvor konflikten befinner seg, noe som fort kan oppstå ved såkalt rebasing.
¶Lett å endre historikk
Git gjør det kanskje lett å omskrive endringshistorikken, men Jujutsu tar det hele et skritt lenger.
Har du lyst til å gjøre en endring i en tidligere kommit? Gå tilbake i tid, gjør endringen og når du kjører en jj kommando vil alle commits som stammer fra denne automatisk oppdateres til å reflektere endringen du nettopp gjorde. I tillegg til endringer kan du også splitte opp og slå sammen commits på denne måten. Enkelt og greit.
Eventuelle konflikter som oppstår pga denne historieomskrivningen lagres som egne commits, som betyr at du ikke trenger å løse de med en gang.
Skulle du ende opp med å gjøre noe du angrer på har Jujutsu en egen operasjonslogg som inneholder absolutt alle operasjoner du har utført, og du kan angre de operasjonene du vil. Dette fungerer litt som git reflog, men er mer detaljert og lar deg angre enkeltoperasjoner.
¶Vil Jujutsu bli det neste store?
Jujutsu føles mer som en inkrementell forbedring enn en revolusjonerende ny måte å versjonere kode på, og inkrementelle forbedring er ofte ikke godt nok for å erstatte et utbredt verktøy. Unntaket er når du kan få disse forbedringene uten ulemper.
Det at Jujutsu har en veldig god Git-integrasjon gjør meg til en forsiktig optimist, og jeg har allerede begynt å ta det i bruk i en rekke prosjekter.
Jeg har bare ikke sagt det til noen.
