Komponenter i GitHub-flödet

Slutförd

I den här lektionen granskar vi följande komponenter i GitHub-flödet:

• Grenar
• Incheckningar
• Pull-begäranden
• GitHub-flödet
• Git-flöde

Komponenter i GitHub Flow

Innan vi kommer in i GitHub-specifika arbetsflöden är det bra att förstå att GitHub Flow bygger direkt på Gits grundläggande begrepp.

Git tillhandahåller verktyg för att spåra och hantera ändringar i koden över tid. GitHub bygger vidare på detta genom att göra det enklare att använda dessa verktyg med funktioner som grenar, incheckningar, pull-begäranden och visuella gränssnitt för samarbete. Vi börjar med att titta på hur de här begreppen fungerar i GitHub.

Vad är grenar

I det sista avsnittet skapade vi en ny fil och en ny gren på lagringsplatsen.

Grenar är en viktig del av GitHub-upplevelsen. Du kan göra ändringar utan att påverka standardgrenen.

Din gren är en säker plats för att experimentera med nya funktioner eller korrigeringar. Om du gör ett misstag kan du återställa dina ändringar eller skicka fler ändringar för att åtgärda misstaget. Ändringarna uppdateras inte på standardgrenen förrän du har sammanfogat grenen.

Kommentar

Du kan också skapa en ny gren och checka ut den med hjälp av git i en terminal. Kommandot skulle vara git checkout -b newBranchName

Vad är kommitteringar?

I föregående enhet lade du till en ny fil i arkivet genom att göra en commit. Nu ska vi kort gå igenom vad åtaganden är.

En commit är en ändring i en eller flera filer i en gren. Varje incheckning spåras av ett unikt ID, tidsstämpel och deltagare, oavsett om det görs via kommandoraden eller direkt i GitHubs webbgränssnitt. Commitar ger en tydlig revisionshistorik för alla som granskar historiken för en fil eller ett länkat objekt, till exempel en issue eller en pull request.

Du kan skapa en incheckning med Git i terminalen med:

git commit -m "Add a helpful commit message"

I en git-lagringsplats kan en fil finnas i flera giltiga tillstånd när den går igenom versionskontrollprocessen. De primära tillstånden för en fil på en Git-lagringsplats är ospårade och spårade.

Ej spårad: Ett initialt tillstånd för en fil när den ännu inte är en del av Git-lagringsplatsen. Git är omedveten om dess existens.

Spårad: En spårad fil är en fil som Git aktivt övervakar. Det kan finnas i någon av följande undertillstånd:

• Oförändrad: Filen spåras, men den har inte modifierats sedan den senaste commiten.
• Ändrad: Filen har ändrats sedan det senaste åtagandet, men dessa ändringar har ännu inte justerats för nästa åtagande.
• Staged: Filen har ändrats och ändringarna har lagts till i arbetsområdet (även kallat indexet). De här ändringarna är redo att genomföras.
• Bekräftad: Filen finns i databasen för lagringsplatsen. Den representerar den senaste bekräftade versionen av filen.

Dessa tillstånd hjälper ditt team att förstå statusen för varje fil och var den finns i versionskontrollprocessen.

Vad är pull requests?

En pull request är en mekanism för att signalera att ändringar i en gren är klara att sammanfogas med en annan gren.

Den teammedlem som skickar pull-begäran ber en eller flera granskare att verifiera koden och godkänna kopplingen. Dessa granskare kan kommentera ändringar, lägga till egna ändringar eller använda pull-begäran för ytterligare diskussion.

GitHub stöder också pull-begäranden för utkast, vilket gör att du kan öppna en pull-begäran som ännu inte är redo för granskning.

När ändringarna har godkänts (om det behövs) sammanfogas pull-begärans källgren (jämförelsegrenen) i basgrenen.

Nu när du har sett hur grenar, incheckningar och pull-begäranden fungerar ska vi gå igenom hur de samlas i GitHub Flow.

GitHub-flödet

GitHub-flödet är ett enkelt arbetsflöde som hjälper dig att göra och dela ändringar på ett säkert sätt. Det är bra att prova idéer och samarbeta med ditt team med hjälp av grenar, pull-begäranden och sammanslagningar.

Kommentar

GitHub-flödet är ett av flera populära arbetsflöden. Andra inkluderar Git-flöde och trunkbaserad utveckling.

Nu när vi vet grunderna i GitHub kan vi gå igenom GitHub-flödet och dess komponenter.

1. Börja med att skapa en gren så att dina ändringar, funktioner eller korrigeringar inte påverkar huvudgrenen.
2. Gör sedan dina uppdateringar i grenen. Om arbetsflödet stöder det kan du distribuera ändringar från den här grenen för att testa dem innan du sammanfogar dem.
3. Öppna nu en pull-begäran för att bjuda in feedback och påbörja en granskning.
4. Granska sedan kommentarerna och gör eventuella nödvändiga uppdateringar baserat på teamets feedback.
5. Slutligen, när du är säker på dina ändringar, får du godkännande och sammanfogar pull-begäran till huvudgrenen.
6. Därefter tar du bort grenen för att hålla lagringsplatsen ren och undvik att använda inaktuella grenar.

Git-flöde

GitHub Flow är ett enkelt arbetsflöde som utformats för kontinuerlig leverans, men Git-flödet är en mer strukturerad förgreningsmodell som ofta används i versionsdrivna miljöer. Git-flödet har funnits längre än GitHub Flow och du kan fortfarande se termen master som används i stället main för som standardgren.

Grentyper för Git-flöde

Git-flödet använder flera långlivade och tillfälliga grenar:

• master: Återspeglar alltid produktionsklar kod.
• utveckla: Innehåller det senaste utvecklingsarbetet för nästa version.
• feature/*: Används för att skapa nya funktioner; förgrenad från develop och sammanfogad tillbaka när den är klar.
• release/*: Förbereder en ny produktionsversion från develop; tillåter slutlig testning och mindre felkorrigeringar.
• snabbkorrigering/*: Används för att snabbt korrigera produktionsproblem; förgrenad från master.

Så här fungerar Git-flödesprocessen

1. Utvecklare skapar funktionsgrenar från develop för att skapa nya funktioner.
2. När det är dags för en version skapas en versionsgren från develop. Detta isolerar förberedelsearbetet för versioner så att utvecklingen kan fortsätta oavbrutet.
3. Buggkorrigeringar kan läggas till i versionsgrenen, men viktiga funktioner bör vänta på en framtida version.
4. När den är klar sammanfogas versionsgrenen till master och taggas med ett versionsnummer. GitHub kan använda dessa taggar för att generera viktig information.
5. Samma versionsgren bör sammanfogas igen develop för att hålla den synkroniserad.
6. Om ett kritiskt produktionsfel uppstår skapas en snabbkorrigeringsgren från master. När den har åtgärdats sammanfogas den till både master och develop.

När du ska använda Git-flöde

• Passar bäst för projekt med schemalagda eller versionsutgåvor
• Användbart om du underhåller flera produktionsversioner (t.ex. långvariga supportgrenar)
• Perfekt för långsammare, mer strukturerade utvecklingscykler (t.ex. företagsmiljöer eller reglerade miljöer)
• Anses vara mer "tungviktare" än GitHub Flow på grund av ytterligare grenhantering

Kommentar

Git-flödet förutsätter sammanslagning av incheckningar för integrering av grenar. Om du använder rebase- eller squashsammanslagningar kan det störa dess grenstruktur och historikspårning.

För många team som använder GitHub är GitHub Flow enklare och snabbare. Men om ditt team värdesätter förutsägbarhet och behöver mer versionsplanering kan Git-flödet passa bättre.

Grattis! Du har precis gått igenom hela GitHub Flow – och utforskat hur Git Flow erbjuder ett strukturerat alternativ för versionsdrivna projekt.

Nu går vi vidare till nästa avsnitt där vi går igenom skillnaderna mellan frågor och diskussioner.