Ste se naučili ukazov Git, vendar si želite predstavljati, kako kontinuirana integracija (CI) deluje v resnici? Ali pa morda želite optimizirati svoje dnevne aktivnosti? Ta tečaj vam bo dal praktične veščine nenehne integracije z uporabo repozitorija GitHub. Ta tečaj ni mišljen kot čarovnik, po katerem bi lahko preprosto kliknili; ravno nasprotno, izvajali boste ista dejanja, ki jih ljudje dejansko počnejo v službi, na enak način, kot to počnejo oni. Teorijo bom razložil, ko boste šli skozi vključene korake.

Kaj počnemo?

Ko bomo napredovali, bomo postopoma ustvarili seznam tipičnih korakov CI, kar je odličen način, da si ta seznam zapomnimo. Z drugimi besedami, ustvarili bomo seznam dejanj, ki jih izvajajo razvijalci med neprekinjeno integracijo, neprekinjeno integracijo. Uporabili bomo tudi preprost niz testov, da bi naš proces CI približali dejanskemu.

Ta GIF shematično prikazuje objave v vašem repozitoriju, ko napredujete skozi tečaj. Kot lahko vidite, tukaj ni nič zapletenega in samo najnujnejše.

Šli boste skozi naslednje standardne scenarije CI:

• Delo na funkciji;
• Uporaba avtomatiziranih testov za zagotavljanje kakovosti;
• Izvedba prednostne naloge;
• Reševanje konfliktov pri združevanju vej (konflikt združevanja);
• V produkcijskem okolju pride do napake.

Kaj se boste naučili?

Odgovorili boste lahko na naslednja vprašanja:

• Kaj je kontinuirana integracija (CI)?
• Katere vrste avtomatiziranih testov se uporabljajo v CI in kot odgovor na katera dejanja se sprožijo?
• Kaj so zahteve po vleku in kdaj so potrebne?
• Kaj je Test Driven Development (TDD) in kako je povezan z CI?
• Ali naj spremembe združim ali spremenim?
• Povrniti ali popraviti v naslednji različici?

Sprva sem povsod prevajal stvari, kot je »povlečne zahteve«, a sem se posledično odločil, da na nekaterih mestih vrnem besedne zveze v angleščini, da zmanjšam stopnjo norosti v besedilu. Včasih bom uporabil "programerski suržik", kot je čudovit glagol "zavezati se", kjer ga ljudje dejansko uporabljajo v službi.

Kaj je kontinuirana integracija?

Neprekinjena integracija, ali CI, je tehnična praksa, pri kateri vsak član ekipe integrira svojo kodo v skupno skladišče vsaj enkrat na dan, nastala koda pa mora biti vsaj zgrajena brez napak.

Glede tega izraza obstajajo nesoglasja

Točka spora je pogostost integracije. Nekateri trdijo, da združevanje kode samo enkrat na dan ni dovolj za dejansko stalno integracijo. Podan je primer ekipe, kjer vsak zjutraj vzame novo kodo in jo integrira enkrat zvečer. Čeprav je to razumen ugovor, se na splošno verjame, da je definicija enkrat na dan razumno praktična, specifična in primerna za ekipe različnih velikosti.

Drug ugovor je, da C++ ni več edini jezik, ki se uporablja pri razvoju, in preprosto zahtevanje sestavljanja brez napak kot načina preverjanja veljavnosti je šibko. Nekateri nizi testov (na primer testi enot, ki se izvajajo lokalno) se morajo prav tako uspešno zaključiti. Trenutno se skupnost približuje temu, da bi to postala zahteva, v prihodnosti pa bo "gradnja + testi enote" verjetno postala običajna praksa, če še ni.

Neprekinjena integracija se razlikuje od neprekinjeno dostavo (Continuous Delivery, CD), saj ne zahteva kandidata za izdajo po vsakem integracijskem ciklu.

Seznam korakov, ki jih bomo uporabljali skozi tečaj

