Git-opetusohjelma: Aloita Git-versionhallinta

Tämä artikkeli tutustuttaa sinut Gitiin, mukaan lukien tarvittavien ohjelmistojen asentaminen Git-palvelimille, joihin ohjelmistoprojektisi tallennetaan.

Versiohallinnan käsitteet

Gitin ja versionhallinnan käsitteen ymmärtäminen on hyödyllistä tarkastella versionhallintaa historiallisesta näkökulmasta. Versionhallintaohjelmistoja on ollut kolme sukupolvea.

Ensimmäinen sukupolvi

Ensimmäinen sukupolvi oli hyvin yksinkertainen. Kehittäjät työskentelivät samalla fyysisellä järjestelmällä ja "tarkistivat" yhden tiedoston kerrallaan.

Tämän versionhallintaohjelmiston sukupolvi käytti kutsuttua tekniikkaa tiedoston lukitus. Kun kehittäjä tarkisti tiedoston, se lukittiin, joten kukaan muu kehittäjä ei voinut muokata tiedostoa.

Esimerkkejä ensimmäisen sukupolven versionhallintaohjelmistoista ovat Revision Control System (RCS) ja Source Code Control System (SCCS).

Toinen sukupolvi

Ensimmäisen sukupolven ongelmat olivat seuraavat:

Vain yksi kehittäjä voi työskennellä tiedoston kanssa kerrallaan. Tämä johti pullonkaulaan kehitysprosessissa.
Kehittäjien oli kirjauduttava sisään suoraan järjestelmään, joka sisälsi versionhallintaohjelmiston.

Nämä ongelmat ratkaistiin toisen sukupolven versionhallintaohjelmistoilla. Toisessa sukupolvessa tiedostot tallennetaan keskitetylle palvelimelle arkistoon. Kehittäjät voivat tarkistaa erilliset kopiot tiedostosta. Kun kehittäjä on suorittanut tiedoston käsittelyn, tiedosto tarkistetaan arkistoon.

Jos kaksi kehittäjää tarkistaa tiedoston saman version, mahdollisuudet ongelmiin ovat olemassa. Tätä hoitaa prosessi nimeltä a yhdistää.

Mikä on yhdistäminen? Oletetaan, että kaksi kehittäjää, Bob ja Sue, tutustuvat nimetyn tiedoston versioon 5 abc.txt. Kun Bob on saanut työnsä päätökseen, hän tarkistaa tiedoston takaisin sisään. Tyypillisesti tuloksena on tiedoston uusi versio, versio 6.

Joskus myöhemmin Sue tarkistaa tiedostostaan. Tämän uuden tiedoston on sisällettävä hänen muutokset ja Bobin muutokset. Tämä toteutetaan yhdistämisprosessin avulla.

Käyttämästäsi versionhallintaohjelmistosta riippuen yhdistäminen voidaan käsitellä eri tavoin. Joissakin tapauksissa, kuten esimerkiksi silloin, kun Bob ja Sue ovat työskennelleet tiedoston eri osien parissa, yhdistämisprosessi on hyvin yksinkertainen. Tapauksissa, joissa Sue ja Bob työskentelivät samalla koodirivillä tiedostossa, yhdistämisprosessi voi olla monimutkaisempi. Tällöin Sue joutuu tekemään päätöksiä, esimerkiksi onko Bobin koodi vai hänen koodinsa tiedoston uudessa versiossa.

Kun yhdistämisprosessi on valmis, tapahtuu tiedoston sitouttaminen arkistoon. Tiedoston sitominen tarkoittaa olennaisesti uuden version luomista arkistoon; tässä tapauksessa tiedoston versio 7.

Esimerkkejä toisen sukupolven versionhallintaohjelmistoista ovat Concurrent Versions System (CVS) ja Subversion.

Kolmas sukupolvi

Kolmatta sukupolvea kutsutaan hajautetuksi versionhallintajärjestelmäksi (DVCS). Kuten toisen sukupolven kohdalla, myös keskusvarastopalvelin sisältää kaikki projektin tiedostot. Kehittäjät eivät kuitenkaan tarkista yksittäisiä tiedostoja arkistosta. Sen sijaan koko projekti tarkistetaan, jolloin kehittäjä voi työskennellä koko tiedostosarjan kanssa eikä vain yksittäisten tiedostojen kanssa.

