Git (versionsstyring)
Git er et distribueret versionsstyringssystem, som udviklere bruger til at registrere og spore ændringer i kildekode over tid. Systemet gemmer hele historikken for et projekt, så det altid er muligt at se, hvem der har ændret hvad, hvornår det skete, og at vende tilbage til en tidligere version, hvis noget går galt. Git kan bruges helt uden en central server, fordi hver udvikler har en fuldstændig kopi af projektets historik liggende lokalt.
Forestil dig et lille udviklerteam, der bygger en webapplikation. Én udvikler retter en fejl i betalingsmodulet, mens en anden samtidig tilføjer en ny funktion til brugerprofilen.
Uden et system til at holde styr på ændringerne ville det være svært at vide, hvilke filer der var opdateret, og risikoen for at overskrive hinandens arbejde ville være stor.
Med Git kan begge udviklere arbejde uafhængigt af hinanden i deres egen del af koden og efterfølgende samle ændringerne, uden at det går ud over resten af projektet.
Sådan er en Git-arbejdsgang bygget op
Når en fil ændres i Git, gennemgår den typisk tre tilstande. Først er filen ændret, uden at ændringen er registreret nogen steder. Dernæst kan filen tilføjes til et såkaldt staging-område, hvor den markeres som klar til at blive gemt. Til sidst laver udvikleren et commit, som gemmer ændringen permanent i projektets historik sammen med en besked, der forklarer, hvad der er lavet, og hvorfor. Denne opdeling giver mulighed for at samle flere relaterede ændringer i ét commit, i stedet for at hver eneste tastetryk bliver logget for sig.
Fordi Git er distribueret, ligger denne historik ikke kun ét sted. Hver udvikler har sit eget lokale repository med hele projektets forløb, og de fleste kommandoer i Git – som at se historik eller sammenligne versioner – foregår derfor lokalt uden at kræve forbindelse til en server. Det gør arbejdet hurtigt og betyder, at man kan committe ændringer, selv når man er offline. Ændringerne kan senere sendes (“push”) til et fælles, centralt repository, hvorfra andre udviklere kan hente (“pull”) de nyeste opdateringer.
Branches gør det muligt at arbejde parallelt
En af Gits mest anvendte funktioner er branches, som fungerer som separate, parallelle udviklingslinjer af det samme projekt. En udvikler kan oprette en ny branch for at bygge en funktion eller rette en fejl, uden at det påvirker hovedversionen af koden.
Når arbejdet er testet og godkendt, kan branchen flettes sammen med hovedgrenen gennem det, der ofte kaldes en pull request eller merge request.
Går eksperimentet ikke som planlagt, kan branchen i stedet forkastes, uden at det har konsekvenser for resten af projektet. Denne arbejdsform bruges bredt i både backend udvikling og frontend udvikling, hvor flere dele af en applikation ofte udvikles sideløbende.
Git er ikke det samme som GitHub
Git og GitHub forveksles ofte, men de dækker over to forskellige ting. Git er selve teknologien til versionsstyring – det program, der kører på udviklerens computer og styrer historik, staging og commits.
GitHub er derimod en webbaseret tjeneste, hvor udviklere kan hoste deres Git-repositories online, dele kode med andre og samarbejde gennem funktioner som pull requests og issue-tracking.
Man kan altså sagtens bruge Git uden nogensinde at røre GitHub, for eksempel ved at have et privat, fælles repository på en anden server. Omvendt findes der flere platforme end GitHub, blandt andet GitLab og Bitbucket, som tilbyder lignende hosting af Git-repositories.
Gode vaner ved brug af Git
Selvom Git i bund og grund er et teknisk værktøj, afhænger nytten af det ofte af, hvordan det bliver brugt.
Hyppige commits med korte, meningsfulde beskeder gør det lettere at forstå historikken senere, og en klar strategi for, hvornår der oprettes nye branches, kan mindske risikoen for konflikter mellem forskellige udvikleres ændringer.
Mange teams vælger desuden at gennemgå hinandens kode via pull requests, før den bliver en del af hovedgrenen, hvilket kan bidrage til både kodekvalitet og videndeling i teamet.