1. Vnesite najnovejšo kodo. Ustvarite vejo iz master. Začni delati.
2. Ustvarite zaveze v svoji novi veji. Zgradite in preizkusite lokalno. Pass? Pojdite na naslednji korak. spodletelo? Popravite napake ali preizkusite in poskusite znova.
3. Potisnite v oddaljeno skladišče ali oddaljeno podružnico.
4. Ustvarite zahtevo za vlečenje. Razpravljajte o spremembah, med nadaljevanjem razprave dodajte več potrditev. Poskrbite, da bodo testi uspešni na veji funkcij.
5. Spajanje/ponovno baziranje potrdi iz nadrejenega. Poskrbite, da bodo testi prestali rezultat spajanja.
6. Razmestite od veje funkcij do proizvodnje.
7. Če je v proizvodnji nekaj časa vse v redu, združite spremembe v master.

️ Priprava

Preverite, ali imate pravo programsko opremo

Za obisk tega tečaja boste potrebovali Node.js и Odjemalec Git.

Uporabite lahko katerega koli odjemalca Git, vendar bom ponudil samo ukaze za ukazno vrstico.

Preverite, ali imate nameščen odjemalec Git, ki podpira ukazno vrstico

Če še nimate odjemalca Git, ki podpira ukazno vrstico, lahko najdete navodila za namestitev tukaj.

Pripravite skladišče

Ustvariti boste morali osebno kopijo (fork) repozitorij predlog s kodo za tečaj na GitHubu. Dogovorimo se, da to imenujemo osebna kopija repozitorij tečajev.

Končano? Če niste spremenili privzetih nastavitev, se najverjetneje kliče vaš repozitorij tečajev continuous-integration-team-scenarios-students, se nahaja v vašem računu GitHub in URL je videti takole

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Preprosto bom poklical ta naslov <URL репозитория>.

Kotni oklepaji kot <тут> bo pomenilo, da morate tak izraz nadomestiti z ustrezno vrednostjo.

Poskrbi da GitHub dejanja vključeno v ta repozitorij tečajev. Če niso omogočeni, jih omogočite s klikom na velik gumb na sredini strani, do katerega pridete s klikom na Dejanja v vmesniku GitHub.

Ne boste mogli dokončati tečaja po mojih navodilih, če dejanja GitHub niso omogočena.

Vedno lahko uporabite možnost GitHub za upodabljanje Markdown, da vidite trenutno stanje seznama, ki ga sestavljamo tukaj

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

O odgovorih

Čeprav je najboljši način za dokončanje tega tečaja, da to storite sami, boste morda imeli nekaj težav.

Če menite, da ne razumete, kaj storiti, in ne morete nadaljevati, lahko pogledate v temo solution, ki je v vašem začetnem skladišču.
Prosim, ne združite solution в master med tečajem. To vejo lahko uporabite, da ugotovite, kaj storiti, ali da primerjate svojo kodo z avtorjevo, z uporabo vseh zmožnosti, ki nam jih daje Git. Če ste popolnoma izgubljeni, lahko popolnoma zamenjate svojo podružnico master na veji solution in nato ponastavite svoj delovni imenik na korak tečaja, ki ga potrebujete.

Uporabite to le, če jo res potrebujete

Uveljavite svojo kodo

git add .
git commit -m "Backing up my work"

Ti ukazi

• preimenovati master в master-backup;
• preimenovati solution в master;
• blagajna v novo poslovalnico master in prepisati vsebino delovnega imenika;
• Ustvarite vejo "rešitev" iz "master" (ki je bila prej "rešitev"), če boste v prihodnosti potrebovali vejo "rešitev".

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Po teh korakih lahko uporabite git log master da ugotovite, katero objavo potrebujete.
Svoj delovni imenik lahko ponastavite na to obvezo takole:

git reset --hard <the SHA you need>

Če ste zadovoljni z rezultatom, boste morali na neki točki objaviti svojo različico repozitorija v oddaljenem repozitoriju. Pri tem ne pozabite izrecno določiti oddaljene veje.

git push --force origin master

Upoštevajte, da uporabljamo git push --force. Malo verjetno je, da boste to želeli početi zelo pogosto, vendar imamo tukaj zelo specifičen scenarij z enim uporabnikom repozitorija, ki poleg tega razume, kaj počne.

Začetek dela

Začnimo sestavljati naš seznam korakov CI. Običajno bi ta korak začeli s preverjanjem najnovejše različice kode v oddaljenem repozitoriju, vendar lokalnega repozitorija še nimamo, zato ga namesto tega kloniramo iz oddaljenega repozitorija.

️ Naloga: posodobite lokalni repozitorij, ustvarite vejo iz master, začni delati

1. Klonirajte repozitorij tečaja iz <URL репозитория>.
2. Teči npm install v imeniku repozitorija tečajev; Potrebujemo ga za namestitev programa Jest, ki ga uporabljamo za izvajanje testov.
3. Ustvarite vejo in jo poimenujte feature. Preklopi na to nit.

4. Dodajte preskusno kodo v ci.test.js med komentarji, ki me prosijo, naj to storim.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. V datoteko dodajte besedilo s prvimi 4 koraki ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Ekipe

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Ustvarite objave v novi veji, zgradite in preizkusite lokalno

Nastavili bomo teste, ki se bodo izvajali pred potrditvijo, in nato potrdili kodo.

Tipični scenariji, ko se testi izvajajo samodejno

• Lokalno:
  • Nenehno ali kot odziv na ustrezne spremembe kode;
  • Pri shranjevanju (za interpretirane ali JIT-prevedene jezike);
  • Med sestavljanjem (ko je potrebno prevajanje);
  • Ob predaji;
  • Pri objavi v skupnem repozitoriju.

• Na gradbenem strežniku ali gradbenem okolju:
  • Ko je koda objavljena v osebni veji/repozitoriju.
  • Koda v tej temi se testira.
  • Potencialni rezultat združitve se testira (običajno s master).
  • Kot stopnja stalne integracije/cevovod neprekinjene dostave

Značilno je, da hitreje ko teče paket testov, pogosteje si ga lahko privoščite. Tipična stopenjska porazdelitev bi lahko izgledala takole.

• Hitri testi enot - med gradnjo, v cevovodu CI
• Počasni testi enot, hitri testi komponent in integracijski testi - ob potrditvi, v cevovodu CI
• Preizkusi počasnih komponent in integracije – v pripravi CI
• Varnostno testiranje, testiranje obremenitve in drugi dolgotrajni ali dragi testi - v cevovodih CI/CD, vendar le v določenih načinih/stopnjah/cevovodih gradnje, na primer pri pripravi kandidata za izdajo ali pri ročnem izvajanju.

️Naloga

Predlagam, da najprej ročno zaženete teste z ukazom npm test. Po tem dodajmo git hook za zagon naših testov ob potrditvi. Obstaja en ulov: kljuke Git se ne štejejo za del repozitorija in jih zato ni mogoče klonirati iz GitHuba skupaj z ostalim gradivom tečaja. Če želite namestiti kavelj, morate zagnati install_hook.sh ali kopirajte datoteko repo/hooks/pre-commit v lokalni imenik .git/hooks/.
Ko se zavežete, boste videli, da se izvajajo testi in preverjajo, ali so določene ključne besede prisotne na seznamu.

1. Zaženite teste ročno z zagonom ukaza npm test v vaši mapi repozitorija tečaja. Preverite, ali so bili testi opravljeni.
2. Nastavite kavelj za objavo (kavelj pred objavo) z zagonom install_hook.sh.
3. Spremembe objavite v lokalnem skladišču.
4. Prepričajte se, da se izvajajo testi, preden se zavežete.

Po izvedbi teh korakov bi moralo vaše skladišče izgledati takole.

Ekipe

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Objavite kodo v oddaljenem repozitoriju ali oddaljeni podružnici

Ko končajo z lokalnim delom, razvijalci običajno dajo svojo kodo na voljo javnosti, tako da jo je mogoče sčasoma integrirati v javnost. Pri GitHubu se to običajno doseže z objavo dela bodisi v osebni kopiji repozitorija (osebni fork) bodisi v osebni veji.

• Z vilicami razvijalec klonira oddaljeno repozitorij v skupni rabi in ustvari njegovo osebno oddaljeno kopijo, znano tudi kot fork. Nato klonira ta osebni repozitorij za lokalno delo. Ko je delo končano in so opravljene objave, jih potisne v svoje vilice, kjer so na voljo drugim in jih je mogoče vključiti v skupno skladišče. Ta pristop se pogosto uporablja v odprtokodnih projektih na GitHubu. Uporablja se tudi v mojem nadaljevalnem tečaju [Timsko delo in CI z Gitom] (http://devops.redpill.solutions/).
• Drug pristop je uporaba samo enega oddaljenega repozitorija in štetje samo veje master skupno skladišče "zaščiteno". V tem scenariju posamezni razvijalci objavijo svojo kodo v vejah oddaljenega repozitorija, tako da lahko drugi pogledajo to kodo, če je vse v redu, jo združijo z master skupno skladišče.

V tem posebnem tečaju bomo uporabljali potek dela, ki uporablja veje.

Objavimo našo kodo.

️Naloga

• Objavite spremembe v oddaljeni veji z enakim imenom kot vaša delovna veja

Ekipe

git push --set-upstream origin feature

Ustvarite zahtevo za vlečenje

Ustvarite zahtevo za vlečenje z naslovom Pregled korakov. Namestite feature kot "glavna podružnica" in master kot "osnovna veja".

Preverite, ali ste namestili master v njegovem razcepi repozitorij Kot "osnovna veja" ne bom odgovarjal na zahteve po spremembah skladišča gradiva za tečaj.

V jeziku GitHub je »osnovna veja« veja, na kateri temelji vaše delo, »glavna veja« pa je veja, ki vsebuje predlagane spremembe.

Razpravljajte o spremembah, dodajte nove obveznosti, ko se razprava nadaljuje

Zahteva za umik (PR)

Zahteva za umik (PR) je način za razpravo in dokumentiranje kode ter za izvajanje pregleda kode. Zahteve za vlečenje so poimenovane po splošnem načinu vključevanja posameznih sprememb v celotno kodo. Običajno oseba klonira oddaljeni uradni repozitorij projekta in lokalno dela na kodi. Po tem kodo postavi v svoj osebni oddaljeni repozitorij in prosi tiste, ki so odgovorni za uradno repozitorij, da prevzamejo(potegnite) svojo kodo v svoje lokalne repozitorije, kjer pregledajo in po možnosti integrirajo (združiti) njegov. Ta koncept je znan tudi pod drugimi imeni, npr. zahteva za združitev.

Pravzaprav vam ni treba uporabiti funkcije za zahtevo po vleki GitHuba ali podobnih platform. Razvojne skupine lahko uporabljajo druge metode komunikacije, vključno z osebno komunikacijo, glasovnimi klici ali e-pošto, vendar še vedno obstajajo številni razlogi za uporabo zahtev po vleku v slogu foruma. Tukaj je nekaj izmed njih:

• organizirane razprave v zvezi s specifičnimi spremembami kode;
• kot mesto za ogled povratnih informacij o delu, ki je v teku, s strani samopreizkuševalcev in vrstnikov;
• formalizacija pregledov kode;
• tako da lahko pozneje ugotovite razloge in premisleke za tem ali onim delom kode.

Običajno ustvarite zahtevo za vlečenje, ko morate o nečem razpravljati ali dobiti povratne informacije. Na primer, če delate na funkciji, ki bi jo lahko implementirali na več kot en način, lahko ustvarite zahtevo za vlečenje, preden napišete prvo vrstico kode, da delite svoje ideje in razpravljate o svojih načrtih s svojimi sodelavci. Če je delo enostavnejše, se zahteva za vleko odpre, ko je nekaj že narejeno, predano in se o tem lahko pogovarjamo. V nekaterih scenarijih boste morda želeli odpreti PR samo zaradi nadzora kakovosti: za izvajanje samodejnih testov ali zagon pregledov kode. Ne glede na to, kako se odločite, ne pozabite @omeniti ljudi, katerih odobritev želite v svoji zahtevi za vlečenje.

Običajno pri ustvarjanju PR naredite naslednje.

• Navedite, kaj nameravate spremeniti in kje.
• Napišite opis, v katerem pojasnite namen sprememb. Morda boste želeli:
  • dodajte kar koli pomembnega, kar ni očitno iz kode, ali nekaj uporabnega za razumevanje konteksta, kot so ustrezni #hrošči in številke potrditve;
  • @omenite kogarkoli, s katerim želite začeti sodelovati, ali pa ga @omenite v komentarjih pozneje;
  • prosite kolege, da vam pri nečem pomagajo ali preverijo kaj konkretnega.

Ko odprete PR, se izvedejo testi, konfigurirani za izvajanje v takih primerih. V našem primeru bo to enak nabor testov, ki smo jih izvajali lokalno, toda v resničnem projektu so lahko dodatni testi in preverjanja.

Počakajte, da se testi končajo. Stanje testov si lahko ogledate na dnu PR razprave v vmesniku GitHub. Nadaljujte, ko so testi končani.

️ Dodajte opombo o naključnosti seznama korakov CI

Seznam, uporabljen v tem tečaju, je poljuben in subjektiven, o tem moramo dodati opombo.

️ Naloga: ustvarite zahtevo za vleko za ta komentar

1. Preklopi na podružnico master.
2. Ustvari vejo z imenom bugfix.
3. Dodajte besedilo opombe na konec datoteke ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Spremenite spremembe.
5. Objavi nit bugfix v oddaljeni repozitorij.
6. Ustvari zahtevo za vlečenje z imenom Dodajanje opombe z glavno vejo bugfix in osnovno vejomaster.

Preverite, ali ste namestili master v njegovem razcepi repozitorij Kot "osnovna veja" ne bom odgovarjal na zahteve po spremembah skladišča gradiva za tečaj.

Tako bi moralo izgledati vaše skladišče.

Ekipe

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Odobri zahtevo za vleko "Dodajanje pripombe"

️Naloga

1. Ustvarite zahtevo za vlečenje.
2. Kliknite »Zahteva za združitev vleka«.
3. Kliknite »Potrdi združitev«.
4. Kliknite »Izbriši vejo«, ne potrebujemo je več.

To je diagram odobritev po združitvi.

️ Delajte naprej in dodajajte teste

Sodelovanje pri zahtevi za vlečenje pogosto povzroči dodatno delo. To je običajno rezultat pregleda kode ali razprave, vendar bomo v našem tečaju to modelirali z dodajanjem novih elementov na naš seznam korakov CI.

Neprekinjena integracija običajno vključuje nekaj testne pokritosti. Zahteve glede pokritosti testov se razlikujejo in jih običajno najdemo v dokumentu, ki se imenuje "smernice za prispevke". Ohranili bomo preprostost in dodali preizkus za vsako vrstico na našem kontrolnem seznamu.

Ko izvajate naloge, poskusite najprej opraviti teste. Če ste pravilno namestili pre-commit kavelj prej, se bo na novo dodan test izvedel, ne bo uspel in nič ne bo odobreno. Upoštevajte, da tako vemo, da naši testi dejansko nekaj testirajo. Zanimivo je, da če bi začeli s kodo pred testi, bi uspešno opravljeni testi lahko pomenili, da je koda delovala po pričakovanjih, ali da testi dejansko niso testirali ničesar. Poleg tega, če testov ne bi pisali že na začetku, bi morda nanje povsem pozabili, saj nas nič ne bi spominjalo na to.

Testno usmerjen razvoj (TDD)

TDD priporoča pisanje testov pred kodo. Tipičen potek dela z uporabo TDD izgleda takole.

1. Dodajte test.
2. Zaženite vse teste in se prepričajte, da novi test ni uspešen.
3. Napišite kodo.
4. Izvedite teste, poskrbite, da bodo vsi testi uspešni.
5. Preoblikujte svojo kodo.
6. Ponovi.

Ker so rezultati neuspešnih testov običajno prikazani v rdeči barvi, rezultati uspešnih pa v zeleni barvi, je cikel znan tudi kot rdeče-zeleni refaktor.

️Naloga

Najprej poskusite potrditi preizkuse in pustite, da so neuspešni, nato dodajte in potrdite besedilo samega seznama korakov CI. Videli boste, da so testi uspešni ("zeleno").
Nato objavite novo kodo v oddaljenem repozitoriju in si oglejte, kako se testi izvajajo v vmesniku GitHub na dnu razprave o zahtevi za vleko in posodobitvi statusa PR.

1. Preklopi na podružnico feature.

2. Dodajte te teste v ci.test.js po zadnjem klicu it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Poskusite opraviti teste. če pre-commit kavelj nameščen, poskus objave ne bo uspel.
4. Nato dodajte to besedilo v ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Izvedite in potrdite spremembe lokalno.
6. Objavite spremembe v veji feature.

Zdaj bi morali imeti nekaj takega

Ekipe

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Konflikt spajanja

Pojdite na Spremeni zahtevo Pregled korakov.

Čeprav nismo storili ničesar narobe in so testi za našo kodo uspešni, še vedno ne moremo združiti veje feature и master. To je zato, ker druga nit bugfix je bil združen z master medtem ko smo delali na tem PR-ju.
To ustvari situacijo, ko oddaljena veja master ima novejšo različico od tiste, na kateri smo osnovali vejo feature. Zaradi tega ne moremo samo previti HEAD master do konca niti feature. V tej situaciji moramo združiti ali uporabiti potrditve feature ponovno osnovati master. GitHub lahko dejansko izvede samodejno združevanje, če ni sporov. Žal, v naši situaciji imata obe veji konkurenčne spremembe v datoteki ci.md. Ta situacija je znana kot spor spajanja in rešiti jo moramo ročno.

Spoji ali preosnovi

Spoji

• Ustvari dodatno potrditev združevanja in shrani zgodovino dela.
  • Ohranja izvirne objave vej z njihovimi izvirnimi časovnimi žigi in avtorji.
  • Shrani SHA potrditev in se poveže z njimi v razpravah o zahtevah za spremembe.
• Zahteva enkratno rešitev spora.
• Naredi zgodbo nelinearno.
  • Zgodba je lahko težko berljiva zaradi velikega števila vej (spominja na IDE kabel).
  • Oteži samodejno odpravljanje napak, npr. git bisect manj uporaben - našel bo le potrditev spajanja.

Prenovite

• Ponavlja objave iz trenutne veje na vrh osnovne veje eno za drugo.
  • Generirajo se nove objave z novimi SHA, zaradi česar se objave v GitHubu ujemajo z izvirnimi zahtevami za vlečenje, ne pa tudi z ustreznimi komentarji.
  • Zaveze je mogoče ponovno združiti in spremeniti v procesu ali celo združiti v eno.
• Morda bo treba razrešiti več konfliktov.
• Omogoča ohranjanje linearne zgodbe.
  • Zgodbo je morda lažje brati, če ni predolga brez razumnega razloga.
  • Samodejno razhroščevanje in odpravljanje težav je nekoliko lažje: omogoča git bisect, lahko naredi samodejne povrnitve jasnejše in predvidljivejše.
• Zahteva objavo veje s preseljenimi potrditvami z zastavico --force kadar se uporablja z zahtevami za vlečenje.

Običajno se ekipe strinjajo, da bodo vedno uporabljale isto strategijo, ko morajo združiti spremembe. To je lahko "čisto" združevanje ali "čista" objava na vrhu ali nekaj vmes, kot je interaktivno izvajanje objave na vrhu (git rebase -i) lokalno za veje, ki niso objavljene v javnem repozitoriju, vendar se združijo za "javne" veje.

Tukaj bomo uporabili spajanje.

️Naloga

1. Prepričajte se, da je koda v lokalni izpostavi master posodobljen iz oddaljenega skladišča.
2. Preklopi na podružnico feature.
3. Začni spajanje z vejo master. Konflikt združitve zaradi konkurenčnih sprememb v ci.md.
4. Rešite spor tako, da bosta naš seznam korakov CI in opomba o njem ostala v besedilu.
5. Objavite združitveno objavo v oddaljeni veji feature.
6. Preverite stanje zahteve za vlečenje v uporabniškem vmesniku GitHub in počakajte, da se združitev razreši.

Ekipe

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Odlično opravljeno!

Končali ste s seznamom in zdaj morate odobriti zahtevo za vlečenje master.

️ Naloga: odobri zahtevo za vleko "Pregled korakov"

1. Odprite zahtevo za vlečenje.
2. Kliknite »Zahteva za združitev vleka«.
3. Kliknite »Potrdi združitev«.
4. Kliknite »Izbriši vejo«, ker je ne potrebujemo več.

To je trenutno vaše skladišče

Napaka izdelka

Rečeno je, da se "testiranje lahko uporablja za prikaz prisotnosti napak, vendar nikoli za prikaz njihove odsotnosti." Čeprav smo imeli teste in nam niso pokazali nobenih napak, se je v proizvodnjo prikradel zahrbten hrošč.

V takšnem scenariju moramo poskrbeti za:

• kaj se uporablja v proizvodnji;
• koda v temi master z napako, od katere lahko razvijalci začnejo novo delo.

Naj ga vrnem ali popravim v naslednji različici?

Povrnitev nazaj je postopek razmestitve znane dobre starejše različice v produkcijo in razveljavitve potrditev, ki vsebujejo napako. "Popravljanje naprej" je dodatek popravka k master in čimprejšnja uvedba nove različice. Ker se API-ji in sheme baz podatkov spreminjajo, ko se koda uvaja v produkcijo, z neprekinjeno dostavo in dobro pokritostjo s testi, je vrnitev nazaj običajno veliko težja in tvegana kot popravljanje v naslednji različici.

Ker vrnitev nazaj v našem primeru ne prinaša nobenega tveganja, bomo šli po tej poti, saj nam to omogoča

• odpraviti napako na izdelku čim prej;
• vnesite kodo master takoj primeren za začetek nove zaposlitve.

️Naloga

1. Preklopi na podružnico master lokalno.
2. Posodobite lokalni repozitorij iz oddaljenega repozitorija.
3. Razveljavi potrditev združitve PR Pregled korakov в master.
4. Objavite spremembe v oddaljenem repozitoriju.

To je zgodovina repozitorija s preklicano odobritvijo spajanja

Ekipe

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Samotestiranje

Poskrbi da ci.md po razveljavitvi objave spajanja ne vsebuje več besedila "zahrbten hrošč".

Popravite seznam korakov CI in ga vrnite masterju

Popolnoma smo razveljavili potrditev spajanja veje. feature. Dobra novica je, da zdaj nimamo nobene napake master. Slaba novica je, da tudi našega dragocenega seznama korakov stalne integracije ni več. Torej, v idealnem primeru moramo uporabiti popravek za objave iz feature in jih vrniti v master skupaj s popravkom.

Problema se lahko lotimo na različne načine:

• razveljavi objavo, ki razveljavi spajanje feature с master;
• premakni zaveze iz prejšnjega feature.

Različne razvojne skupine v tem primeru uporabljajo različne pristope, vendar bomo uporabne zaveze premaknili v ločeno vejo in ustvarili ločeno zahtevo za vlečenje za to novo vejo.

️Naloga

1. Ustvarite nit, imenovano feature-fix in preklopite nanj.

2. Preseli vse objave iz prejšnje veje feature v novo nit. Razrešite spore združevanja, do katerih je prišlo med selitvijo.

   

3. Dodajte regresijski test v ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Zaženite teste lokalno, da zagotovite, da ne bodo padli.
5. Odstranite besedilo "z zahrbtnim hroščem". ci.md.
6. V indeks dodajte preskusne spremembe in spremembe seznama korakov ter jih potrdite.
7. Objavite vejo v oddaljenem repozitoriju.

Na koncu bi morali dobiti nekaj podobnega temu:

Ekipe

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Ustvarite zahtevo za vlečenje.

Ustvarite zahtevo za vlečenje z naslovom Popravljanje funkcije. Namestite feature-fix kot "glavna podružnica" in master kot "osnovna veja".
Počakajte, da se testi končajo. Stanje testov si lahko ogledate na dnu PR diskusije.

Preverite, ali ste namestili master v njegovem razcepi repozitorij Kot "osnovna veja" ne bom odgovarjal na zahteve po spremembah skladišča gradiva za tečaj.

Odobri zahtevo za vleko "Popravljanje funkcije"

Hvala za popravek! Prosimo, odobrite spremembe za master iz zahteve za vlečenje.

️Naloga

1. Kliknite »Zahteva za združitev vleka«.
2. Kliknite »Potrdi združitev«.
3. Kliknite »Izbriši vejo«, ker je ne potrebujemo več.

To je tisto, kar bi morali imeti v tem trenutku.

Čestitamo!

Opravili ste vse korake, ki jih ljudje običajno izvajajo med neprekinjeno integracijo.

Če opazite težave s tečajem ali veste, kako ga izboljšati, ustvarite težavo v repozitorije z gradivi za tečaje. Ta tečaj ima tudi interaktivna različica uporabo GitHub Learning Lab kot platforme.

Vir: www.habr.com