Toinen (erittäin suuri) ero versionhallintaohjelmiston toisen ja kolmannen sukupolven välillä liittyy siihen, miten yhdistämis- ja sitoutumisprosessi toimii. Kuten aiemmin mainittiin, toisen sukupolven vaiheet ovat yhdistämisen suorittaminen ja sitten uuden version sitominen arkistoon.

Kolmannen sukupolven versionhallintaohjelmistolla tiedostot tarkistetaan ja yhdistetään.

Oletetaan esimerkiksi, että kaksi kehittäjää tarkistaa tiedoston, joka perustuu kolmanteen versioon. Jos yksi kehittäjä tarkistaa kyseisen tiedoston ja muodostaa tiedoston version 4, toisen kehittäjän on ensin yhdistettävä muutokset uloskirjautuneesta kopiosta version 4 (ja mahdollisesti muiden versioiden) muutoksiin. Kun yhdistäminen on valmis, uusi versio voidaan sitoa arkistoon versiona 5.

Jos keskityt siihen, mikä on arkistossa (kunkin vaiheen keskiosa), huomaat, että kehitys on hyvin suora (ver1, ver2, ver3, ver4, ver5 ja niin edelleen). Tämä yksinkertainen lähestymistapa ohjelmistokehitykseen aiheuttaa joitain mahdollisia ongelmia:

Kehittäjän vaatimus sulautumisesta ennen sitoutumista johtaa usein siihen, että kehittäjät eivät halua sitoutua muutoksiinsa säännöllisesti. Yhdistämisprosessi voi olla tuskaa, ja kehittäjät saattavat päättää vain odottaa myöhempään aikaan ja tehdä yhden yhdistämisen pikemminkin kuin joukko säännöllisiä fuusioita. Tällä on kielteinen vaikutus ohjelmistokehitykseen, kun tiedostoon lisätään yhtäkkiä valtavia koodipaloja. Lisäksi haluat kannustaa kehittäjiä tekemään muutoksia arkistoon, aivan kuten haluat kannustaa asiakirjaa kirjoittavaa henkilöä säästämään säännöllisesti.
Erittäin tärkeä: Tämän esimerkin versio 5 ei välttämättä ole työ, jonka kehittäjä alun perin suoritti. Yhdistämisen aikana kehittäjä saattaa hylätä osan työstään sulautusprosessin loppuun saattamiseksi. Tämä ei ole ihanteellinen, koska se johtaa mahdollisesti hyvän koodin menetykseen.

Parempaa, vaikkakin epäilemättä monimutkaisempaa tekniikkaa voidaan käyttää. Sitä kutsutaan suunnattu asyklinen kaavio (DAG).

Kuvaa samaa skenaariota kuin yllä, jossa kaksi kehittäjää tarkistaa tiedoston version 3. Jos yksi kehittäjä tarkistaa kyseisen tiedoston sisään, se johtaa silti tiedoston versioon 4. Toinen sisäänkirjautumisprosessi johtaa kuitenkin version 5 tiedostoon, joka ei perustu versioon 4, vaan pikemminkin versiosta 4. Prosessin seuraavassa vaiheessa tiedoston versiot 4 ja 5 yhdistetään version luomiseksi 6.

Vaikka tämä prosessi on monimutkaisempi (ja mahdollisesti paljon monimutkaisempi, jos sinulla on paljon kehittäjiä), se tarjoaa joitain etuja yhteen kehityslinjaan verrattuna:

Kehittäjät voivat sitoutua muutoksiinsa säännöllisesti, eikä heidän tarvitse huolehtia sulautumisesta vasta myöhemmin.
Yhdistämisprosessi voidaan delegoida tietylle kehittäjälle, jolla on parempi käsitys koko projektista tai koodista kuin muilla kehittäjillä.
Milloin tahansa, projektipäällikkö voi palata takaisin katsomaan tarkalleen, minkä työn kukin kehittäjä loi.

