Programovanie

Výukový program Git: Začíname s riadením verzií Git

Tento článok vás zoznámi s Gitom vrátane toho, ako nainštalovať potrebný softvér na prístup k serverom Git, kde bude uložený váš softvérový projekt.

Koncepty riadenia verzií

Aby sme pochopili Git a koncept riadenia verzií, je užitočné pozrieť sa na riadenie verzií z historického hľadiska. Existujú tri generácie softvéru na správu verzií.

Prvá generácia

Prvá generácia bola veľmi jednoduchá. Vývojári pracovali na rovnakom fyzickom systéme a „rezervovali“ si jeden súbor po druhom.

Táto generácia softvéru na správu verzií využívala techniku ​​tzv zamykanie súborov. Keď vývojár odhlásil súbor, bol uzamknutý, takže žiadny iný vývojár nemohol súbor upraviť.

Medzi príklady softvéru na riadenie verzií prvej generácie patria Revision Control System (RCS) a Source Code Control System (SCCS).

Druhá generácia

Medzi problémy prvej generácie patrili tieto problémy:

  • Na súbore mohol pracovať naraz iba jeden vývojár. To malo za následok úzke miesto v procese vývoja.

  • Vývojári sa museli prihlásiť priamo do systému, ktorý obsahoval softvér na správu verzií.

Tieto problémy boli vyriešené v druhej generácii softvéru na správu verzií. V druhej generácii sú súbory uložené na centralizovanom serveri v úložisku. Vývojári si môžu pozrieť samostatné kópie súborov. Keď vývojár dokončí prácu na súbore, súbor sa zapíše do úložiska.

Ak dvaja vývojári skontrolujú rovnakú verziu súboru, existuje potenciálny problém. Rieši to proces nazývaný a zlúčiť.

Čo je to zlúčenie? Predpokladajme, že dvaja vývojári, Bob a Sue, vyskúšajú verziu 5 súboru s názvom abc.txt. Keď Bob dokončí prácu, vráti súbor späť. Zvyčajne to vedie k novej verzii súboru, verzie 6.

O niečo neskôr Sue skontroluje svoj spis. Tento nový súbor musí obsahovať jej zmeny a Bobove zmeny. Toto sa dosahuje procesom zlúčenia.

V závislosti od použitého softvéru na správu verzií môžu existovať rôzne spôsoby riešenia tohto zlúčenia. V niektorých prípadoch, napríklad keď Bob a Sue pracovali na úplne iných častiach súboru, je proces zlúčenia veľmi jednoduchý. Avšak v prípadoch, keď Sue a Bob pracovali na rovnakých riadkoch kódu v súbore, môže byť proces zlúčenia zložitejší. V týchto prípadoch bude musieť Sue robiť rozhodnutia, napríklad či bude Bobov kód alebo jej kód v novej verzii súboru.

Po dokončení procesu zlučovania prebehne proces odovzdania súboru do úložiska. Zaviazanie súboru v podstate znamená vytvorenie novej verzie v úložisku; v tomto prípade verzia 7 súboru.

Medzi príklady softvéru na riadenie verzií druhej generácie patria systémy Concurrent Versions System (CVS) a Subversion.

Tretia generácia

Tretia generácia sa označuje ako distribuované systémy riadenia verzií (DVCS). Rovnako ako druhá generácia, server centrálneho úložiska obsahuje všetky súbory pre projekt. Vývojári však nekontrolujú jednotlivé súbory z úložiska. Namiesto toho je celý projekt rezervovaný, čo vývojárovi umožňuje pracovať skôr na úplnej množine súborov, ako iba na jednotlivých súboroch.

Ďalší (veľmi veľký) rozdiel medzi druhou a treťou generáciou softvéru na správu verzií súvisí s tým, ako funguje proces zlúčenia a odovzdania. Ako už bolo spomenuté, v druhej generácii je potrebné vykonať zlúčenie a odovzdanie novej verzie do úložiska.

So softvérom na správu verzií tretej generácie sa súbory zapisujú a potom sa zlúčia.

Povedzme napríklad, že dvaja vývojári vyskúšajú súbor založený na tretej verzii. Ak jeden vývojár tento súbor skontroluje a výsledkom bude verzia 4 súboru, musí druhý vývojár najskôr zlúčiť zmeny zo svojej odhlásenej kópie so zmenami verzie 4 (a prípadne aj ďalších verzií). Po dokončení zlúčenia môže byť nová verzia odovzdaná do úložiska ako verzia 5.

Ak sa zameriavate na to, čo je v úložisku (stredná časť každej fázy), uvidíte, že existuje veľmi priama línia vývoja (ver1, ver2, ver3, ver4, ver5 atď.). Tento jednoduchý prístup k vývoju softvéru predstavuje určité potenciálne problémy:

  • Požadovanie zlúčenia vývojára pred spáchaním má často za následok, že vývojári nebudú chcieť pravidelne vykonávať svoje zmeny. Proces zlúčenia môže byť nepríjemný a vývojári sa môžu rozhodnúť, že počkajú až neskôr a urobia jedno zlúčenie, a nie kopu pravidelných zlúčení. To má negatívny vplyv na vývoj softvéru, pretože do súboru sa zrazu pridajú obrovské kúsky kódu. Ďalej chcete povzbudiť vývojárov, aby vykonali zmeny v úložisku, rovnako ako chcete povzbudiť niekoho, kto píše dokument, aby si pravidelne ukladali.
  • Veľmi dôležité: Verzia 5 v tomto príklade nemusí nutne znamenať prácu, ktorú vývojár pôvodne dokončil. Počas procesu zlúčenia môže vývojár zahodiť časť svojej práce, aby dokončil proces zlúčenia. To nie je ideálne, pretože to vedie k strate potenciálne dobrého kódu.

Môže sa použiť lepšia, aj keď pravdepodobne zložitejšia technika. To sa nazýva smerovaný acyklický graf (DAG).

Predstavte si rovnaký scenár ako vyššie, kde si dvaja vývojári vyskúšajú verziu 3 súboru. Ak tu jeden vývojár daný súbor skontroluje, výsledkom bude stále jeho verzia 4. Výsledkom druhého procesu registrácie je však súbor verzie 5, ktorý nie je založený na verzii 4, ale je nezávislý od verzie 4. V ďalšej fáze procesu sa verzie 4 a 5 súboru zlúčia a vytvorí sa verzia 6.

Aj keď je tento proces zložitejší (a potenciálne oveľa zložitejší, ak máte veľký počet vývojárov), poskytuje určité výhody oproti jednej línii vývoja:

  • Vývojári môžu vykonávať svoje zmeny pravidelne a nemusia sa starať o zlúčenie až neskôr.
  • Proces zlúčenia je možné delegovať na konkrétneho vývojára, ktorý má lepšiu predstavu o celom projekte alebo kóde ako ostatní vývojári.
  • Kedykoľvek sa môže projektový manažér vrátiť späť a presne vidieť, aké dielo vytvoril každý jednotlivý vývojár.

Pre obidve metódy určite existuje argument. Nezabúdajte však, že tento článok sa zameriava na Git, ktorý používa metódu riadeného acyklického grafu systémov riadenia verzií tretej generácie.

Inštaluje sa Git

Git vo svojom systéme už môžete mať, pretože je niekedy nainštalovaný predvolene (alebo ho mohol nainštalovať iný správca). Ak máte prístup do systému ako bežný používateľ, môžete vykonať nasledujúci príkaz a zistiť, či máte nainštalovaný Git:

ocs @ ubuntu: ~ $ ktoré git / usr / bin / git

Ak je nainštalovaný Git, potom cesta k git príkaz je poskytnutý, ako je uvedené v predchádzajúcom príkaze. Ak nie je nainštalovaný, buď nedostanete žiadny výstup, alebo chybu, ako je táto:

[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)

Ako administrátor v systéme založenom na Debiane môžete používať dpkg príkaz na zistenie, či je nainštalovaný balík Git:

root @ ubuntu: ~ # dpkg -l git Požadované = Neznáme / Inštalovať / Odstrániť / Čistiť / Zadržať | Status = Not / Inst / Conf-files / Unpacked / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Err? = (None) / Reinst-required (Status, Err: uppercase = bad) | | / Názov Verzia Architektúra Popis +++ - ======== - ============= - ============= - === ====================================== ii git 1: 1.9.1-1ubun amd64 rýchly, škálovateľný , distribuované ➥revízia kon

Ako správca v systéme založenom na Red Hat môžete použiť ot./min príkaz na zistenie, či bol nainštalovaný balík git:

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

Ak vo vašom systéme nie je nainštalovaný Git, musíte sa prihlásiť ako používateľ root alebo použiť sudo alebo su na inštaláciu softvéru. Ak ste prihlásený ako užívateľ root v systéme založenom na Debiane, môžete na inštaláciu Gitu použiť nasledujúci príkaz:

apt-get nainštalovať git

Ak ste prihlásený ako užívateľ root v systéme založenom na Red Hat, môžete nainštalovať Git pomocou nasledujúceho príkazu:

yum nainštalovať git

Získajte viac ako Git

Zvážte inštaláciu softvérového balíka git-all. Tento balík obsahuje niekoľko ďalších balíkov závislostí, ktoré zvyšujú výkon systému Git. Aj keď tieto funkcie nemusíte na začiatku používať, bude dobré mať ich k dispozícii, keď budete pripravení vykonávať pokročilejšie funkcie Git.

Koncepty a funkcie Git

Jednou z výziev pri používaní Gitu je len pochopenie konceptov, ktoré sú za tým. Ak nerozumiete konceptom, potom sa všetky príkazy javia ako nejaká čierna mágia. Táto časť sa zameriava na kritické koncepty Git a oboznámi vás s niektorými základnými príkazmi.

Gitové fázy

Je veľmi dôležité mať na pamäti, že ste skontrolovali celý projekt a že väčšina vašej práce bude lokálna v systéme, na ktorom pracujete. Súbory, ktoré si rezervujete, budú umiestnené do adresára vo vašom domovskom adresári.

Ak chcete získať kópiu projektu z úložiska Git, použijete proces s názvom klonovanie. Klonovanie nevytvára iba kópiu všetkých súborov z úložiska; v skutočnosti plní tri základné funkcie:

  • Vytvorí miestne úložisko projektu pod Názov projektuadresár /.git vo vašom domovskom adresári. Súbory projektu na tomto mieste sa považujú za rezervované z centrálneho úložiska.
  • Vytvorí adresár, kde môžete priamo vidieť súbory. Toto sa nazýva pracovisko. Zmeny vykonané v pracovnej oblasti nie sú okamžite riadené verziou.
  • Vytvorí oddychovú oblasť. Oddychová oblasť je navrhnutá na ukladanie zmien súborov predtým, ako ich potvrdíte v miestnom úložisku.

To znamená, že ak by ste naklonovali projekt s názvom Jacumba, celý projekt by bol uložený v priečinku Jacumba / .git adresár vo vašom domovskom adresári. Nesnažte sa ich priamo upravovať. Namiesto toho sa pozrite priamo do ~ / Jacumba adresár tol zobraziť súbory z projektu. Toto sú súbory, ktoré by ste mali zmeniť.

Predpokladajme, že ste vykonali zmenu v súbore, ale na niektorých ďalších súboroch musíte pracovať skôr, ako budete pripravení vykonať zmeny v miestnom úložisku. V takom prípade by ste to urobili etapa súbor, na ktorom ste dokončili prácu. To by pripravilo jeho nasadenie v miestnom úložisku.

Po vykonaní všetkých zmien a rozmiestnení všetkých súborov ich odovzdáte do miestneho úložiska.

Uvedomte si, že potvrdenie postupných súborov ich pošle iba do miestneho úložiska. To znamená, že k vykonaným zmenám máte prístup iba vy. Proces kontroly nových verzií do centrálneho úložiska sa nazýva a tam.

Výber hostiteľa úložiska Git

Prvá dobrá správa: Mnoho organizácií poskytuje hostenie Gitu - v čase písania tohto článku existuje viac ako dve desiatky možností. To znamená, že máte na výber z mnohých možností. To sú dobré správy ... a zlé správy.

Je to iba zlá správa, pretože to znamená, že musíte skutočne venovať nejaký čas hľadaniu výhod a nevýhod hostiteľských organizácií. Napríklad väčšina neúčtuje poplatky za základný hosting, ale účtuje si poplatky za rozsiahle projekty. Niektoré poskytujú iba verejné úložiská (vaše úložisko môže vidieť ktokoľvek), zatiaľ čo iné vám umožňujú vytvárať súkromné ​​úložiská. Existuje mnoho ďalších funkcií, ktoré je potrebné vziať do úvahy.

Jednou z funkcií, ktorá by mohla byť na vašom zozname vysoko, je webové rozhranie. Aj keď v systéme môžete vykonávať takmer všetky operácie úložiska lokálne vo vašom systéme, schopnosť vykonávať niektoré operácie cez webové rozhranie môže byť veľmi užitočná. Pred výberom preskúmajte poskytované rozhranie.

Prinajmenšom odporúčam zvážiť nasledovné:

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

Upozorňujeme, že som si pre nižšie uvedené príklady vybral stránku Gitlab.com. Ktokoľvek z hostiteľov v predchádzajúcom zozname by fungoval rovnako dobre; Gitlab.com som si vybral jednoducho preto, lebo som ho použil pri svojom poslednom projekte Git.

Konfigurácia Git

Teraz, keď ste sa dostali cez celú teóriu, je čas skutočne niečo urobiť s Gitom. Táto ďalšia časť predpokladá nasledovné:

  • Nainštalovali ste git alebo git-all softvérový balík vo vašom systéme.
  • Vytvorili ste si účet v hostiteľskej službe Git.

Prvá vec, ktorú musíte urobiť, je vykonať základné nastavenie. Kedykoľvek vykonáte operáciu potvrdenia, vaše meno a e-mailová adresa budú uvedené v metadátach. Ak chcete nastaviť tieto informácie, vykonajte nasledujúce príkazy:

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

Je zrejmé, že nahradíte „Bo Rothwell“ s tvojim menom a [email protected] s tvojou emailovou adresou. Ďalším krokom je klonovanie projektu z hostiteľskej služby Git. Pred klonovaním sa v domovskom adresári používateľa nachádza iba jeden súbor:

ocs @ ubuntu: ~ $ ls first.sh

Nasledujúce klonovalo projekt s názvom ocs:

$config[zx-auto] not found$config[zx-overlay] not found