Hva er Git og hvorfor du bør bruke Versjonskontroll Hvis du er utvikler

Som webutviklere har vi mye tid på å jobbe på lokale utviklingssteder, og laster så opp alt når vi er ferdige. Dette er greit når det bare er deg og endringene er små, men når du arbeider med mer enn én person som jobber med noe, eller på et stort prosjekt med mange kompliserte komponenter, er det bare ikke mulig. Det er da vi vender oss til noe som kalles versjonskontroll.

I dag snakker jeg om en åpen kildekode versjon programvare som heter Git. Dette gjør det mulig for flere enn en person å arbeide trygt på samme prosjekt uten å forstyrre hverandre, men det er så mye mer enn det også.

Hvorfor bruke Versjonskontrollprogramvare?

Først og fremst bør navnet gi det bort. Versjonskontrollprogramvaren lar deg ha “versjoner” av et prosjekt, som viser endringene som ble gjort til koden over tid, og lar deg tilbakestille om nødvendig og angre endringene. Denne muligheten alene - for å kunne sammenligne to versjoner eller omvendte endringer, gjør det ganske uvurderlig når man arbeider med større prosjekter.

Du har sikkert gjort dette selv på et tidspunkt, og lagrer kopier av et prosjekt på forskjellige punkter, slik at du har en sikkerhetskopi. I et versjonskontrollsystem vil bare endringene bli lagret - en oppdateringsfil som kan brukes til en versjon for å gjøre det samme som den neste versjonen. Med en utvikler er dette tilstrekkelig.

Men hva om du har mer enn en utvikler som jobber med et prosjekt? Det er da ideen om en sentralisert versjonskontrollserver kommer inn. Disse har vært standard i lang tid, hvor alle versjoner lagres på en sentral server, og individuelle utviklere kasserer og laster opp endringer tilbake til denne serveren. Hvis du noen gang har sett på redigeringshistorikken til en Wikipedia-side, har du en god ide om hvordan dette virker i en ekte verdensscenario:

Fordelene ved et system som dette er at flere utviklere kan gjøre endringer, og hver endring kan da tilskrives en bestemt utvikler. På downside er det faktum at alt er lagret på en ekstern database, ingen endringer kan gjøres når den serveren går ned; og hvis den sentrale databasen går tapt, har hver klient bare den nåværende versjonen av hva de jobbet med.

Det tar oss videre til Git, og andre såkalte distribuert versjon kontrollsystemer. I disse systemene ser kundene ikke bare ut den gjeldende versjonen av filene og jobber fra dem - de speiler hele versjonsloggen. Hver utvikler har alltid en komplett kopi av alt. En sentral server brukes fortsatt, men hvis det verste skjer, kan alt fortsatt bli gjenopprettet fra noen av klientene som har de nyeste versjonene.

Git jobber spesielt ved å ta “snapshots” av filer; hvis filene forblir uendret i en bestemt versjon, kobler den bare til de forrige filene - dette holder alt raskt og lunt.

Det kan også være interessant for deg å lære at Git er brukt til å håndtere og utvikle kjernen Linux-kjernen - grunnblokken der alle Linux distros er bygget.

Hva er Github?

Selv om du kan kjøre din egen Git-server lokalt, er Github både en ekstern server, et fellesskap av utviklere og et grafisk webgrensesnitt for å administrere Git-prosjektet. Det er gratis å bruke for opptil 5 offentlige repositorier - det vil si når noen kan se eller gaffel koden din - med kostnadsfrie planer for private prosjekter. Jeg anbefaler sterkt at du registrerer deg for en gratis konto slik at du kan begynne å spille rundt med dine egne prosjekter eller forking noen elses.

Forking & Branching

Disse er kjernekonsepter til Git-opplevelsen, så la oss ta et øyeblikk for å forklare forskjellen.

Du har sikkert hørt arbeidet “gaffel” når det gjelder linux distros. Hvis du er kjent med Media Center App Plex, vet du at det opprinnelig var en gaffel av lignende åpen kildekode. Xbox Media Center Aeon Nox 3.5: Vakkert og tilpassbart tema for XBMC Aeon Nox 3.5: Vakkert og tilpassbart tema for XBMC-sett opp mediasenteret akkurat slik du vil ha det. Aeon Nox 3.5 er den nyeste versjonen av det som kanskje er det beste temaet for XBMC, og det er en sjelden kombinasjon: vakker ... Les mer. Dette innebærer ganske enkelt at noen utviklere på et tidspunkt i fortiden tok koden til XBMC, og bestemte seg for å gå sin egen vei med det; det ble Plex.

Dette er selvsagt helt tillatt når prosjektet er åpen kildekode - du kan ta koden, gjøre hva du vil med det. Med Git, hvis du føler at endringene dine er gode nok til å bli rullet tilbake i “herre” prosjekt, du kan lage en “trekk forespørsel” til forfatteren, be dem om å trekke endringene tilbake til deres opprinnelige prosjekt. Dette gjør at du kan ha hundrevis av tusenvis av utviklere som arbeider på et prosjekt når som helst, ingen av dem må nødvendigvis godkjennes for kodetilgang - de kopierer bare koden, gjør endringer og ber om å bli rullet tilbake til mesteren. Selvfølgelig er det opp til eieren av det opprinnelige prosjektet hvis de bestemmer seg for å godta endringene eller ikke.

Forgrening er noe gjort internt på et prosjekt av autoriserte utviklere. Det lar deg enkelt adskille bestemte problemer eller funksjoner, og jobbe på dem uten å bryte hovedfilene. Når du er fornøyd med at avdelingen har behandlet problemet, slår du det sammen igjen i mesteren. På noe tidspunkt kan det være så mange grener som du liker; de forstyrrer ikke hverandre. Du kan også slå sammen endringer mellom grener uten å berøre mesteren.

Her er et flott diagram over et eksempel på arbeidsflyt av Vincent Driessen:

Neste gang ser vi på hvordan du oppretter et fungerende Git-eksempel, og gjør kodeendringer innen grener. Versjonskontroll er et stort tema. Jeg har bare gitt den korteste oversikten her, men som en utvikler som er vant til å bare gjøre endringer og fortryde dem hvis de ikke virker, har hele konseptet blåst i sinnet - jeg håper det gjør din også.

Er du en erfaren utvikler med erfaring i Git? Har du nettopp kommet i gang og tror du vil ha en tur? Lyder av i kommentarene!

Utforsk mer om: Programmering, prosjektledelse, webutvikling.