Git apmācība: sāciet darbu ar Git versiju kontroli

Šis raksts iepazīstina jūs ar Git, tostarp to, kā instalēt nepieciešamo programmatūru, lai piekļūtu Git serveriem, kur tiks glabāts jūsu programmatūras projekts.

Versiju vadības koncepcijas

Lai saprastu Git un versiju vadības jēdzienu, ir noderīgi aplūkot versiju kontroli no vēsturiskā viedokļa. Ir bijušas trīs versiju kontroles programmatūras paaudzes.

Pirmā paaudze

Pirmā paaudze bija ļoti vienkārša. Izstrādātāji strādāja pie vienas un tās pašas fiziskās sistēmas un vienlaikus “pārbaudīja” vienu failu.

Šīs versijas vadības programmatūras paaudze izmantoja tehniku, ko sauc failu bloķēšana. Kad izstrādātājs pārbaudīja failu, tas tika bloķēts, tāpēc neviens cits izstrādātājs nevarēja rediģēt failu.

Pirmās paaudzes versiju kontroles programmatūras piemēri ir Revision Control System (RCS) un Source Code Control System (SCCS).

Otrā paaudze

Pirmās paaudzes problēmas bija šādas:

Vienlaikus ar failu varēja strādāt tikai viens izstrādātājs. Tā rezultātā radās sastrēgums izstrādes procesā.
Izstrādātājiem bija jāpiesakās tieši sistēmā, kas satur versiju kontroles programmatūru.

Šīs problēmas tika atrisinātas otrās paaudzes versiju kontroles programmatūrā. Otrajā paaudzē faili tiek glabāti centralizētā serverī krātuvē. Izstrādātāji var apskatīt atsevišķas faila kopijas. Kad izstrādātājs pabeidz darbu ar failu, fails tiek reģistrēts repozitorijā.

Ja divi izstrādātāji pārbauda vienu un to pašu faila versiju, pastāv problēmu iespējamība. To apstrādā process, ko sauc par a sapludināt.

Kas ir apvienošana? Pieņemsim, ka divi izstrādātāji, Bobs un Sjū, pārbauda faila 5. versiju ar nosaukumu abc.txt. Pēc tam, kad Bobs ir pabeidzis darbu, viņš atkal pārbauda failu. Parasti tā rezultātā tiek iegūta jauna faila versija - 6. versija.

Kādu laiku vēlāk Sjū pārbauda savu failu. Šajā jaunajā failā jāiekļauj viņas un Boba veiktās izmaiņas. Tas tiek panākts apvienošanās procesā.

Atkarībā no izmantotās versijas vadības programmatūras, var būt dažādi veidi, kā rīkoties ar šo apvienošanu. Dažos gadījumos, piemēram, kad Bobs un Sjū ir strādājuši pie pilnīgi atšķirīgām faila daļām, sapludināšanas process ir ļoti vienkāršs. Tomēr gadījumos, kad Sjū un Bobs failā strādāja ar vienām un tām pašām koda rindām, sapludināšanas process var būt sarežģītāks. Šādos gadījumos Sjū būs jāpieņem lēmumi, piemēram, vai Boba kods vai viņas kods būs faila jaunajā versijā.

Pēc apvienošanas procesa pabeigšanas notiek faila nodošanas krātuvei process. Saistīt failu būtībā nozīmē jaunas versijas izveidošanu repozitorijā; šajā gadījumā faila 7. versija.

Otrās paaudzes versiju kontroles programmatūras piemēri ietver vienlaicīgu versiju sistēmu (CVS) un Subversion.

Trešā paaudze

Trešā paaudze tiek saukta par izplatītajām versiju vadības sistēmām (DVCS). Tāpat kā otrās paaudzes gadījumā centrālā repozitorija serveris satur visus projekta failus. Tomēr izstrādātāji nepārbauda atsevišķus failus no krātuves. Tā vietā tiek pārbaudīts viss projekts, ļaujot izstrādātājam strādāt pie visa failu komplekta, nevis tikai ar atsevišķiem failiem.

Vēl viena (ļoti liela) atšķirība starp otrās un trešās paaudzes versiju kontroles programmatūru ir saistīta ar to, kā darbojas sapludināšanas un saistīšanas process. Kā jau minēts iepriekš, otrajā paaudzē ir jāveic apvienošana un pēc tam jaunās versijas piešķiršana repozitorijam.

Izmantojot trešās paaudzes versiju kontroles programmatūru, faili tiek reģistrēti un pēc tam tie tiek apvienoti.

Pieņemsim, ka divi izstrādātāji pārbauda failu, kura pamatā ir trešā versija. Ja viens izstrādātājs pārbauda šo failu, kā rezultātā tiek iegūta faila 4. versija, otrajam izstrādātājam vispirms ir jāapvieno izmaiņas no izrakstītās kopijas ar 4. versijas (un, iespējams, citu versiju) izmaiņām. Pēc apvienošanas pabeigšanas jauno versiju repozitorijam var piešķirt kā 5. versiju.

Ja koncentrējaties uz to, kas atrodas repozitorijā (katras fāzes centrālā daļa), redzat, ka pastāv ļoti taisna attīstības līnija (ver1, ver2, ver3, ver4, ver5 un tā tālāk). Šī vienkāršā pieeja programmatūras izstrādei rada dažas potenciālas problēmas:

Prasība izstrādātājam apvienoties pirms saistību uzņemšanās bieži noved pie tā, ka izstrādātāji nevēlas regulāri veikt izmaiņas. Apvienošanas process var sagādāt sāpes, un izstrādātāji var nolemt vienkārši pagaidīt vēlāk un veikt vienu apvienošanu, nevis kārtējo apvienošanu. Tas negatīvi ietekmē programmatūras izstrādi, jo pēkšņi failam tiek pievienoti milzīgi koda gabali. Turklāt jūs vēlaties iedrošināt izstrādātājus veikt izmaiņas krātuvē, tāpat kā mudināt kādu, kurš raksta dokumentu, regulāri saglabāt.
Ļoti svarīgi: 5. piemērs šajā piemērā ne vienmēr ir darbs, kuru izstrādātājs sākotnēji pabeidza. Apvienošanas procesā izstrādātājs var izmest daļu sava darba, lai pabeigtu apvienošanas procesu. Tas nav ideāli, jo tā rezultātā tiek zaudēts potenciāli labs kods.

Var izmantot labāku, lai arī neapšaubāmi sarežģītāku tehniku. To sauc par virzīts acikliskais grafiks (DAG).

Attēlojiet to pašu scenāriju kā iepriekš, kur divi izstrādātāji pārbauda faila 3. versiju. Ja viens izstrādātājs pārbauda šo failu, tā joprojām rada faila 4. versiju. Tomēr otrā reģistrēšanās procesa laikā tiek iegūts 5. versijas fails, kas nav balstīts uz 4. versiju, bet drīzāk neatkarīgs no 4. versijas. Nākamajā procesa posmā faila 4. un 5. versija tiek apvienota, lai izveidotu versiju. 6.

Lai gan šis process ir sarežģītāks (un, iespējams, daudz sarežģītāks, ja jums ir daudz izstrādātāju), tas tomēr sniedz dažas priekšrocības salīdzinājumā ar vienu attīstības līniju:

Izstrādātāji var veikt izmaiņas regulāri un nav jāuztraucas par apvienošanos tikai vēlāk.
Apvienošanas procesu varētu deleģēt konkrētam izstrādātājam, kuram ir labāka ideja par visu projektu vai kodu nekā citiem izstrādātājiem.
Jebkurā laikā projekta vadītājs var atgriezties un redzēt, tieši kādu darbu katrs individuālais izstrādātājs ir izveidojis.

Noteikti pastāv arguments par abām metodēm. Tomēr paturiet prātā, ka šajā rakstā galvenā uzmanība tiek pievērsta Git, kurā tiek izmantota trešās paaudzes versiju vadības sistēmu virzītā acikliskā grafa metode.

Git instalēšana

Iespējams, jūsu sistēmā jau ir Git, jo tā dažreiz tiek instalēta pēc noklusējuma (vai, iespējams, to ir instalējis cits administrators). Ja jums ir piekļuve sistēmai kā parasts lietotājs, varat izpildīt šādu komandu, lai noteiktu, vai esat instalējis Git:

ocs @ ubuntu: ~ $ kas git / usr / bin / git

Ja Git ir instalēts, tad ceļš uz git tiek nodrošināta komanda, kā parādīts iepriekšējā komandā. Ja tas nav instalēts, jūs nesaņemat izvadi vai kļūdu, piemēram:

[ocs @ centos ~] # which git / usr / bin / which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)

Kā administrators Debian sistēmā, jūs varat izmantot dpkg komandu, lai noteiktu, vai Git pakotne ir instalēta:

root @ ubuntu: ~ # dpkg -l git Vēlamais = Nezināms / Instalēt / Noņemt / Notīrīt / Turēt | Statuss = Not / Inst / Conf-files / Unpacked / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Kļūda? = (Nav) / Nepieciešams atkārtoti (Statuss, Kļūda: lielie burti = slikti) | | / Nosaukums Versija Arhitektūras apraksts +++ - ======== - ============= - ============= - === ===================================== ii git 1: 1.9.1-1ubun amd64 ātri, mērogojami , izplatīts ➥revision con

Kā Red Hat balstītas sistēmas administrators jūs varētu izmantot apgr./min komandu, lai noteiktu, vai git pakotne ir instalēta:

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

Ja jūsu sistēmā nav instalēts Git, jums jāpiesakās kā root lietotājam vai jāizmanto sudo vai su lai instalētu programmatūru. Ja esat pieteicies kā root lietotājs sistēmā Debian, Git instalēšanai varat izmantot šādu komandu:

apt-get install git

Ja esat pieteicies kā saknes lietotājs sistēmā Red Hat balstītā sistēmā, Git instalēšanai varat izmantot šādu komandu:

yum instalēt git

Iegūstiet vairāk nekā Git

Apsveriet programmatūras pakotnes instalēšanu git-viss. Šajā paketē ir dažas papildu atkarības paketes, kas Git papildina ar lielāku jaudu. Lai gan sākumā jūs, iespējams, nelietojat šīs funkcijas, būs labi, ja tās būs pieejamas, kad esat gatavs veikt uzlabotas Git funkcijas.

Git jēdzieni un iezīmes

Viens no Git izmantošanas izaicinājumiem ir tikai saprast tā pamatā esošos jēdzienus. Ja jūs nesaprotat jēdzienus, visas komandas vienkārši šķiet kaut kāda melnā maģija. Šī sadaļa koncentrējas uz kritiskajiem Git jēdzieniem, kā arī iepazīstina jūs ar dažām pamata komandām.

Git posmi

Ir ļoti svarīgi atcerēties, ka jūs pārbaudāt visu projektu un ka lielākā daļa jūsu veiktā darba būs lokāli sistēmai, pie kuras strādājat. Pārbaudītie faili tiks ievietoti direktorijā zem jūsu mājas direktorija.

Lai iegūtu projekta kopiju no Git repozitorija, izmantojat procesu, ko sauc klonēšana. Klonēšana ne tikai izveido visu failu kopiju no repozitorija; tas faktiski veic trīs galvenās funkcijas:

Izveido vietējo projekta repozitoriju zem Projekta nosaukums/.git direktoriju jūsu mājas direktorijā. Tiek uzskatīts, ka projekta faili šajā vietā ir pārbaudīti no centrālā repozitorija.
Izveido direktoriju, kurā jūs varat tieši redzēt failus. To sauc par darba zona. Darba zonā veiktās izmaiņas netiek uzreiz kontrolētas ar versiju.
Izveido pieturvietu. Pakāpiena apgabals ir paredzēts failu izmaiņu saglabāšanai, pirms jūs tos nododat vietējam repozitorijam.

Tas nozīmē, ka, ja jūs klonētu projektu ar nosaukumu Jacumba, viss projekts tiktu saglabāts Jacumba / .git direktoriju, kas atrodas jūsu mājas direktorijā. Jums nevajadzētu mēģināt tos tieši modificēt. Tā vietā skatieties tieši ~ / Jacumba direktorija, lai redzētu projekta failus. Šie faili ir jāmaina.

Pieņemsim, ka esat veicis izmaiņas failā, taču jums jāstrādā ar dažiem citiem failiem, pirms bijāt gatavs veikt izmaiņas vietējā repozitorijā. Tādā gadījumā jūs to darītu posmā failu, ar kuru esat pabeidzis strādāt. Tas sagatavotu to saistīt ar vietējo repozitoriju.

Pēc visu izmaiņu veikšanas un visu failu iestudēšanas jūs tos novirzāt uz vietējo repozitoriju.

Saprotiet, ka, veicot pakāpeniskos failus, tie tiek nosūtīti tikai uz vietējo repozitoriju. Tas nozīmē, ka tikai jums ir piekļuve veiktajām izmaiņām. Jaunās versijas pārbaudes centrālajā repozitorijā sauc par a grūst.

Git repozitorija resursdatora izvēle

Pirmkārt, labās ziņas: daudzas organizācijas nodrošina Git hostingu - šī raksta tapšanas laikā ir vairāk nekā divi desmiti izvēles iespēju. Tas nozīmē, ka jums ir daudz iespēju izvēlēties. Tās ir labās un sliktās ziņas.

Tās ir tikai sliktas ziņas, jo tas nozīmē, ka jums patiešām jāpavada laiks, pētot uzņemošo organizāciju plusi un mīnusi. Piemēram, lielākā daļa neiekasē maksu par pamata mitināšanu, bet par lieliem projektiem. Daži nodrošina tikai publiskus krātuves (ikviens var redzēt jūsu krātuvi), bet citi ļauj jums izveidot privātus krātuves. Jāņem vērā daudzas citas funkcijas.

Viena iezīme, kas varētu būt jūsu sarakstā, ir tīmekļa saskarne. Lai gan jūs varat darīt gandrīz visas krātuves darbības lokāli savā sistēmā, spēja veikt dažas darbības, izmantojot tīmekļa saskarni, var būt ļoti noderīga. Pirms izvēles veikšanas izpētiet nodrošināto saskarni.

Es iesaku apsvērt vismaz šādus jautājumus:

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

Ņemiet vērā, ka zemāk redzamajiem piemēriem es izvēlējos Gitlab.com. Jebkurš no iepriekšējā saraksta saimniekiem būtu strādājis tikpat labi; Es izvēlējos Gitlab.com vienkārši tāpēc, ka tas notika tā, kuru izmantoju savā pēdējā Git projektā.

Git konfigurēšana

Tagad, kad esat apguvis visu teoriju, ir pienācis laiks kaut ko darīt ar Gitu. Šajā nākamajā sadaļā tiek pieņemts šāds:

Jūs esat instalējis git vai git-viss programmatūras pakotne jūsu sistēmā.
Jūs esat izveidojis kontu Git mitināšanas pakalpojumā.

Vispirms vēlaties veikt pamata iestatīšanu. Ikreiz, kad veicat apņemšanās operāciju, jūsu vārds un e-pasta adrese tiks iekļauti metadatos. Lai iestatītu šo informāciju, izpildiet šādas komandas:

ocs @ ubuntu: ~ $ git config - globālais lietotājvārds "Bo Rothwell" ocs @ ubuntu: ~ $ git config - globālais lietotājs.email "[email protected]"

Acīmredzot jūs nomainīsit "Bo Rothwell" ar savu vārdu un "[email protected]" ar savu e-pasta adresi. Nākamais solis ir sava projekta klonēšana no mitināšanas pakalpojuma Git. Ņemiet vērā, ka pirms klonēšanas lietotāja mājas direktorijā ir tikai viens fails: