Master Version Control för avlägsna lag

Arbeta har blivit mycket vanligare i webbutveckling de senaste åren. Innan versionskontroll, skulle arbeta på distans på samma utvecklingsprojekt ha varit en absolut mardröm. Utvecklare skulle ha varit tvungen att Skicka stora filer till varandra (förmodligen via e-post), klistra in i sin egen kod innan den skickas tillbaka. Det fanns inget riktigt sätt att spåra vad som hade lagts till och när.

• 6 måste ha färdigheter för unga webbutvecklare

Tack och lov har Version Control anlänt och gjorde utveckling på alla fronter mycket mer hanterbara. Webprojekt har blivit mycket enklare att genomföra och hantera, särskilt när det gäller att arbeta i ett fjärrutvecklingslag. Du behöver inte längre oroa dig för den aktuella versionen av en webbplats som skrivs över - varje lagmedlem är gratis att arbeta med någon fil när som helst, det finns ingen förvirring om var den senaste versionen av en fil lagras - och topp molnlagring Hjälper med processen också.

I den här handledningen ska vi använda Github att hantera vår kod. Det finns många olika typer av versionskontrollverktyg där ute, till exempel Bitbucket och TFVC, men även om de är olika, är principerna lika när det gäller hanteringskod.

För mer sätt att göra din webbplats bygga process lättare, se våra guider till toppen Website Builder och webbhotell service.

Förgrenande modell

För det första är det mycket viktigt att ha en framgångsrik förgrenningsmodell när man arbetar i något lag för att göra utvecklingen och utplaceringsprocessen löpa smidigt. Du kommer sannolikt att få flera utvecklare som arbetar med samma projekt. När du arbetar med en fjärransluten arbetskraft tror jag att det bästa arbetsflödet består av tre huvudgrenar samt en uppsättning tillfälliga:

• Utveckla gren: Varje kodlinje har testats och validerats av klienten.
• Staging Branch: Detta motsvarar valideringsmiljön.
• Släpp gren: Detta innehåller den senaste versionen av din webbplats i produktionen.

Det kommer också att finnas en uppsättning av funktionsgrenar. Men dessa kommer bara att vara tillfälliga för att initialt bygga ut de nya funktionerna.

Flera utvecklare på ett projekt

Låt oss anta att du kör ett lag med två utvecklare som arbetar på distans. Vi kommer att kalla dem Sarah och James: De arbetar båda på samma e-handelswebbplats för en klient. Sarah behöver utveckla en funktion som registrerar kundens detaljer.

Vi skulle bryta ner detta i tre separata användarberättelser - lägga till, redigera och ta bort - och lägg sedan till dessa tre biljetter i Sprint-eftersläpningen.

Funktionsgrenar

Så, låt oss säga att Sarah börjar på avsnittet Lägg till kundinformation. Hon skulle behöva skapa funktionsgrenens kunduppgifter och en användarhistoria en för den första uppgiften "tilläggsuppgifter".

 Git Checkout Utveckla & Amp; & amp; git pull ursprung / utveckla
GIT-kassan -B-funktion / Kunduppgifter
Git Checkout -B Add-Detaljer 

Sarah skulle fortsätta att arbeta på den tillfälliga filialen "tilläggsadress" lokalt och begå sitt arbete som hon utvecklar. Nu, låt oss säga att James vill hjälpa Sarah med funktionen Kunddetaljer, så han börjar arbeta med detaljerna.

James skulle dra den sista versionen av den delade grenen och skapa en ny filial för användarhistorien "Radera-detaljer". Då kan han börja göra sina egna tillägg utan att oroa sig för att skriva över Sarahs kod.

 GIT-kassettfunktion / kunduppgifter
Git Pull Ursprung / Funktion / Kunduppgifter
Git Checkout -B Delete-Detaljer 

Han kommer också att använda sin tillfälliga gren för att kosta lokalt och begå några ändringar. När Sarah har slutat sin funktion lokalt lägger hon biljetten till kodsöversyn. Hon skulle trycka sin kod till staginggrenen och öppna en pull-förfrågan med stagingmiljön.

// hon skjuter sin kod till staginggrenen
Git Push Origin Add-Detaljer
// hon öppnar en pull-förfrågan med stagingmiljön
Git Request-Pull Staging Add-Detaljer 

Vi skulle nu ha kundinformationsfunktionen filial och de två användarhistoriens funktionsgrenar i utveckling "tilläggsuppgifter" och "Radera-detaljer".

Sammanslagning

När hennes kod har granskats kan hon slå samman sin gren i staging. Biljetten är nu i valideringskolumnen och väntar på validering från ledningsutvecklaren.

 // hon får den sista versionen av staginggrenen