Varmasti argumentti on olemassa molemmille menetelmille. Muista kuitenkin, että tämä artikkeli keskittyy Gitiin, joka käyttää kolmannen sukupolven versionhallintajärjestelmien suunnattua asyklistä kaaviomenetelmää.

Gitin asentaminen

Sinulla saattaa olla jo Git järjestelmässäsi, koska se on joskus asennettu oletuksena (tai toinen järjestelmänvalvoja on saattanut asentaa sen). Jos sinulla on pääsy järjestelmään tavallisena käyttäjänä, voit suorittaa seuraavan komennon selvittääksesi, onko Git asennettu:

ocs @ ubuntu: ~ $ mikä git / usr / bin / git

Jos Git on asennettu, polku git komento tarjotaan edellisen komennon mukaisesti. Jos sitä ei ole asennettu, et joko saa tulostetta tai seuraavanlaista virhettä:

[ocs @ centos ~] # mikä git / usr / bin / mikä: ei git sisään (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)

Debian-pohjaisen järjestelmän järjestelmänvalvojana voit käyttää dpkg komento määrittää, onko Git-paketti asennettu:

root @ ubuntu: ~ # dpkg -l git Haluttu = Tuntematon / Asenna / Poista / Poista / Pidä | Tila = Ei / Inst / Conf-tiedostot / Pakkaamaton / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Err? = (Ei mitään) / Vaaditaan uudelleen (Tila, Err: isot kirjaimet = huonot) | | / Nimi Versio Arkkitehtuuri Kuvaus +++ - ======== - ============= - ============= - === ===================================== ii git 1: 1.9.1-1ubun amd64 nopea, skaalautuva , jaettu ➥revision con

Red Hat -pohjaisen järjestelmän järjestelmänvalvojana voit käyttää kierrosluku komento sen selvittämiseksi, onko git-paketti asennettu:

[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

Jos Git-sovellusta ei ole asennettu järjestelmään, sinun on joko kirjauduttava sisään pääkäyttäjänä tai käytettävä sudo tai su ohjelmiston asentamiseksi. Jos olet kirjautunut pääkäyttäjänä Debian-pohjaiseen järjestelmään, voit asentaa Gitin seuraavalla komennolla:

apt-get install git

Jos olet kirjautunut pääkäyttäjänä Red Hat -pohjaiseen järjestelmään, voit asentaa Gitin seuraavalla komennolla:

asenna git

Hanki enemmän kuin Git

Harkitse ohjelmistopaketin asentamista git-kaikki. Tämä paketti sisältää joitain lisäriippuvuuspaketteja, jotka lisäävät Gitin tehoa. Vaikka et ehkä käytä näitä ominaisuuksia alussa, on hyvä olla käytettävissä, kun olet valmis suorittamaan edistyneempiä Git-toimintoja.

Git-käsitteet ja ominaisuudet

Yksi Gitin käytön haasteista on vain sen taustalla olevien käsitteiden ymmärtäminen. Jos et ymmärrä käsitteitä, kaikki komennot näyttävät vain olevan jonkinlainen musta taika. Tämä osa keskittyy kriittisiin Git-käsitteisiin ja tutustuttaa sinut joihinkin peruskomentoihin.

Git-vaiheet

On erittäin tärkeää muistaa, että tarkistat koko projektin ja että suurin osa tekemäsi työstä on paikallista järjestelmälle, jota työskentelet. Tarkistamasi tiedostot sijoitetaan hakemistoon kotihakemistosi alla.

Voit hankkia kopion projektista Git-arkistosta käyttämällä prosessia nimeltä kloonaus. Kloonaus ei luo vain kopiota kaikista tiedostoista arkistosta; se tosiasiallisesti suorittaa kolme ensisijaista tehtävää:

Luo projektin paikallisen arkiston projektin nimi/.git-hakemisto kotihakemistossasi. Tässä paikassa olevien projektin tiedostojen katsotaan olevan tarkastettuja keskusrekisteristä.
Luo hakemiston, jossa voit nähdä tiedostot suoraan. Tätä kutsutaan työalue. Työalueella tehtyjä muutoksia ei voida välittömästi hallita versiolla.
Luo lavastusalueen. Vaihealue on suunniteltu tallentamaan tiedostojen muutokset ennen kuin annat ne paikalliseen arkistoon.

Tämä tarkoittaa, että jos haluat kloonata projektin nimeltä Jacumba, koko projekti tallennettaisiin Jacumba / .git kotihakemistosi alla. Sinun ei pitäisi yrittää muokata näitä suoraan. Sen sijaan, katso suoraan ~ / Jacumba hakemisto nähdäksesi projektin tiedostot. Nämä tiedostot kannattaa muuttaa.

Oletetaan, että teit muutoksen tiedostoon, mutta sinun on työskenneltävä joidenkin muiden tiedostojen kanssa, ennen kuin olit valmis tekemään muutoksia paikalliseen arkistoon. Siinä tapauksessa haluat vaiheessa tiedosto, jonka kanssa olet työskennellyt. Tämä valmistaisi sen sitoutumaan paikalliseen arkistoon.

Kun olet tehnyt kaikki muutokset ja lavastanut kaikki tiedostot, annat ne paikalliselle arkistolle.

Ymmärrä, että vaiheitettujen tiedostojen tekeminen lähettää ne vain paikalliseen arkistoon. Tämä tarkoittaa, että vain sinulla on pääsy tehtyihin muutoksiin. Uusien versioiden tarkistamista keskusrekisteriin kutsutaan nimellä a työntää.

Git-arkiston isännän valitseminen

Ensinnäkin hyvä uutinen: Monet organisaatiot tarjoavat Git-isännöinnin - tämän kirjoituksen aikaan on yli kaksi tusinaa valintoja. Tämä tarkoittaa, että sinulla on monia vaihtoehtoja. Se on hyvä uutinen ... ja huono uutinen.

Se on vain huono uutinen, koska se tarkoittaa, että sinun täytyy todella viettää aikaa tutkia isäntäorganisaatioiden etuja ja haittoja. Esimerkiksi useimmat eivät veloita peruspalvelusta, mutta veloittavat suurista projekteista. Jotkut tarjoavat vain julkisia arkistoja (kuka tahansa voi nähdä arkistosi), kun taas toiset antavat sinun luoda yksityisiä arkistoja. Huomioon on otettava monia muita ominaisuuksia.

Yksi ominaisuus, joka saattaa olla listallasi korkealla, on verkkoliittymä. Vaikka voit tehdä lähes kaikki arkistotoiminnot paikallisesti järjestelmässäsi, joidenkin toimintojen suorittaminen verkkoliitännän kautta voi olla erittäin hyödyllistä. Tutustu käyttöliittymään, joka on annettu ennen valintasi tekemistä.

Ainakin suosittelen harkitsemaan seuraavia asioita:

//bitbucket.org
//www.cloudforge.com
//www.codebasehq.com
//github.com
//gitlab.com

Huomaa, että valitsin alla olevista esimerkeistä Gitlab.com. Mikä tahansa edellisen luettelon isännistä olisi toiminut yhtä hyvin; Valitsin Gitlab.com yksinkertaisesti siksi, että sattui olemaan yksi, jota käytin viimeisessä Git-projektissani.

Gitin määrittäminen

Nyt kun olet käynyt läpi kaiken teorian, on aika tehdä jotain Gitin kanssa. Seuraavassa osassa oletetaan seuraavaa:

Olet asentanut git tai git-kaikki ohjelmistopaketti järjestelmässäsi.
Olet luonut tilin Git-hosting-palveluun.

Ensimmäinen asia, jonka haluat tehdä, on suorittaa perusasetukset. Aina kun teet sitoutumistoiminnon, nimesi ja sähköpostiosoitteesi sisällytetään metatietoihin. Määritä nämä tiedot suorittamalla seuraavat komennot:

ocs @ ubuntu: ~ $ git config --global user.name "Bo Rothwell" ocs @ ubuntu: ~ $ git config --global user.email "[email protected]"

Ilmeisesti korvaat "Bo Rothwell" nimesi kanssa "[email protected]" sähköpostiosoitteellasi. Seuraava vaihe on kloonata projekti Git-isännöintipalvelusta. Huomaa, että ennen kloonausta vain yksi tiedosto on käyttäjän kotihakemistossa: