Vad är git och varför du ska använda versionskontroll om du är en utvecklare

Annons

Som webbutvecklare, mycket av tiden vi tenderar att arbeta på lokala utvecklingswebbplatser bara ladda upp allt när vi är klara. Det går bra när det bara är dig och förändringarna är små, men när du har att göra med mer än en person som arbetar på något, eller på ett stort projekt med massor av komplicerade komponenter, det är helt enkelt inte möjlig. Det är när vi vänder oss till något som heter versionskontroll.

Idag kommer jag att prata om en öppen källkod för versionskontroll som heter Git. Detta tillåter mer än en person att säkert arbeta med samma projekt utan att störa varandra, men det är så mycket mer än så också.

Varför använda versionskontrollprogramvara?

Först och främst bör namnet ge bort det. Med programvaran för versionskontroll kan du ha ”versioner” av ett projekt, som visar de ändringar som gjordes i koden över tid, och gör att du kan backtracka vid behov och ångra dessa ändringar. Enbart denna förmåga - att kunna jämföra två versioner eller vända ändringar gör det ganska ovärderligt när man arbetar med större projekt.

Du har antagligen till och med gjort det själv vid någon tidpunkt och sparat kopior av ett projekt på olika punkter så att du har en säkerhetskopia. I ett versionskontrollsystem skulle bara ändringarna sparas - en patchfil som kan 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 på ett projekt? Det är när idén om en centraliserad versionskontrollserver kommer in. Dessa har varit standarden under lång tid, varigenom alla versioner lagras på en central server och individuella utvecklare checkar ut och laddar upp ändringar tillbaka till denna server. Om du någonsin har tittat på redigeringshistoriken på en Wikipedia-sida, har du en bra uppfattning om hur detta fungerar i ett verkligt scenario:

Fördelarna med ett system som detta är att flera utvecklare kan göra ändringar, och varje ändring kan sedan tillskrivas en specifik utvecklare. På nackdelen betyder det faktum att allt lagras i en fjärrdatabas inga förändringar kan göras när servern går ner; och om den centrala databasen går förlorad har varje klient bara den aktuella versionen av vad de arbetade med.

Det tar oss vidare till Git och andra så kallade distribuerade versionskontrollsystem. I dessa system tittar kunder inte bara på den aktuella versionen av filerna och fungerar från dem - de speglar hela versionens historik. Varje utvecklare har alltid en komplett kopia av allt. En central server används fortfarande, men om det värsta skulle hända kan allt fortfarande återställas från någon av de klienter som har de senaste versionerna.

Git fungerar specifikt genom att ta ”snapshots” av filer; om filer förblir oförändrade i en viss version, länkar de helt enkelt till de tidigare filerna - detta håller allt snabbt och mager.

Det kan också intressera dig att lära sig att Git används för att hantera och utveckla core Linux-kärna - basbyggnadsblocket på vilket alla linux-distros är byggda.

Vad är Github?

Även om du kan köra din egen Git-server lokalt, github är både en fjärrserver, en community av utvecklare och ett grafiskt webbgränssnitt för att hantera ditt Git-projekt. Det är gratis att använda för upp till 5 offentliga förvar - det vill säga när vem som helst kan visa eller gaffla 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 smyga någon annan.

Forking & Branching

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

Du har förmodligen hört arbetet "gaffel" när du hanterar linux-distros. Om du är bekant med mediacenter-appen Plex vet du att det ursprungligen var en gaffel av den likadana open source Xbox Media Center Aeon Nox 3.5: Vackert och anpassningsbart tema för XBMCStäll in ditt mediecenter precis som du vill ha det. Aeon Nox 3.5 är den senaste versionen av vad som kanske är det bästa temat för XBMC, och det är en sällsynt kombination: vacker ... Läs mer . Detta betyder helt enkelt att vissa utvecklare vid någon tidpunkt i det förflutna tog koden för XBMC och beslutade att gå sin egen väg med det; det blev Plex.

Detta är naturligtvis helt tillåtet när projektet är öppen källkod - du kan ta koden, göra vad du vill med den. Med Git, om du känner att dina förändringar är tillräckligt bra för att rullas tillbaka till "master" -projektet, du kan göra en "pull-begäran" till författaren och be dem att dra dina ändringar tillbaka till sina original projekt. Detta gör att du kan ha hundratusentals utvecklare som arbetar på ett projekt när som helst, varav ingen måste godkännas nödvändigtvis för kodåtkomst - de kopierar bara koden, gör ändringar och begär att rullas tillbaka till bemästra. Naturligtvis är det upp till ägaren till det ursprungliga projektet om de beslutar att acceptera dina ändringar eller inte.

Grenning är något som görs internt i ett projekt av auktoriserade utvecklare. Det låter dig enkelt separera specifika problem eller funktioner och arbeta med dem utan att bryta huvudfilerna. När du är nöjd med att din filial har hanterat problemet, slår du den tillbaka till befälhavaren. När som helst kan det finnas så många grenar som man vill; de stör inte varandra. Du kan också slå samman förändringar mellan grenar utan att beröra master.

Här är ett fantastiskt diagram över ett exempel på ett arbetsflöde av Vincent Driessen:

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

Är du en erfaren utvecklare med erfarenhet av Git? Kommer du bara att komma igång och tror att du vill gå? Ljud av i kommentarerna!