Hva er git og hvorfor du bør bruke versjonskontroll hvis du er en utvikler

Annonse

Som webutviklere, mye av tiden vi pleier å jobbe med lokale utviklingsnettsteder, er det bare å laste opp alt når vi er ferdige. Dette er bra når det bare er deg og endringene er små, men når du har å gjøre med mer enn ett person som jobber med noe, eller på et stort prosjekt med mange kompliserte komponenter, det er rett og slett ikke gjennomførbart. Det er da vi henvender oss til noe som heter versjonskontroll.

I dag skal jeg snakke om en open source versjonskontrollprogramvare kalt Git. Dette gjør at mer enn en person trygt kan jobbe med det samme prosjektet uten å forstyrre hverandre, men det er så mye mer enn det også.

Hvorfor bruke versjonskontroll programvare?

Først og fremst skal navnet gi det bort. Programvareversjonskontroll lar deg ha "versjoner" av et prosjekt, som viser endringene som ble gjort i koden over tid, og lar deg spore om nødvendig og angre endringene. Denne muligheten alene - å kunne sammenligne to versjoner eller reversere endringer, gjør det ganske uvurderlig når du jobber med større prosjekter.

Du har sannsynligvis til og med gjort dette selv på et tidspunkt og lagret 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 på en versjon, for å gjøre den samme som neste versjon. Med en utvikler er dette tilstrekkelig.

Men hva hvis 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 standarden i lang tid, der alle versjoner er lagret på en sentral server, og individuelle utviklere sjekker og laster opp endringer tilbake til denne serveren. Hvis du noen gang har sett på redigeringshistorikken på en Wikipedia-side, har du en god ide om hvordan dette fungerer i et virkelighetsnært scenario:

Fordelene med et system som dette er at flere utviklere kan gjøre endringer, og hver endring kan tilskrives en bestemt utvikler. På den ulempen betyr det at alt er lagret i en ekstern database, ingen endringer kan gjøres når den serveren går ned; og hvis den sentrale databasen er tapt, har hver klient bare den gjeldende versjonen av hva de arbeidet med.

Det tar oss videre til Git, og andre såkalte distribuerte versjonsstyringssystemer. I disse systemene sjekker ikke klienter bare den gjeldende versjonen av filene og jobber fra dem - de speiler hele versjonshistorikken. Hver utvikler har alltid en komplett kopi av alt. En sentral server brukes fortsatt, men skulle det verste skje, kan alt fortsatt gjenopprettes fra noen av klientene som har de nyeste versjonene.

Git fungerer spesielt ved å ta “øyeblikksbilder” av filer; Hvis filer forblir uendret i en bestemt versjon, kobler de ganske enkelt til de forrige filene - dette holder alt raskt og magert.

Det kan også interessere deg å lære at Git brukes til å administrere og utvikle core Linux-kjernen - den grunnleggende byggesteinen som alle linux-distros er bygget på.

Hva er Github?

Selv om du kan kjøre din egen Git-server lokalt, GitHub er både en ekstern server, et fellesskap av utviklere og et grafisk nettgrensesnitt for å administrere ditt Git-prosjekt. Det er gratis å bruke for opptil 5 offentlige depoter - det vil si når noen kan se eller gaffle koden din - med lave kostnadsplaner for private prosjekter. Jeg anbefaler på det sterkeste at du melder deg på en gratis konto, slik at du kan begynne å leke med dine egne prosjekter eller smi noen andre.

Gaffel og forgrening

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

Du har sannsynligvis hørt arbeidet "gaffel" når du arbeider med linux distros. Hvis du er kjent med mediasenter-appen Plex, vil du vite at den opprinnelig var en gaffel med den samme open source Xbox Media Center Aeon Nox 3.5: vakkert og tilpassbart tema for XBMCSett opp mediesenteret akkurat slik du vil ha det. Aeon Nox 3.5 er den siste versjonen av det som kanskje er det beste temaet for XBMC, og det er en sjelden kombinasjon: vakker ... Les mer . Dette betyr ganske enkelt at noen utviklere på et tidspunkt i fortiden tok koden til XBMC, og bestemte seg for å gå sine egne veier med det; det ble Plex.

Dette er selvfølgelig helt tillatt når prosjektet er åpen kildekode - du kan ta koden, gjøre hva du vil med den. Med Git, hvis du føler at endringene dine er gode nok til å bli rullet tilbake til “master” -prosjektet, da kan sende en "pull-forespørsel" til forfatteren og be dem om å trekke endringene tilbake til originalen prosjekt. Dette lar deg ha hundretusener av utviklere som jobber med et prosjekt når som helst, ingen av dem må godkjennes nødvendigvis for kodetilgang - de bare kopierer koden, gjør endringer og ber om å bli rullet tilbake til herre. Det er selvfølgelig opp til eieren av det originale prosjektet om de bestemmer seg for å godta endringene dine eller ikke.

Grening er noe som gjøres internt i et prosjekt av autoriserte utviklere. Det lar deg enkelt skille spesifikke problemer eller funksjoner, og jobbe med dem uten å ødelegge hovedfilene. Når du er fornøyd med at filialen din har taklet problemet, fletter du det tilbake til masteren. Når som helst kan det være så mange grener du vil; de forstyrrer ikke hverandre. Du kan også slå sammen endringer mellom grener uten å berøre masteren.

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

Neste gang skal vi se på hvordan du setter opp et fungerende Git-eksempel og gjør kodeendringer i grener. Versjonskontroll er et enormt tema. Jeg har bare gitt den korteste oversikten her, men som en utvikler som er vant til bare å gjøre endringer og angre dem hvis de ikke fungerer, har hele konseptet sprengt tankene mine - jeg håper det gjør ditt også.

Er du en erfaren utvikler med erfaring fra Git? Kommer du bare i gang og tror du vil ta en tur? Lyd av i kommentarene!