Hva er en feature branch?
En feature branch er en kopi av hovedkodebasen der en enkelt utvikler eller et team av programvareutviklere kan jobbe med en ny funksjon til den er ferdig.
Når mange utviklere jobber i samme kodebase, er det viktig å ha en strategi for hvordan de samarbeider. For å unngå å overskrive hverandres endringer oppretter utviklerne sin egen kopi av kodebasen, kalt branches (grener). I analogi med et tre kalles hovedgrenen noen ganger for stammen (trunk). Prosessen med å innlemme endringene fra en individuell kopi inn i hovedstammen kalles merging (sammenslåing).
Utviklingsprosessen med feature branches
I feature branch-utvikling slår ikke individuelle utviklere eller team sammen grenen sin før en funksjon er ferdigstilt, og de jobber noen ganger i uker eller måneder på en separat kopi. Denne lange tidsperioden kan gjøre sammenslåingsprosessen vanskelig, fordi stammen eller master sannsynligvis har endret seg på grunn av andre utviklere som har slått sammen sine grener. Dette kalles en merge-konflikt.
Feature branch-utvikling og sammenslåing av kildekode håndteres i versjonskontrollprogramvare som Git, mest kjent som tjenesten Github. Hovedgrenen og feature branches lever i dette kodelageret (eller repoet), og utviklere sjekker ut kode for å opprette en ny gren å jobbe fra.
Når endringene i koden er gjort, oppretter utvikleren det som kalles en pull request, altså en forespørsel om at andre utviklere på teamet gjennomfører en kodegjennomgang for å sikre at den lokale grenen ikke har noen feil, og at den heller ikke vil forårsake feil når den slås sammen med hovedgrenen. Når en gren er grundig gjennomgått, kan den slås sammen med hovedgrenen og bli en del av hovedrepoet.
Git branch-utvikling er én metode for å håndtere mange utviklere som jobber fra samme kodebase. Moderne team bruker ofte kontinuerlig integrasjon og trunk-basert utvikling for å unngå problemer med feilrettinger og merge-konflikter som oppstår fra branching-modellen for kodeutvikling. Dette bidrar til å forhindre problemer med at flere personer jobber på samme kodebase, og holder en detaljert logg over hvilken kodebit som ble lagt til av hvem, når og hvor. Denne prosessen er også kjent som rebasing.
Hva gjør man ved problemer med en feature branch
En av fordelene med å utvikle i en feature branch er at den ikke påvirker hovedkoden din før du slår den sammen igjen. Ved å bruke en git-arbeidsflyt kan du rulle tilbake til tidligere versjoner ved hjelp av versjonskontrollfunksjonene.
Her er et par vanlige git-funksjoner som kan hjelpe med å diagnostisere og rulle ut en hurtigreparasjon
-
Bruk git pull for å laste ned den nyeste koden fra hovedgrenen. Hvis du henter fra hovedgrenen, er denne kommandoen synonymt med git pull master origin.
-
Bruk git push for å sende tilbake koden du har oppdatert til utviklingsgrenen din.
-
Git branch var sannsynligvis kommandoen du kjørte for å forgrene fra hovedgrenen din.
-
Git checkout lar deg bytte til forskjellige versjoner av en gren. Dette forteller Git hvilken versjon du ønsker å registrere endringer på før du sender koden tilbake.
-
Git merge er i bunn og grunn det motsatte av en git branch, og lar deg slå sammen endringene dine tilbake i hovedkoden du forgrenet fra, samt rydde opp ved å fjerne grenen din.
Ved hjelp av disse kommandoene kan devops-teamet evaluere utviklingsarbeidet sitt og bruke versjonskontrollsystemet til å feilsøke spesifikke versjoner og rulle tilbake der det er nødvendig. Hvis du er i en organisasjon med mange teammedlemmer som jobber på samme kodebase og bruker feature branches, kan dette hjelpe med å diagnostisere problemer raskt.
Hvorfor bruke branching-strategier
Bruk av feature branches isolerer hver funksjon i sitt eget separate område, overvåket av versjonskontrollprogramvaren (vanligvis git). Dette gjør det mulig å jobbe med nye, eksperimentelle funksjoner uten å påvirke hovedkoden direkte, samtidig som du kan hente ned nye versjoner og oppdateringer som kan ha kommet mens du jobbet med den nye funksjonen. Dette er spesielt nyttig i team der flere teammedlemmer jobber på det samme sentrale kodelageret.
En separat gren isolerer problemer og utvikling i en utgivelsesgren, som kan slås sammen igjen når den er ferdig. Å ha en git-arbeidsflyt og tydelige kommunikasjonslinjer mellom utviklere og ingeniører kan bidra til å fjerne konflikter, og gjøre det mulig å utvikle forskjellige kodegrener samtidig uten at de forstyrrer hverandre.
Som en del av en branching-strategi er det viktig å ikke bare fokusere på gitflow, men også på praksiser for feature branch-arbeidsflyt som navnekonvensjoner for grener og kodegjennomgang. Versjonskontrollen er eksepsjonelt nyttig funksjonalitet som gjør det mulig for flere teammedlemmer å gjennomgå kode før den sendes ut.
Noen vanlige navnekonvensjoner for feature branches:
-
Vær beskrivende – hvilken funksjon jobbes det med
-
Vær kort, bruk ikke flere ord enn nødvendig. Hvis det trengs mer forklaring, legg det til i beskrivelsen
-
Skriv det på en måte som andre utviklere og ingeniører kan forstå hva det jobbes med
Selv om du jobber med flere nye funksjoner samtidig, er det fortsatt god praksis å opprette grener for hver enkelt funksjon slik at de ikke kommer i konflikt med hverandre.
Når du er klar, bruk en pull request for å la andre teammedlemmer gjennomgå koden din og slå den sammen tilbake i det sentrale lageret. Det er dårlig praksis å slå sammen og gjennomgå din egen kode. Det kan alltid oppstå uforutsette problemer med den aktuelle funksjonen din som andre kan fange opp i en gjennomgang.
Kontinuerlig integrasjon og feature branches
Et alternativ til feature branch-arbeidsflyten er kontinuerlig integrasjon, som er en programvareutviklingsmetodikk som innebærer at nye kodeendringer kontinuerlig integreres i hovedlinjen eller stammen, i stedet for å vente til en ny feature branch har vært under utvikling i uker eller måneder og har divergert fra hovedgrenen.
Kontinuerlig integrasjon, også kjent som trunk-basert utvikling, bidrar til å minimere merge-konflikter ved å kontinuerlig slå sammen endringer i én enkelt kilde for å forhindre feature branching. Kontinuerlig integrasjon, sammen med praksiser som feature flagging, kan hjelpe utviklere med å distribuere kode raskere og bruke mindre tid på å forsone forskjellige versjoner av kode.
