By Drew Seewald, Dataforsker

Versjonskontroll er viktig for å samarbeide om kode, dele den med andre, kunne se gamle versjoner av koden og til og med distribuere koden automatisk. Det kan være litt forvirrende i begynnelsen, men det er vel verdt tiden din, spesielt hvis du jobber i åpen kildekode eller på et team der du ofte vil bruke versjonskontroll for prosjekter. Her er noen av de største funksjonene som gjør det verdt å bruke:

• Lagre filendringshistorikk med kommentarer
• Organiserer flere brukere som redigerer det samme prosjektet samtidig
• Tilrettelegge for prosedyrer for gjennomgang av kode
• Automatisere arbeidsflyter for å rapportere problemer, be om forbedringer og distribuere kode

Slapp av, du trenger ikke å bruke kommandolinjen
Photo by Dennis van Dalen on Unsplash
 

Versjonskontrollfunksjoner

 
 
En av hovedfunksjonene i versjonskontroll er filendringsloggen for hver fil i depotet. Dette fungerer som en endringslogg for hver fil, så det er alltid mulig å se hvilken kode som kjørte på et hvilket som helst tidspunkt tidligere. Hver gang noen oppdaterer en fil og skyver den nye versjonen til depotet, må de legge til en kort kommentar. I en perfekt verden beskriver denne hva endringene var og hvorfor de ble gjort. Hvis det noen gang er et spørsmål om hvorfor noe ble endret eller hvorfor, vil den ansvarlige bli merket i forpliktelsen, sammen med tilleggsinformasjonen de ga.

En annen funksjon ved versjonskontroll er muligheten til å lage grener. En gren er en ny versjon av koden som holdes adskilt. Dette er nyttig for å gjøre og teste endringer i koden, da den ikke endrer hovedgrenen, der den mest oppdaterte arbeidsversjonen er. Grener kan også brukes av forskjellige brukere til å arbeide med forskjellige koder eller funksjoner samtidig. Disse grenene kan slås tilbake til mesteren når de er klare, og det er en prosess for å forene forskjellene mellom dem ved sammenslåing.

Kodevurdering er en god praksis når du arbeider med team. Én person kan gjøre alt arbeidet med en ny funksjon i en ny gren, men før den blander seg sammen med hovedgrenen, bør den gjennomgås av teamet. Når en pull -forespørsel opprettes for å flytte kode til hovedgrenen, starter den også en diskusjon der teammedlemmer kan snakke om koden og be om endringer før den blir slått sammen med hovedgrenen. Denne prosessen bør bidra til å forbedre koden som gjør den i produksjon for å forhindre feil og brudd, forbedre effektiviteten til koden eller til og med få den til å matche en standard for formatering av koden.

En siste bemerkelsesverdig fordel ved å bruke GitHub for versjonskontroll er automatiseringsalternativene den tilbyr. Hvis det er en standard sjekkliste for gjennomgang av kode, kan den legges til som en mal som vil være tilgjengelig når en pull -forespørsel opprettes, klar til å fylles ut etter hvert som gjennomgåelsesoppgavene er fullført. Maler kan også brukes når folk oppretter problemer, slik at de husker alle detaljene de trenger å legge inn når de oppretter et problem. GitHub tilbyr også handlinger for å støtte automatisering. Disse kan utløses av forskjellige hendelser, for eksempel sammenslåing av kode i hovedgrenen. En handling kan kjøre enhetstester, bygge/kompilere pakkekomponenter og til og med distribuere kode til produksjon.

Versjonskontroll smaker

 
 
Det er noen få store versjonskontroll du kanskje har hørt om. Noen av de mest populære er Git og GitHub. gå er den underliggende teknologien for versjonskontroll, og GitHub er programvare som forenkler arbeidsflyten for versjonskontroll.

Git kan brukes lokalt, uten behov for et eksternt depot. Du kan utføre alle versjonskontrolloppgavene på datamaskinens harddisk. Lokale Git -lagre er ideelle for personlige prosjekter eller for når du ikke er helt klar til å dele koden din med hele teamet ditt, men fortsatt vil ha fordelene med versjonskontroll.

GitHub -nettstedet er et depot for lagring av kode. Mange åpne kildekode -prosjekter, for eksempel Python- og R -pakker, er vert på GitHub -nettstedet. For offentlige depoter kan hvem som helst se revisjonshistorikk, problemer med pakken og dokumentasjon knyttet til den.

For å koble til et depot på GitHub -nettstedet, kan vi bruke Git eller GitHub Desktop. For de av dere som elsker et kommandolinjegrensesnitt (CLI), Rebecca Vickery har en flott artikkel om ved hjelp av Git CLI for Data Science. Så hvorfor skal du fortsette å lese? Kommandolinjer kan være skremmende. Det er ingenting galt med å ønske et grafisk brukergrensesnitt (GUI) for å administrere versjonskontrollen. GitHub Desktop gir et klart og enkelt grensesnitt med depotet ditt.

GitHub Desktop-prosessflyt

 
 
Selv om alle vil ha en litt annen prosessflyt for depotet, er det noen få generelle trinn for å gjøre endringer i koden på GitHub:

1. Opprette en gren
2. Legger til forpliktelser
3. Oppretter en ny pull -forespørsel
4. Gjennomgang av kodevurderingen
5. Slå sammen trekkforespørselen

Når du oppretter en gren, blir en kopi av den nåværende produksjonskoden. En utvikler vil gjøre endringer i filene, og foreta eventuelle endringer i den nye grenen. Deretter vil en pull -forespørsel åpne diskusjon for å legge til den nye grenens endringer i produksjonskoden, vanligvis i hoved- eller hovedgrenen. Kodevurderere kan legge til kommentarer og be om avklaring på endringene som er gjort på trekkforespørselen. Når anmeldelsen er fullført og nødvendige endringer er gjort, kan trekkforespørselen slås sammen med hoved- eller hovedgrenen og lukkes.

La oss gå gjennom disse trinnene mer detaljert og se på hvordan du gjør hver enkelt ved hjelp av GitHub Desktop.

Opprette en gren (skille den nye koden fra den gamle)

 
 
For å gjøre en endring, opprett først en ny gren. Hvis du har full tilgang til depotet, kan du ganske enkelt opprette en ny gren på depotets GitHub -nettsted.

1a. Klikk på Gren: hoved

Bilde av forfatteren

 

2a. Skriv inn navnet på den nye grenen i tekstboksen. Det kan være noen granskingskonvensjoner du bør vurdere fra organisasjonen din for å holde ting organisert

Bilde av forfatteren

 

3a. Klikk på Opprett gren

Bilde av forfatteren

 

Den nye grenen vil nå bli valgt.

Bilde av forfatteren

 

Hvis du ikke har full tilgang til depotet, som er vanlig for offentlige prosjekter, må du forkle depotet. En ny gren og en gaffel er synonymt. En gaffel vil bli opprettet i et nytt depot i motsetning til det samme som produksjonskoden, vanligvis under din personlige profil. Å gaffel:

1b. Klikk på Gaffel øverst til høyre

Bilde av forfatteren

 

2b. Vent til filene er kopiert

Bilde av forfatteren

 

3b. Den nye gaffelen vil bli valgt

Bilde av forfatteren

 

Legge til forpliktelser (forbedre koden/legge til funksjoner)

 
 
For å forplikte seg til koden, vil du klone depotet til din lokale datamaskin. Dette kopierer koden du kan jobbe med før du sender oppdateringene tilbake til depotet. Slik kloner du depotet til din lokale maskin:

Klikk klone eller last ned.

Bilde av forfatteren

 

Klikk på åpne med GitHub -skrivebordet.

Bilde av forfatteren

 

Hvis du ikke har GitHub Desktop, klikker du på nedlasting GitHub Desktop.

Bilde av forfatteren

 

GitHub -skrivebordet vil spørre hvor du skal klone depotet på din lokale maskin. Dette er feltet Lokal bane.

Bilde av forfatteren

 

Klikk på grenen og velg den nyopprettede grenen. Dette vil oppdatere filene på din lokale maskin med eventuelle oppdateringer på den grenen og gjøre den til den aktive å legge til forpliktelser til.

Bilde av forfatteren

 

For å gjøre endringer, åpne katalogen du valgte under kloning, og gjør endringer med tekstredigereren eller det integrerte utviklingsmiljøet (IDE) som normalt. Lagre filene.

Gå tilbake til GitHub Desktop. GitHub Desktop skanner kontinuerlig depotet i depotet og ser eventuelle endringer du gjør. Disse endringene vises i den venstre ruten. Den høyre ruten vil forhåndsvise endringer i den valgte filen (visse filtyper vil ikke forhåndsvise).

Bilde av forfatteren

 

Hver gang du gjør et sett med relaterte endringer, overfører du disse endringene til depotet ditt. Husk å legge til kommentarer til forpliktelsene, slik at folk enkelt kan identifisere hva som ble endret. Den øvre tekstboksen er for en rask beskrivelse, men hvis du har flere notater å legge til om forpliktelsen, legger du dem i den større beskrivelses tekstboksen.

Med endringer gjort og kommentarer lagt til, forplikter du endringene.

Bilde av forfatteren

 

Endringer lagrer dem bare i de lokale filene. Klikk push -opprinnelse for å skyve endringene tilbake til GitHub -serveren. Hvis det gjøres forpliktelser som ikke er blitt skyvet tilbake til serveren, vil det vises en melding i høyre rute som sier Skyv xx commit (r) til opprinnelsesfjernkontrollen. Opprinnelsen er bare et navn på hvor depotet ble klonet fra.

Bilde av forfatteren

 

Åpne en Pull -forespørsel

 
 
Naviger til depotet ditt på GitHub -serveren. Sørg for at du er på riktig gren. Hvis du opprettet en ny gren på det opprinnelige depotet, navigerer du dit. Hvis du måtte gaffel depotet, navigerer du til depotet på din personlige profil.

På Trekk forespørsler kategorien, klikk på Ny trekkforespørsel.

Bilde av forfatteren

 

Velg den nye grenen som den du vil sammenligne, og klikk på opprett trekkforespørsel. I vårt tilfelle fylles forespørselen automatisk ut med våre kommentarer.

Bilde av forfatteren

 

Kode anmeldelse

 
 
Kodevurdering hjelper deg med å sikre at koden vi legger til eller endrer er korrekt og har blitt gjennomgått og godkjent av flere personer. Enten du har tilgang til et depot eller ikke, bør du alltid la granskere sjekke endringene. Hvis det er spørsmål, gå over dem som et team.

Pull -forespørsler vises under fanen Pull -forespørsel i depotet. Hver trekkforespørsel har en samtale, forpliktelser og filer endret faner.

Samtale er hvor folk kan legge til spørsmål eller kommentarer om koden. Du kan formatere kommentarene dine og merke personer og problemer i kommentarene dine.

Commits viser alle forpliktelsene og kommentarene som er gjort i pull -forespørselen

Filer endret viser hvilke filer som ble endret, lagt til eller slettet sammen med linje for linje sammenligninger av kode der det er tilgjengelig

Bilde av forfatteren

 

Slå sammen forespørselen om trekking

 
 
I mitt tilfelle ble hovedgrenen min endret mens jeg jobbet med den nye grenen. Det er derfor det er meldinger som sier at det er konflikter å løse. Klikk på knappen Løs konflikter for å åpne en redaktør. Det vil vise versjonen av filen fra hver gren, slik at du kan slette den ene og beholde den andre, eller lage en versjon av begge.

Bilde av forfatteren

 

I dette tilfellet er versjonen fra hovedgrenen riktig. Endringene fra den andre grenen og separatorene kan slettes. Konflikten kan merkes som løst, og forpliktet til sammenslåingen.

Bilde av forfatteren

 

Med kodevurdering og konflikter ute av veien, kan trekkforespørselen slås sammen. Nok en gang vil det være et alternativ til å gi en kommentar til hva sammenslåingen oppnår. Etter sammenslåing vil koden være en del av master- eller hovedgrenen!

Bilde av forfatteren

 

Og der har du det, du vet nå hvordan du fullfører de mest grunnleggende versjonskontrolloppgavene ved hjelp av GitHub og GitHub Desktop!

Jeg skriver om datavitenskap, analyse og programmeringskonsepter. Du kan koble deg til meg på Medium, Twitterog Linkedin.

Videre Reading

 
 
Forstå GitHub -flyten
Når du jobber med et prosjekt, vil du ha en rekke forskjellige funksjoner eller ideer på gang til enhver tid ...

 
Versjonskontroll med Git
Wolfman og Dracula har blitt ansatt av Universal Missions (en romtjeneste fra Euphoric State University) til ...

 
Hva er versjonskontroll | Atlassian Git -opplæring
Versjonskontroll, også kjent som kildekontroll, er praksisen med å spore og administrere endringer i programvarekode ...

 
Bio: Drew Seewald er dataforsker hos Mercedes-Benz Financial Services. Følg Drew på Twitter @RealDrewData eller koble til Linkedin.

original. Ompostet med tillatelse.

Relatert:

• GitHub Copilot -alternativer for åpen kildekode
• 3 Verktøy for datainnsamling, annotering og forstørrelse
• GitHub Copilot og fremveksten av AI-språkmodeller i programmeringsautomatisering