Wat is Git en waarom je versiebeheer moet gebruiken als je een ontwikkelaar bent

Als webontwikkelaars werken we vaak vaak op lokale ontwikkelsites en uploaden we vervolgens alles wanneer we klaar zijn. Dit is prima als je alleen bent en de wijzigingen zijn klein, maar als je te maken hebt met meer dan één persoon die ergens aan werkt, of aan een groot project met veel gecompliceerde componenten, is dat gewoon niet haalbaar. Dat is wanneer we ons wenden tot iets genaamd versiebeheer.

Vandaag zal ik het hebben over een open source versiecontrolesoftware genaamd Git. Hierdoor kunnen meer dan één persoon veilig aan hetzelfde project werken zonder zich met elkaar te bemoeien, maar het is ook zoveel meer dan dat.

Waarom Versiebeheersoftware gebruiken?

Eerst en vooral moet de naam het weggeven. Versiebeheer software staat je toe om te hebben “versies” van een project, dat de wijzigingen toont die in de loop van de tijd aan de code zijn aangebracht, en waarmee u zo nodig kunt teruggaan en die wijzigingen ongedaan kunt maken. Alleen al deze mogelijkheid - van het kunnen vergelijken van twee versies of het omkeren van veranderingen, maakt het van onschatbare waarde bij het werken aan grotere projecten.

Je hebt dit waarschijnlijk zelfs op een gegeven moment zelf gedaan, waarbij je kopieën van een project op verschillende punten hebt bewaard, zodat je een back-up hebt. In een versiecontrolesysteem zouden alleen de wijzigingen worden opgeslagen - een patchbestand dat op één versie zou kunnen worden toegepast om het hetzelfde te maken als de volgende versie. Met één ontwikkelaar is dit voldoende.

Maar wat als je meer dan één ontwikkelaar aan een project hebt laten werken? Dat is het idee van een gecentraliseerde versiecontroleserver. Deze zijn al lang de standaard, waarbij alle versies op een centrale server worden opgeslagen en individuele ontwikkelaars uitchecken en wijzigingen uploaden naar deze server. Als je ooit naar de bewerkingsgeschiedenis van een Wikipedia-pagina hebt gekeken, heb je een goed idee hoe dit werkt in een scenario in de echte wereld:

De voordelen van een dergelijk systeem zijn dat meerdere ontwikkelaars wijzigingen kunnen aanbrengen en dat elke wijziging vervolgens kan worden toegeschreven aan een specifieke ontwikkelaar. Aan de andere kant betekent het feit dat alles op een externe database is opgeslagen, dat er geen wijzigingen kunnen worden aangebracht wanneer die server uitvalt; en als de centrale database verloren is gegaan, heeft elke client alleen de huidige versie van alles waar ze aan werkten.

Dat brengt ons naar Git en andere zogenaamde gedistribueerde versiecontrolesystemen. In deze systemen controleren klanten niet alleen de huidige versie van de bestanden en werken ze ook - ze weerspiegelen de volledige versiegeschiedenis. Elke ontwikkelaar heeft altijd een volledige kopie van alles. Een centrale server wordt nog steeds gebruikt, maar mocht het ergste gebeuren, dan kan alles nog worden hersteld van alle clients met de nieuwste versies.

Git werkt specifiek door te nemen “snapshots” van bestanden; als bestanden in een bepaalde versie ongewijzigd blijven, is het eenvoudig gekoppeld aan de vorige bestanden - dit houdt alles snel en overzichtelijk.

Het kan je ook interesseren om te leren dat Git wordt gebruikt voor het beheren en ontwikkelen van de kern linux kernel - de basisbouwsteen waarop alle linux distro's worden gebouwd.

Wat is Github?

Hoewel u uw eigen Git-server lokaal kunt uitvoeren, is Github zowel een externe server, een community van ontwikkelaars en een grafische webinterface voor het beheer van uw Git-project. Het is gratis te gebruiken voor maximaal 5 openbare archieven - dat wil zeggen wanneer iemand uw code kan bekijken of aftakken - met goedkope plannen voor privéprojecten. Ik raad je ten sterkste aan om je aan te melden voor een gratis account, zodat je kunt beginnen met rond te kijken met je eigen projecten of iemand anders te vragen.

Forking & vertakking

Dit zijn kernbegrippen voor de Git-ervaring, dus laten we een moment nemen om het verschil uit te leggen.

U hebt waarschijnlijk het werk gehoord “vork” bij het omgaan met Linux Distro's. Als je bekend bent met de mediacentrum-app Plex, weet je dat het oorspronkelijk een vork was van de vergelijkbare open source Xbox Media Center Aeon Nox 3.5: mooi en aanpasbaar thema voor XBMC Aeon Nox 3.5: mooi en aanpasbaar thema voor XBMC-set uw mediacentrum precies zoals u het wilt. Aeon Nox 3.5 is de meest recente versie van wat misschien wel het beste thema is voor XBMC, en het is een zeldzame combinatie: prachtige ... Lees meer. Dit betekent simpelweg dat sommige ontwikkelaars ooit de code van XBMC hebben gebruikt en besloten hun eigen weg te gaan; dat werd Plex.

Dit is natuurlijk volledig toegestaan ​​als het project open source is - je kunt de code gebruiken, ermee doen wat je wilt. Met Git, als je voelt dat je veranderingen goed genoeg zijn om terug in de “meester” project, kunt u een maken “trek aanvraag” aan de auteur, met het verzoek om uw wijzigingen terug te brengen in hun oorspronkelijke project. Op deze manier kun je op elk moment honderdduizenden ontwikkelaars aan een project laten werken, die geen van allen moeten worden goedgekeurd voor codetoegang. Ze kopiëren de code, brengen wijzigingen aan en vragen om teruggestuurd te worden naar de master. Het is natuurlijk aan de eigenaar van het oorspronkelijke project als ze besluiten uw wijzigingen te accepteren of niet.

Vertakking is iets dat intern door een projectontwikkelaar wordt gedaan door geautoriseerde ontwikkelaars. Hiermee kunt u eenvoudig specifieke problemen of functies scheiden en eraan werken zonder de hoofdbestanden te verbreken. Als je eenmaal zeker weet dat je branche het probleem heeft opgelost, voeg je het opnieuw in de master. Op elk moment kunnen er zoveel takken zijn als je wilt; ze interfereren niet met elkaar. U kunt ook wijzigingen tussen branches samenvoegen zonder de master aan te raken.

Hier is een geweldig diagram van een voorbeeldworkflow van Vincent Driessen:

De volgende keer zullen we bekijken hoe een werkend Git-voorbeeld kan worden opgezet en binnen de branches wijzigingen in de code kunnen worden doorgevoerd. Versiebeheer is een enorm onderwerp. Ik heb hier alleen het kortste overzicht gegeven, maar als een ontwikkelaar die gewend is om gewoon veranderingen aan te brengen en ze ongedaan te maken als ze niet werken, is het hele concept in me opgekomen - ik hoop dat het ook van jou is.

Ben je een ervaren ontwikkelaar met ervaring in Git? Ben je net begonnen en denk je dat je het wilt proberen? Geluid uit in de reacties!

Meer informatie over: Programmeren, Projectbeheer, Webontwikkeling.