Vad är Git och varför du bör använda Version Control Om du är utvecklare

Som webbutvecklare, lägger vi mycket tid på att arbeta på lokala utvecklingsplatser, så ladda bara upp allt när vi är klara. Det här är bra när det bara är du och förändringarna är små, men när du arbetar med mer än en person som arbetar på något, eller på ett stort projekt med många komplicerade komponenter, är det helt enkelt inte genomförbart. Det är då vi vänder oss till något som kallas versionsstyrning.

Idag ska jag prata om en öppen källkodsversionsprogramvara kallad Git. Detta gör att fler än en person kan arbeta säkert på samma projekt utan att störa varandra, men det är så mycket mer än det också.

Varför använda Version Control Software?

Först och främst bör namnet ge bort det. Versionskontrollprogrammet låter dig ha “versioner” av ett projekt, som visar de förändringar som gjordes i koden över tiden, och låter dig backtrack vid behov och ångra dessa ändringar. Denna förmåga ensam - att kunna jämföra två versioner eller omvända förändringar gör det relativt ovärderligt när man arbetar med större projekt.

Du har nog även gjort det själv på ett visst sätt och sparar kopior av ett projekt på olika punkter så att du har en säkerhetskopia. I ett versionsstyrningssystem skulle bara ändringarna sparas - en patchfil som skulle kunna tillämpas på en version för att göra det samma som nästa version. Med en utvecklare är detta tillräckligt.

Men vad händer om du har mer än en utvecklare som arbetar med ett projekt? Det är då tanken på en centraliserad versionskontrollservern kommer in. Dessa har varit standard under lång tid, varigenom alla versioner lagras på en central server, och individuella utvecklare checkar ut och laddar upp ändringar tillbaka till den här servern. Om du någonsin har tittat på redigeringshistoriken för en Wikipedia-sida får du en bra bild av hur det här fungerar i ett verkligt scenario:

Fördelarna med ett sådant system är att flera utvecklare kan göra ändringar, och varje ändring kan då tillskrivas en specifik utvecklare. På nackdelen är det faktum att allt lagras på en fjärransluten databas, att inga ändringar kan göras när den servern går ner. och om den centrala databasen går förlorad har varje klient bara den nuvarande versionen av vad de arbetade med.

Det tar oss vidare till Git och andra så kallade distribuerade versionsstyrsystem. I dessa system klarar kunderna inte bara den aktuella versionen av filerna och arbetar från dem - de speglar hela versionshistoriken. Varje utvecklare har alltid en fullständig kopia av allt. En central server används fortfarande, men ska det värsta hända, då kan allting återställas från någon av de klienter som har de senaste versionerna.

Git arbetar specifikt genom att ta “snapshots” av filer; Om filerna förblir oförändrade i en viss version länkar den bara till föregående filer - det håller allt snabbt och lutat.

Det kan också intressera dig att lära dig att Git används för att hantera och utveckla kärn Linux-kärnan - basbyggstenen där alla Linux distros är byggda.

Vad är Github?

Även om du kan köra din egen Git-server lokalt, är Github både en fjärrserver, ett utvecklingsgemenskap och ett grafiskt webbgränssnitt för hantering av ditt Git-projekt. Det är gratis att använda för upp till 5 offentliga repositorier - det vill säga när någon kan se eller förgaffla din kod - med låga kostnadsplaner för privata projekt. Jag föreslår starkt att du registrerar dig för ett gratis konto så att du kan börja leka med dina egna projekt eller förklara någon annan.

Forking & Branching

Dessa är kärnkoncept för Git-upplevelsen, så låt oss ta en stund för att förklara skillnaden.

Du har nog hört arbetet “gaffel” när man hanterar linux distros. Om du är bekant med Media Center App Plex, vet du att det var ursprungligen en gaffel av samma öppna källa Xbox Media Center Aeon Nox 3.5: Vackert och anpassningsbart tema för XBMC Aeon Nox 3.5: Vackert och anpassningsbart tema för XBMC-set Upp ditt mediacenter precis som du vill ha det. Aeon Nox 3.5 är den senaste versionen av det som kanske är det bästa temat för XBMC, och det är en sällsynt kombination: vacker ... Läs mer. Det innebär helt enkelt att vissa utvecklare vid något tillfälle tidigare tagit koden för XBMC och bestämde sig för att gå på egen väg med det. det blev Plex.

Detta är givetvis helt tillåtet när projektet är öppen källkod - du kan ta koden, göra vad du vill med det. Med Git, om du känner att dina ändringar är tillräckligt bra för att rulla tillbaka in i “bemästra” projekt, du kan göra en “dra förfrågan” till författaren, be dem att dra dina ändringar tillbaka till sitt ursprungliga projekt. Detta gör att du kan ha hundratusentals utvecklare som arbetar på ett projekt när som helst, ingen av dem måste nödvändigtvis godkännas för kodåtkomst - de kopierar bara koden, gör ändringar och begär att rulla tillbaka till mastern. Naturligtvis är det upp till ägaren till det ursprungliga projektet om de bestämmer sig för att acceptera dina ändringar eller ej.

Förgrening sker något internt på ett projekt av de auktoriserade utvecklarna. Det låter dig enkelt separera specifika problem eller funktioner och arbeta på dem utan att bryta huvudfilerna. När du väl är nöjd med att din filial har behandlat problemet, slår du tillbaka det i mästaren. Vid varje tillfälle kan det finnas så många grenar som du vill, de stör inte varandra. Du kan även slå samman förändringar mellan grenar utan att röra huvudet.

Här är ett bra diagram över ett exempel arbetsflöde av Vincent Driessen:

Nästa gång tittar vi på hur du skapar ett fungerande Git-exempel och gör kodändringar inom grenar. Versionskontroll är ett stort ämne. Jag har bara gett den kortaste översikten här, men som en utvecklare som är van vid att bara göra ändringar och ångra dem om de inte fungerar har hela konceptet blivit mitt hjärta - jag hoppas det gör din också.

Är du en erfaren utvecklare med erfarenhet av Git? Har du precis börjat och tror att du skulle vilja gå? Ljud av i kommentarerna!

Utforska mer om: Programmering, projektledning, webbutveckling.