Git Checkout Staging & Amp; & amp; git pull ursprung / staging
Git Merge Add-Details & Amp; & amp; git tryck på ursprungsstagen
// hon bygger valideringsmiljön
// och ber produktägaren att validera 

När Sarahs arbete har validerats kan biljetten flyttas till den färdiga kolumnen. Hon kan slå samman sitt arbete i funktionsgrenen och starta en annan användarhistoria, som att radera kunduppgifter.

 // hon drar den senaste versionen av funktionsgrenen
GIT-kassettfunktion / kunduppgifter
Git Pull Origin-funktion / Kunduppgifter
Git Merge Add-Adress & Amp; & amp; Git Push Origin-funktion / Kunduppgifter 

När hela funktionen har validerats av både ledningsutvecklaren och klienten, kan Sarah sammanfoga funktionsgrenen till utveckling, eftersom den är redo att gå.

 // hon får den senaste versionen av den utvecklade grenen
Git Checkout Utveckla & Amp; & amp; git pull ursprung / utveckla
Git Merge Funktion / Kunduppgifter & Amp; & amp; GIT-tryck Ursprung Utveckla 

Distribuera till produktion

När allt är klart och det är klart att distribuera till produktion utvecklas James Fererges till frisläppande och lanserar utplaceringen. Vid denna tidpunkt skulle han veta att all kod är korrekt och kunden är glad. Han märker förbindelsen för utgåvan för att få historien om varje version.

 Git Checkout Utveckla & Amp; & amp; git pull ursprung / utveckla
Git Checkout Release & Amp; & amp; git pull ursprung / release
Git Merge utvecklas & amp; & amp; git tag 2.1
Git Push Origin Release --tags 

Regler att följa för detta arbetsflöde

Detta fjärrutvecklingsarbetsflöde kan vara ganska svårt att förstå först, men om du får ditt team att arbeta med den här metoden, har du ett gratis arbetsflöde utan att behöva panik om filer som skrivs över eller dina utvecklare som arbetar på samma område.

Det finns några viktiga saker att komma ihåg:

• Det första du behöver lära dig dina fjärrkontroller är ditt versionskontroll arbetsflöde och se till att de alla läser från samma bok.
• Om du utvecklar en funktion, försök att bryta ner detta i mindre användarberättelser. På så sätt är det lättare att hålla reda på varje begå.
• Missa inte några steg: samma arbetsflöde måste följas varje gång.
• Du måste alltid slå samman din filial i att utvecklas för att förbereda nästa utgåva.
• Du bör rengöra stagingförvaret varje vecka om möjligt. Du bör radera den staginggren, lokalt och på distans och återskapa den från att utveckla gren - se exempel nedan:

 Git Co utveckla & amp; & amp; git pull ursprung / utveckla
Git Branch -D-staging & amp; & amp; git push ursprung --delete staging
Git Co-b-staging & amp; & amp; git pull ursprungsstaging 

Ytterligare arbetsflöden

Med mindre projekt kanske du vill använda ett mindre komplext arbetsflöde. Du kan använda Master, som innehåller den mest aktuella versionen, en utvecklad gren och sedan en uppsättning grenar för varje ytterligare funktion - oavsett om det är forum, kontaktformulär, utcheckningssystem. Allt beror på din personliga preferens.

Hantera sammanfogade konflikter

Att hantera fusionskonflikter är svårt nog om du alla arbetar i samma rum men de kan bli ännu mer av en mardröm om du alla arbetar på ett annat kontor. Det viktigaste är att komma ihåg att du alltid kan ångra en sammanslagning och återvända tillbaka till staten innan konflikten inträffade.

Oavsett om du gör alla sammanslagningar som ledande utvecklare eller ditt lag är de som gör dem självständigt, är det första steget att förstå vad som hänt.

• Har en av dina medutvecklare rediger samma rad i samma fil?
• Tog de bort en fil som du ändrade?
• Ledde du båda en fil med samma namn?

Git kommer att berätta att du har Unmerged vägar via git status :

 $ git status
# På gren checkout-system
# Du har oanvända vägar.
# (fixa konflikter och kör "git commit")
#
# Unmerged vägar:
# (Använd "Git Add & Lt; File & GT; ..." för att markera upplösning)
#
# båda ändrade: checkout.html
#
Inga ändringar läggs till för att begå (använd "Git Lägg till" och / eller "Git Commit-A") 

Nu är den vanligaste orsaken till en konflikt när förändringar påverkar samma filer på samma linje. Så, låt oss ta en titt på innehållet i den konfliktade linjen. Du kommer att märka att Git är riktigt bra i det faktum att det kommer att markera det konfliktade området genom att bifoga det i & lt; & lt; & lt; & lt; och & GT; & GT; & GT; & GT; [Övrigt / Gren / Namn] . I det här fallet är det Kassa-system .

 & lt; & lt; & lt; & lt; & lt; HUVUD
Denna linje begicks under arbetet i filmen "User-Form".
=======
Denna linje, däremot, begicks under arbetet i filmen "Checkout-System".
& GT; & GT; & GT; & GT; & GT; Refs / Heads / Checkout-System 

Innehållet efter den första markören härrör från din nuvarande arbetsgren. Efter vinkelfästena berättar Git oss vilken gren som förändringarna kom ifrån. En linje med ======= separerar de två motstridiga förändringarna.

Du kan nu bara öppna filen i en redaktör, söka efter konfliktmarkörerna och göra några nödvändiga ändringar. När du är klar måste filen se ut som du vill att den ska titta eller alternativt, kan du berätta för Git att du helt enkelt ska gå med en av de redigerade versionerna, kallas vår eller deras .

 Git Checkout --ours Path / to / Conflict-File.html 

Det finns också många merge verktygsapplikationer som kan hjälpa till med detta. Kaleidoscope är en bra en för Mac.

Projekt och utfärdande

Det är lika viktigt som en ledande utvecklare att ha ett projekthanteringsverktyg för att hantera saker som uppgifter och buggar, särskilt när dina utvecklare inte är kontorsbaserade. Det finns många lösningar där ute, till exempel Zenhub och Asuna, men jag tror att Githubs inbyggda projekt och problemet är det bästa.

Du kan göra saker som att skapa ett nytt projekt, skapa brädor eller tilldela problem. Och förvirra inte bara problem med problem: Du kan också använda den för förbättringar, frågor och buggar, bland annat.

Här är några av de bästa egenskaperna:

• Inbyggt märkningssystem: Gör det möjligt att organisera och prioritera ditt arbetsflöde och enkelt söka igenom projekt för relevant information.
• Milstolpar: Perfekt för att associera problem med specifika funktioner eller projektfaser, till exempel buggar som måste lösas innan en beta-lansering eller uppgifter som ska slutföras i oktober.
• Multi-uppdrag: Frågor kan tilldelas användare i bulk, vilket sparar tid och gör dig effektivare.
• Kommentera: Ingenjörer och ledningsgrupper kan enkelt diskutera framsteg och resultat vid varje steg på vägen med det inbyggda kommentarsystemet.
• Uppgiftslistor: Större problem kan delas upp i steg för att avskräcka skapandet av dussintals mikroskopiska problem, hålla allt ditt arbete på samma plats.
• MarkDown-format: Möjligheten att använda markdown-formatering kommer att vara populär med dina utvecklare och den kan användas på de flesta platser runt GitHub.
• Projektbrädor: Dessa kan användas för att hysa problem, dra förfrågningar och anteckningar, kategorisera dem som kort i kolumner om du väljer så att du kan titta på större projekt som helhet.
• Hög säkerhet: Du kan lita på GitHub för att hålla dina data säkra och det är svårare att bryta mot de flesta andra projektledningssystem.

Ställa in ett projekt

Om du går till GitHub och sedan går till en av dina repositories, kommer du att se en flik som kallas projekt. Därifrån kan du välja ett nytt projekt, ställa in dina projektuppgifter och skapa en ny projektmall.

Om du nu väljer fliken Problem som ligger längst upp och väljer ny fråga, kommer du att kunna skapa en ny fråga. Du kan sedan tillämpa olika etiketter - det här är saker som bugg, förbättring, fråga och dubbletter. Du kan också använda förbättring för en ny funktion eller ett begäran. Du kan sedan tilldela olika lagmedlemmar till uppgiften, en milstolpe och det projekt du just skapat.

Tilldelade medlemmar kommer då att ha en lista över alla sina uppgifter och du kan även använda projektbrädet för att hålla ett spår av vad som för närvarande byggs. Om du kommer ihåg vår tidigare handledning, pratade vi om att flytta biljetter till Sprint-backlog och validering. Så Github fungerar väldigt bra som ett allt-i-ett-verktyg för att övervaka ett projekt.

Denna artikel publicerades ursprungligen i utgåva 311 av netto , världens bästsäljande tidning för webbdesigners och utvecklare. Köp utgåva 311 här eller prenumerera här .

Relaterade artiklar:

• Hur man lyckas som frilansutvecklare
• Utveckla återanvändbara reaktionskomponenter
• 4 tips för att utveckla dina utvecklare färdigheter