Šis straipsnis supažindina jus su „Git“, įskaitant tai, kaip įdiegti reikiamą programinę įrangą, kad galėtumėte pasiekti „Git“ serverius, kuriuose bus saugomas jūsų programinės įrangos projektas.
Versijų valdymo sąvokos
Norint suprasti „Git“ ir versijų valdymo sampratą, naudinga pažvelgti į versijų valdymą iš istorinės perspektyvos. Buvo trys versijų valdymo programinės įrangos kartos.
Pirmoji karta
Pirmoji karta buvo labai paprasta. Kūrėjai dirbo toje pačioje fizinėje sistemoje ir „patikrino“ po vieną failą.
Šios versijos programinės įrangos versijos karta naudojo vadinamąją techniką failų užrakinimas. Kai kūrėjas patikrino failą, jis buvo užrakintas, todėl joks kitas kūrėjas negalėjo redaguoti failo.
Pirmosios kartos versijų valdymo programinės įrangos pavyzdžiai yra „Revision Control System“ (RCS) ir „Source Code Control System“ (SCCS).
Antroji karta
Pirmosios kartos problemos buvo šios:
Vienu metu prie failo galėjo dirbti tik vienas kūrėjas. Tai sukėlė kliūčių kūrimo procese.
Kūrėjai turėjo prisijungti tiesiai prie sistemos, kurioje buvo versijų valdymo programinė įranga.
Šios problemos buvo išspręstos antrosios versijos valdymo programinės įrangos kartoje. Antros kartos failai saugomi centralizuotame serveryje, saugykloje. Kūrėjai gali patikrinti atskiras failo kopijas. Kai kūrėjas baigia darbą su failu, failas patikrinamas saugykloje.
Jei du kūrėjai patikrina tą pačią failo versiją, gali kilti problemų. Tai tvarko procesas, vadinamas a sujungti.
Kas yra sujungimas? Tarkime, kad du kūrėjai, Bobas ir Sue'as, patikrina pavadinto failo 5 versiją abc.txt. Baigęs darbą, Bobas patikrina failą. Paprastai tai suteikia naują failo versiją, 6 versiją.
Kažkada vėliau Sue patikrina savo bylą. Šiame naujame faile turi būti jos ir Bobo pakeitimai. Tai pasiekiama per susijungimo procesą.
Priklausomai nuo naudojamos versijos valdymo programinės įrangos, gali būti skirtingi būdai, kaip valdyti šį sujungimą. Kai kuriais atvejais, pavyzdžiui, kai Bobas ir Sue'as dirbo su visiškai skirtingomis failo dalimis, suliejimo procesas yra labai paprastas. Tačiau tais atvejais, kai Sue ir Bobas faile dirbo tomis pačiomis kodo eilutėmis, suliejimo procesas gali būti sudėtingesnis. Tokiais atvejais Sue turės priimti sprendimus, pavyzdžiui, ar Bobo kodas, ar jos kodas bus naujoje failo versijoje.
Baigus sujungimo procesą, failas perduodamas į saugyklą. Priskirti failą iš esmės reiškia sukurti naują versiją saugykloje; šiuo atveju - bylos 7 versija.
Antrosios kartos versijų valdymo programinės įrangos pavyzdžiai yra „Concurrent Versions System“ (CVS) ir „Subversion“.
Trečia karta
Trečioji karta vadinama paskirstytosiomis versijų valdymo sistemomis (DVCS). Kaip ir antrosios kartos atveju, centriniame saugyklos serveryje yra visi projekto failai. Tačiau kūrėjai netikrina atskirų failų iš saugyklos. Vietoj to, patikrinamas visas projektas, leidžiantis kūrėjui dirbti su visu failų rinkiniu, o ne tik su atskirais failais.
Kitas (labai didelis) skirtumas tarp antrosios ir trečiosios versijos valdymo programinės įrangos kartos yra susijęs su tuo, kaip veikia sujungimo ir vykdymo procesas. Kaip minėta anksčiau, antrosios kartos veiksmai yra atlikti sujungimą ir paskui priskirti naują versiją saugyklai.
Naudojant trečiosios kartos versijų valdymo programinę įrangą, failai yra tikrinami ir sujungiami.
Pavyzdžiui, tarkime, kad du kūrėjai patikrina failą, pagrįstą trečiąja versija. Jei vienas kūrėjas patikrina tą failą ir pateikia 4 failo versiją, antrasis kūrėjas pirmiausia turi sujungti pakeitimus iš savo patikrintos kopijos su 4 versijos (ir, galbūt, kitų versijų) pakeitimais. Baigus sujungimą, naująją versiją galima priskirti saugyklai kaip 5 versiją.
Jei sutelksite dėmesį į tai, kas yra saugykloje (kiekvienos fazės centrinė dalis), pamatysite, kad yra labai tiesi vystymosi linija (ver1, ver2, ver3, ver4, ver5 ir kt.). Šis paprastas požiūris į programinės įrangos kūrimą kelia keletą galimų problemų:
- Reikalavimas, kad kūrėjas sujungtų prieš įsipareigojimą, dažnai lemia tai, kad kūrėjai nenori reguliariai atlikti pakeitimų. Sujungimo procesas gali būti skaudus ir kūrėjai gali nuspręsti tiesiog palaukti vėlesnio laiko ir atlikti vieną sujungimą, o ne reguliarų sujungimą. Tai daro neigiamą poveikį programinės įrangos plėtrai, nes staiga į failą įtraukiami didžiuliai kodo gabalai. Be to, jūs norite paskatinti kūrėjus atlikti pakeitimus saugykloje, kaip ir norėdami paskatinti dokumentą rašantį asmenį reguliariai taupyti.
- Labai svarbu: šio pavyzdžio 5 versija nebūtinai yra kūrėjo iš pradžių atliktas darbas. Sujungimo proceso metu kūrėjas gali išmesti dalį savo darbo, kad užbaigtų sujungimo procesą. Tai nėra idealu, nes prarandamas potencialiai geras kodas.
Galima naudoti geresnę, nors neabejotinai sudėtingesnę, techniką. Tai vadinama nukreiptas aciklinis grafikas (DAG).
Vaizduokite tą patį scenarijų kaip ir anksčiau, kai du kūrėjai patikrina failo 3 versiją. Jei vienas kūrėjas patikrina tą failą, vis tiek pateikiama 4 failo versija. Tačiau antrojo registracijos proceso metu gaunamas 5 versijos failas, kuris nėra pagrįstas 4 versija, o nepriklauso nuo 4 versijos. Kitame proceso etape failo 4 ir 5 versijos sujungiamos, kad būtų sukurta versija 6.
Nors šis procesas yra sudėtingesnis (ir, galbūt, daug sudėtingesnis, jei turite daug kūrėjų), jis teikia tam tikrų pranašumų prieš vieną kūrimo liniją:
- Kūrėjai gali atlikti savo pakeitimus reguliariai ir neturi jaudintis dėl sujungimo tik vėliau.
- Sujungimo procesą galima pavesti konkrečiam kūrėjui, kuris geriau supranta visą projektą ar kodą nei kiti kūrėjai.
- Bet kuriuo metu projekto vadovas gali grįžti atgal ir tiksliai pamatyti, kokį darbą sukūrė kiekvienas individualus kūrėjas.
Be abejo, egzistuoja argumentas dėl abiejų metodų. Tačiau nepamirškite, kad šiame straipsnyje daugiausia dėmesio skiriama „Git“, kuriame naudojamas trečiosios kartos versijų valdymo sistemų nukreipto aciklinio grafo metodas.
Diegiama „Git“
Jūsų sistemoje jau gali būti „Git“, nes ji pagal numatytuosius nustatymus kartais yra įdiegta (arba gali būti, kad ją įdiegė kitas administratorius). Jei turite prieigą prie sistemos kaip įprastas vartotojas, galite atlikti šią komandą, kad nustatytumėte, ar įdiegėte „Git“:
ocs @ ubuntu: ~ $ kuri git / usr / bin / git
Jei įdiegta „Git“, kelias į git pateikiama komanda, kaip parodyta ankstesnėje komandoje. Jei jis nėra įdiegtas, tada negaunate išvesties arba pateikiama tokia klaida:
[ocs @ centos ~] # kuri git / usr / bin / kuri: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)
Kaip „Debian“ sistemos administratorius, galite naudoti dpkg komandą nustatyti, ar „Git“ paketas įdiegtas:
root @ ubuntu: ~ # dpkg -l git Pageidaujamas = Nežinoma / Įdiegti / Pašalinti / Išvalyti / Laikyti | Būsena = Ne / Inst / Conf-failai / Išpakuota / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Err? = (Nėra) / Reikalinga pakartotinai (Status, Err: didžiosios = blogai) | | / Pavadinimas Versija Architektūros aprašymas +++ - ======== - ============= - ============= - === ===================================== ii git 1: 1.9.1-1ubun amd64 greita, keičiama , platinamas isionperžiūros kon
Kaip „Red Hat“ pagrįstos sistemos administratorius, galite naudoti aps./min komanda nustatyti, ar „git“ paketas buvo įdiegtas:
[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64
Jei „Git“ nėra įdiegta jūsų sistemoje, turite prisijungti kaip pagrindinis vartotojas arba naudoti sudo arba su įdiegti programinę įrangą. Jei esate prisijungę kaip pagrindinis vartotojas „Debian“ sistemoje, galite naudoti šią komandą, kad įdiegtumėte „Git“:
apt-get install git
Jei esate prisijungę kaip pagrindinis vartotojas sistemoje „Red Hat“ pagrįstoje sistemoje, galite naudoti šią komandą, kad įdiegtumėte „Git“:
yum install git
Gaukite daugiau nei Git
Apsvarstykite galimybę įdiegti programinės įrangos paketą git-viskas. Šiame pakete yra keletas papildomų priklausomybės paketų, kurie suteikia daugiau galios „Git“. Nors iš pradžių galbūt nenaudosite šių funkcijų, bus gera jas turėti, kai būsite pasirengę atlikti pažangesnes „Git“ funkcijas.
Gito sąvokos ir ypatybės
Vienas iš iššūkių naudojant „Git“ yra tiesiog suprasti jo sąvokas. Jei nesuprantate sąvokų, visos komandos atrodo tik kaip tam tikra juodoji magija. Šiame skyriuje daugiausia dėmesio skiriama kritinėms „Git“ sąvokoms, taip pat supažindinama su kai kuriomis pagrindinėmis komandomis.
Git etapai
Labai svarbu nepamiršti, kad jūs patikrinote visą projektą ir kad didžioji dalis jūsų atliekamo darbo bus vietos sistemai, prie kurios dirbate. Failai, kuriuos patikrinsite, bus patalpinti į katalogą, esantį jūsų namų kataloge.
Norėdami gauti projekto kopiją iš „Git“ saugyklos, naudokite procesą, vadinamą klonavimas. Klonavimas sukuria ne tik visų failų kopijas iš saugyklos; jis iš tikrųjų atlieka tris pagrindines funkcijas:
- Sukuria vietinę projekto saugyklą pagal projekto pavadinimas/.git katalogas jūsų namų kataloge. Laikoma, kad šioje vietoje esančio projekto failai yra patikrinti iš centrinės saugyklos.
- Sukuria katalogą, kuriame galite tiesiogiai matyti failus. Tai vadinama darbo zona. Darbo srityje atlikti pakeitimai nėra valdomi iš karto.
- Sukuria sustojimo zoną. Parodymo sritis skirta failų pakeitimams saugoti prieš juos pervedant į vietinę saugyklą.
Tai reiškia, kad jei klonuotumėte projektą, pavadintą „Jacumba“, visas projektas būtų saugomas Jacumba / .git katalogą, esantį jūsų namų kataloge. Neturėtumėte bandyti jų tiesiogiai modifikuoti. Verčiau žiūrėkite tiesiai į ~ / Jacumba katalogas, norėdamas pamatyti projekto failus. Tai yra failai, kuriuos turėtumėte pakeisti.
Tarkime, kad pakeitėte failą, bet turite dirbti su kai kuriais kitais failais, kol buvote pasirengę atlikti pakeitimus vietinėje saugykloje. Tokiu atveju norėtumėte etapas failą, kurį baigėte dirbti. Tai paruoštų ją skirti vietos saugyklai.
Atlikę visus pakeitimus ir suformavę visus failus, paskirsite juos vietinei saugyklai.
Supraskite, kad įvykdę etapinius failus jie siunčiami tik į vietinę saugyklą. Tai reiškia, kad tik jūs turite prieigą prie atliktų pakeitimų. Naujų versijų tikrinimo į centrinę saugyklą procesas vadinamas a stumti.
„Git“ saugyklos prieglobos pasirinkimas
Pirma, gera žinia: Daugelis organizacijų teikia „Git“ prieglobą - šio rašymo metu yra daugiau nei dvi dešimtys pasirinkimų. Tai reiškia, kad galite pasirinkti iš daugybės variantų. Tai geros naujienos ... ir blogos naujienos.
Tai tik blogos naujienos, nes tai reiškia, kad tikrai reikia skirti šiek tiek laiko tyrinėjant priimančiųjų organizacijų privalumus ir trūkumus. Pavyzdžiui, dauguma neapmokestina pagrindinio prieglobos, bet už didelio masto projektus. Kai kurie teikia tik viešas saugyklas (visi gali matyti jūsų saugyklą), o kiti leidžia kurti privačias saugyklas. Reikia atsižvelgti į daugybę kitų funkcijų.
Viena iš funkcijų, kurios gali būti svarbios jūsų sąraše, yra žiniatinklio sąsaja. Nors sistemoje galite atlikti beveik visas saugyklos operacijas, galimybė atlikti kai kurias operacijas per žiniatinklio sąsają gali būti labai naudinga. Prieš pasirinkdami, ištirkite pateiktą sąsają.
Aš bent jau rekomenduoju apsvarstyti šiuos dalykus:
- //bitbucket.org
- //www.cloudforge.com
- //www.codebasehq.com
- //github.com
- //gitlab.com
Atkreipkite dėmesį, kad žemiau pateikiamiems pavyzdžiams pasirinkau Gitlab.com. Bet kuris iš ankstesniame sąraše esančių šeimininkų būtų dirbęs taip pat gerai; Pasirinkau „Gitlab.com“ vien dėl to, kad tai atsitiko mano paskutiniame „Git“ projekte.
„Git“ konfigūravimas
Dabar, kai peržengėte visą teoriją, atėjo laikas iš tikrųjų ką nors padaryti su „Git“. Šiame kitame skyriuje daroma prielaida:
- Įdiegėte
gitarbagit-viskasprograminės įrangos paketą jūsų sistemoje. - Sukūrėte „Git“ prieglobos paslaugos paskyrą.
Pirmas dalykas, kurį norite padaryti, yra atlikti pagrindinę sąranką. Kai atliksite įsipareigojimo operaciją, jūsų vardas ir el. Pašto adresas bus įtraukti į metaduomenis. Norėdami nustatyti šią informaciją, vykdykite šias komandas:
ocs @ ubuntu: ~ $ git config - pasaulinis vartotojo vardas "Bo Rothwell" ocs @ ubuntu: ~ $ git config - pasaulinis vartotojas. el. paštas "[email protected]"
Akivaizdu, kad jūs pakeisite „Bo Rothwell“ su savo vardu ir „[email protected]“ su savo el. pašto adresu. Kitas žingsnis - klonuoti savo projektą iš „Git“ prieglobos paslaugos. Atminkite, kad prieš klonuojant tik vienas failas yra vartotojo namų kataloge:
ocs @ ubuntu: ~ $ ls first.sh
Šie klonavo projektą, pavadintą „ocs“:
