Olete õppinud Git'i käske, kuid soovite mõista, kuidas pidev integreerimine (Continuous Integration, CI) reaalses elus toimub? Võib-olla soovite optimeerida oma igapäevaseid tegevusi? See kursus annab teile praktilised oskused pideva integreerimise osas, kasutades GitHubi repositooriumi. See kursus ei ole mõeldud mingiks viisardiks, millega lihtsalt klikkida; vastupidi, teete samu toiminguid, mida inimesed tegelikult tööl teevad, samal viisil, kuidas nad seda teevad. Selgitan teooriat samal ajal, kui liigute seotud sammude kaudu.

Mida me teeme?

Edasi liikudes loome järk-järgult CI tüüpiliste sammude loendi, mis on suurepärane viis selle nimekirja meeles pidamiseks. Teisisõnu, loome tegevuste nimekirja, mida arendajad teevad pideva integreerimise käigus. Samuti kasutame lihtsat testide kogumit, et viia meie CI protsess tõele lähemale.

See GIF näitab scheematiliselt teie repositooriumis tehtud commit'e, kui edusamme teete. Nagu näete, pole siin midagi keerulist ja kõik on vajalik.

Te läbite järgmised CI-standardile vastavad stsenaariumid:

• Töö feature'iga;
• Automaatsete testide rakendamine kvaliteedi tagamiseks;
• Prioriteetse ülesande täitmine;
• Kollisiooni lahendamine harude liitmisel (merge conflict);
• Tõrke tekkimine tootmiskeskkonnas.

Mida te õpite?

Saate vastata sellistele küsimustele:

• Mis on pidev integreerimine (CI)?
• Milliseid automaatseid teste kasutatakse CI-s ja millistele toimingutele need käivitatakse?
• Mis on pull request ja millal neid on vaja?
• Mis on testipõhine arendus (Test Driven Development, TDD) ja kuidas see seondub CI-ga?
• Kas liita (merge) või rakendada muutusi (rebase)?
• Kas tagasi rullida või parandada järgmises versioonis?

Alguses tõlkisin igal pool asju nagu "pull request", aga otsustasin lõpuks mõnes kohas fraasid inglise keelde tagasi tuua, et vähendada tekstis hulluse taset. Kasutan mõnikord "arendaja slängi" nagu kummalist verbi "commitida" seal, kus inimesed tegelikult tööl seda kasutavad.

Mis on pidev integreerimine?

Pidev integreerimine, või CI, on tehniline praktika, kus iga tiimi liige integreerib oma koodi ühisesse hoidlasse vähemalt kord päevas, samas peab tulemuseks olev kood vähemalt koguma ilma vigadeta.

Selle termini osas on erinevaid tõlgendusi.

Vaidluse all on integreerimise sagedus. Mõned väidavad, et koodi ühendamine vaid kord päevas ei ole piisav, tegelikult tuleb integreeruda pidevalt. Näiteks tuuakse välja meeskond, kus kõik võtavad hommikul värske koodi ja integreeruvad õhtul ühe korra. Kuigi see on mõistlik vastuväide, peetakse siiski laiemalt, et määratlemise variandi "kord päevas" kasutamine on piisavalt praktiline, konkreetne ja sobib erineva suurusega meeskondadele.

Teine vastuväide on see, et C++ ei ole enam ainus keel, mida arenduses kasutatakse, ja lihtsalt nõue, et kogumine peab olema vigadeta, on nõrk. Teatud testide (nt üksustestid, mis toimuvad kohapeal) komplekt peaks samuti edukalt lõpule viidud olema. Hetkel kaldub kogukond arvama, et selline nõue peaks olema kohustuslik ja tulevikus "kogumine + üksustestid" saab ilmselt üldiselt aktsepteerituks, kui see ei ole juba juhtunud.

Pidev integreerimine erineb pidevast tarnimisest (Continuous Delivery, CD) sellega, et ei nõua iga integreerimistsükli järel vabanemis kandidaadi olemasolu.

Sammude loetelu, mida me kursuse jooksul kasutame.

1. Tõmmake uusim kood. Looge haru master. Alustage tööd.
2. Looge oma uuel harul commite. Koguge ja testige kohalikult. Läbikukkumine? Liikuge järgmise sammuni. Ebaõnnestumine? Parandage vead või testid ja proovige uuesti.
3. Pange oma kaug-hoidlas või kaug-harus.
4. Looge pull request. Arutage muutusi, lisage rohkem commite, kui arutelu kestab. Tehke testid edukaks funktsiooniharus.
5. Ühendage/rebase commite masterist. Tehke testid edukaks ühendamise tulemuse osas.
6. Paigaldage funktsiooniharu tootmisse.
7. Kui tootmises on kõik mõnda aega hästi, ühendage muudatused masterisse.

️ Valmistamine

Veenduge, et teil on vajalik tarkvara

Selle kursuse läbimiseks on teil vaja Node.js ja Git-klienti.

Võite kasutada ükskõik millist Git-klienti, kuid ma toon välja käsud ainult käsurea jaoks.

Veenduge, et teil on installitud Git-klient, mis toetab käsurea.

Kui teil pole veel installitud Git-klienti, mis toetab käsurea, võite leida installimisjuhised siin.

Valmistage hoidla ette

Teil on vaja luua isiklik koopia (fork) kursuse koodi mall-repositooriumist GitHubis. Leppigem kokku, et nimetame seda isiklikku koopiat kursuse hoidla.

Olete lõpetanud? Kui te ei ole vaikeseadeid muutnud, siis teie kursuse hoidla tõenäoliselt nimetatakse continuous-integration-team-scenarios-students, see asub teie GitHubi kontol ja URL näeb välja järgmine

https://github.com//continuous-integration-team-scenarios-students

Ma nimetan seda aadressi lihtsalt <URL репозитория>.

Nurgasulgude nagu <тут> tähendavad, et peate selle väljendi asendama vastava väärtusega.

Veenduge, et GitHub actions on aktiveeritud antud kursuse hoidlas. Kui need ei ole aktiveeritud, palun lülitage need sisse, klõpsates keskel asuvale suurele nupule, kuhu pääsete, klõpsates GitHubi liideses Actions.

Te ei saa kursust läbida, järgides minu juhiseid, kui GitHub Actions ei ole aktiveeritud.

Saate alati kasutada GitHubi võimet Markdownit väljastada, et näha praegust olekut nimekirjast, mida me siia kirjutame, siin

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Vastuste kohta

Kuigi parim viis selle kursuse lõpetamiseks on kõik ise teha, võivad tekkida raskused.

Kui teil on tunne, et ei saa aru, mida teha ja ei suuda edasi liikuda, võite piiluda harusse lahendus, mis on teie alghoidlas.
Palun ärge tehke ühinemisi lahendus ja master kursuse ajal. Saate seda haru kasutada, et aru saada, mida teha, või oma koodi autori omaga võrrelda, kasutades kõiki Git'i võimalusi. Kui olete täiesti segaduses, saate täielikult asendada oma haru master haru lahendus ja seejärel taastada oma töökausta sellele kursuse sammule, mida vajate.

Kasutage seda ainult siis, kui see on tõeliselt vajalik

Tehke oma koodist commit

git add .
git commit -m "Minu töö varundamine"

Need käsud

• nimetavad ümber master ja master-backup;
• nimetavad ümber lahendus ja master;
• vahetavad (checkout) uuele harule master ja kirjutavad töötava katalooge sisu ümber;
• loovad haru "lahendus" harust "master" (mis varem oli "lahendus") juhuks, kui teil on tulevikus "lahenduse" haru vaja.

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

Pärast neid toiminguid saate kasutada git log master et välja selgitada, milline commit on vajalik.
Saate oma töökausta selle commit'i peale tagasi seadistada järgmiselt:

git reset --hard

Kui olete tulemusega rahul, siis varem või hiljem peate oma repositooriumi versiooni avaldama kaug- (remote) repositooriumisse. Ärge unustage selgelt määrata kaug- haru, kui te seda teete.

git push --force origin master

Palun pange tähele, et me kasutame git push --force. Harva soovite nii käituda, kuid meil on siin äärmiselt spetsiifiline stsenaarium, kus ühel repositooriumi kasutajal on arusaam, mida ta teeb.

Alustame töötamist

Alustame oma CI sammude nimekirja koostamist. Tavaliselt alustate seda sammu koodi viimase versiooni allalaadimisega kaug-repositooriumist, kuid meil ei ole veel kohalikku repositooriumi, seega kloonime selle kaug- repositooriumist.

️ Ülesanne: värskendage kohalikke repositooriume, looge haru master, alustage töötamist

1. Kloonige kursuse repositoorium aadressilt <URL репозитория>.
2. Käivitage npm install kursuse repositooriumi kataloogis; see on vajalik, et installida Jest'i, mida me kasutame testide käitamiseks.
3. Looge haru ja nimetage see feature. Vahetage sellele harule.

4. Lisage testikood ci.test.js kommentaaride vahele palvega seda teha.

   it('1. tõmba uusim kood', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. lisa commitid', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. puskige sama nimega kaug-haru', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. looge tõmbepäring ja jätkake töötamist', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Lisage tekst koos esimeste 4 sammudega faili ci.md.

   1. Tõmmake uusim kood. Looge haru `master`. Alustage töötamist.    
   2. Looge uuel harul commitid. Koguge ja testige kohapeal.  
   Pass? Minge järgmisele sammale. Ebaõnnestus? Parandage vead või testid ja proovige uuesti.  
   3. Puskige oma kaug-repositooriumisse või kaug-harusse.  
   4. Looge tõmbepäring. Arutage muudatusi, lisage rohkem commit'e  
   järgnevate arutelude käigus. Veenduge, et testid õnnestuvad funktsiooniharus.  

   Käsklused

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

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

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

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

Looge commitid uuel harul, koguge ja testige kohapeal

Kavatseme seadistada testide käitamiseks enne commitimist, ja seejärel kood kokku panna.

Tüüpilised stsenaariumid, kui testid käivitatakse automaatselt

• Kohapeal:
  • Pidevalt või vastuseks vastavatele muudatustele koodis;
  • Salvestamisel (interpreteeritavates või JIT-kompileeritud keeltes);
  • Kogumisel (kui nõutakse kompileerimist);
  • Commitimisel;
  • Avaldamisel avalikku repositooriumisse.

• Kogumiserakenduses (build server) või kogumise keskkonnas:
  • Kui kood avaldatakse isiklikule harule / repositooriumile.
  • Testitakse koodi selles harus.
  • Testitakse potentsiaalset sulandumist (tavaliselt koos master).
  • Jätkuva integreerimine / pidev kohaletoimetamise toru etapp

Reeglina, mida kiiremini testide komplekt täidetakse, seda sagedamini saate endale lubada selle käivitamist. Tüüpiline etappide jaotus võib välja näha selline.

• Kiirete üksuste testid - ehituse ajal, CI torus
• Aeglased üksuste testid, kiired komponentide ja integreerimistestid - commit'i ajal, CI torus
• Aeglased komponentide ja integreerimistestid - CI torus
• Turvatestimine, koormustestid ja muud pikad või kulukad testid - CI/CD torudes, kuid ainult teatud režiimides / etappides / ehitustoru, näiteks väljalaske kandidaadi ettevalmistamisel või käsitsi käivitamisel.

️ Ülesanne

Ma soovitan alustada testide käsitsi käivitamist, kasutades käsku npm test. Pärast seda lisame git hook'i, et käivitada meie testid commit'ide ajal. On üks nüanss: Git hook'id ei loeta osa repost ning seetõttu ei saa neid koos muu kursuse materjaliga GitHubist kloonida. Hook'i seadmiseks peate käivitama install_hook.sh või kopeerima faili repo/hooks/pre-commit kohalikku kataloogi .git/hooks/.
Commit'i ajal näete, et testid käivitatakse ja kontrollivad, kas loendis on teatud võtmesõnad.

1. Käivitage testid käsitsi, käivitades käsk npm test oma kursuse reposti kataloogis. Veenduge, et testid oleksid läbi viidud.
2. Seadistage commit hook (pre-commit hook), käivitades install_hook.sh.
3. Commitige muudatused kohalikku reposse.
4. Veenduge, et testid käivad enne commit'i.

Teie repo peaks pärast nende toimingute tegemist välja nägema selline.

Käsklused

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

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

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

Avaldage kood eemalolekusse reposse või eemalsele harule

Kui arendajad lõpetavad kohalikku tööd, teevad nad tavaliselt oma koodi avalikuks, et seda saaks lõpuks ühendada üldise kogumiga. GitHubis saavutatakse see tavaliselt töö avaldamisega kas isiklikus repo koopias (personal fork) või isiklikul harul.

• Forkide töötamisel kopeerib arendaja kaugserveri ühise hoidla, luues oma isikliku kaugkapi, mida tuntakse ka kui fork. Seejärel kloonib ta selle isikliku hoidla, et töötada selle kallal kohalikult. Kui töö on lõpetatud ja commitid loodud, paneb ta need oma forki, kus need on teistele kättesaadavad ja neid saab integreerida üldisesse hoidlasse. Seda lähenemist kasutatakse sageli avatud lähtekoodiga projektides GitHubis. Seda kasutatakse ka minu laiendatud kursusel [Team Work and CI with Git]http://devops.redpill.solutions/).
• Teine lähenemine on kasutada ainult ühte kaughoidlat ja pidada ainult haru master koos jagatud hoidla "kaitstud". Sellises stsenaariumis avaldavad eraldi arendajad oma koodi kaughoidla harudes, et teised saaksid seda koodi vaadata; kui kõik on korras, ühendada master üldise hoidla.

Selles konkreetses kursuses kasutame harude lähenemist.

Avaldame oma koodi.

️ Ülesanne

• Avaldage muudatused kaugusele harule, mille nimi on sama mis teie tööhara

Käsklused

git push --set-upstream origin feature

Looge pull request

Looge pull request pealkirjaga Sammude ülevaade. Määrake feature kui "head branch" ja master kui "base branch".

Veenduge, et olete määranud master oma forgis hoidlast kui "base branch", ma ei vasta kursuse materjalide hoidlasse esitatud muudatuste päringutele.

GitHubi slängis on "base branch" haru, mille alusel te oma tööd alustate, ja "head branch" on haru, mis sisaldab pakutavaid muudatusi.

Arutage muudatusi, lisage uusi commit’e arutelude käigus

Pull request (PR)

Pull request (PR) on viis, kuidas arutada ja dokumenteerida koodi, samuti teha koodile ülevaatus (code review). Pull request on nimetatud selle nime tõttu, kuidas eraldi muudatusi tavaliselt üldise koodi integreeritakse. Tavaliselt kloonib inimene kaugserveri ametliku projekti hoidla ja töötab koodiga kohaliku arvutiga. Seejärel paneb ta koodi oma isiklikku kaughoidlasse ja palub ametliku hoidla vastutajatel võttapull) tema koodi oma kohalikesse hoidlatesse, kus nad vaatavad ja võimalusel integreerivadmerge) selle. Seda mõistet tuntakse ka teiste nimede all, näiteks merge request.

Tõepoolest, teil ei ole vaja kasutada GitHubi pull request'i funktsiooni või muid sarnaseid platvorme. Arendajate meeskonnad võivad kasutada muid suhtlemisviise, sealhulgas isiklikke kohtumisi, telefonikõnesid või e-kirju, kuid on siiski mitmeid põhjuseid, miks kasutada selliseid pull request'e, mis sarnanevad foorumikesksete aruteludega. Siin on mõned neist:

• korraldatud arutelud, mis on seotud konkreetsete muudatustega koodis;
• koht, kus vaadata tagasisidet lõpetamata töö osas nii automaattestide kui kolleegide poolt;
• koodi kontrollimise formaliseerimine;
• et hiljem oleks võimalik välja selgitada põhjused ja kaalutlused, mis seisavad selle või selle koodilõigu taga.

Tavaliselt loote pull request'i, kui peate midagi arutama või tagasisidet saama. Näiteks kui töötate funktsiooni kallal, mis võib olla teostatav mitmel viisil, võite luua muudatuste taotluse juba enne esimese koodirida kirjutamist, et jagada oma ideid ja arutada oma plaane kaasautoritega. Kui töö on lihtsam, avatakse pull request siis, kui midagi on juba valmis, fikseeritud ja arutatav. Mõnes stsenaariumis võite avada PR'i ainult kvaliteedikontrolli kaalutlustel: et käivitada automaatseid teste või algatada koodi ülevaatus. Mis iganes te otsustate, ärge unustage @mainida inimesi, kelle heakskiit on teie pull request'is vajalik.

Tavaliselt PR'i loomisel teete järgmist.

• Näitate, mida soovite muuta ja kus.
• Kirjutate kirjelduse, mis selgitab muudatuste eesmärki. Võite soovida:
  • lisada midagi olulist, mis ei ole koodist ilmne, või midagi kasulikku, et mõista konteksti, näiteks asjakohased #vead ja commit-numbrid;
  • @mainida kõiki, kellega soovite koostööd alustada, või võite neid hiljem kommentaarides @mainida;
  • paluda kolleegidel aidata millegi või konkreetse ülevaatamisega.

Pärast PR'i avamist käivitatakse testid, mis on seadistatud selliste toimingute jaoks. Meie puhul on see sama testide komplekt, mida me kohalikult käivitasime, kuid reaalsetes projektides võivad olla täiendavad testid ja kontrollid.

Palun oodake, kuni testid on lõpule viidud. Te saate näha testide olekut PR arutelu alumises osas GitHubi liidese kaudu. Jätkake, kui testid on lõpetatud.

️ Lisage märkimus CI etappide suvalisusest

Kursuses kasutatud loetelu on suvaline ja subjektiivne, peame sellele märkusele lisama.

️ Ülesanne: pull requesti loomine seda märkust silmas pidades

1. Lülituge harule master.
2. Looge haru nimega bugfix.
3. Lisage märkuse tekst faili lõppu ci.md.

   > **GitHubi voog** kasutatakse mõnikord hüüdnimeks, et viidata trunk-põhisele arendamise eri vormile, 
   kuna kood on otse funktsiooniharu kaudu juurutatud. See loetelu on lihtsalt tõlgendus, 
   millega ma oma [DevOps kursustes](http://redpill.solutions) töötan. 
   Ametlik õpetus on [siin](https://guides.github.com/introduction/flow/).

4. Tehke muudatused commitida.
5. Avaldage haru bugfix kaugseifisse.
6. Looge pull request nimega Märgise lisamine peaharuga bugfix ja baasigamaster.

Veenduge, et olete määranud master oma forgis hoidlast kui "base branch", ma ei vasta kursuse materjalide hoidlasse esitatud muudatuste päringutele.

Nii peaks teie repository välja nägema.

Käsklused

# Переключитесь на ветку 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 как описано выше

Kinnitage pull request "Märgise lisamine"

️ Ülesanne

1. Looge pull request.
2. Klõpsake "Merge pull request".
3. Klõpsake "Kinnita liitmine".
4. Klõpsake "Kustuta haru", me ei vaja seda enam.

See on commitide diagramm pärast liitmist.

️ Jätkake töötamist ja testide lisamist

Pull requestide koostööduel võib sageli nõuda täiendavat tööd. See on tavaliselt koodivaatamise või arutelu tulemus, kuid meie kursusel kavatseme simuleerida seda, lisades uusi elemente meie CI sammude loetellu.

Jätkuva integreerimise korral rakendatakse tavaliselt mingit testimist. Testimise katmise nõudmised erinevad ja on reeglina dokumentides, mille pealkiri on näiteks "autorite juhend" (contribution guidelines). Me teeme selle lihtsalt ja lisame iga rea jaoks meie kontroll-loendis ühte testi.

Ülesande täitmisel proovige kõigepealt testid commitida. Kui olete õigesti seadistanud pre-commit hook'i varem, just lisatud test käivitatakse, ei läbita ja midagi ei commitita. Pange tähele: seeläbi saame teada, et meie testid tegelikult midagi kontrollivad. Huvi pärast, kui oleksime alustanud koodiga enne teste, võiks testide läbimine tähendada, et kas kood töötab nii nagu eeldatud, või et testid tegelikult midagi ei kontrolli. Lisaks, kui me ei oleks esimesena teste kirjutanud, võiksime need üldse unustada, kuna miski ei meenutaks meile sellest.

Testimise kaudu arendamine (TDD)

TDD soovitab kirjutada testid enne koodi. Tavaline tööprotsess TDD kasutamisel näeb välja järgmine.

1. Lisa test.
2. Käivita kõik testid ja veendu, et uus test ei õnnestu.
3. Kirjuta kood.
4. Käivita testid, veendu, et kõik testid õnnestuvad.
5. Tee koodi refaktooring.
6. Korda.

Kuna testide tulemused, mis ei õnnestu, kuvatakse tavaliselt punasena ning edukalt läbitud testid rohelisena, tuntakse seda tsüklit ka kui "punane-roheline-refaktooring".

️ Ülesanne

Esmalt proovi commitida testid ja lase neil ebaõnnestuda, seejärel lisa ja commitige CI sammude tekst. Sa näed, et testid õnnestuvad ("rohelised").
Seejärel avalda uus kood kaugreposiitari ja vaata, kuidas testid käivituvad GitHubi arutelu akna all ja PR staatus uuendatakse.

1. Lülituge harule feature.

2. Lisa need testid ci.test.js pärast viimast kutset it (...);.

   it('5. Ühenda/rebase kommid masterist. Tee testid ühinemisel õnnestuma.', () => {
     expect(/.*merge.*commits.*testid.*õnnestuma.*\/ig.test(failiSisu)).toBe(true);
   });
   
   it('6. Avalda funktsiooni haru tootmisesse.', () => {
     expect(/.*Deploy.*tootmisse.*\/ig.test(failiSisu)).toBe(true);
   });
   
   it('7. Kui kõik on tootmises mõne aja jooksul hästi, ühenda muudatused masterisse.', () => {
     expect(/.*merge.*masterisse.*\/ig.test(failiSisu)).toBe(true);
   });

3. Proovi commitida testid. Kui pre-commit hook on seadistatud, lõpeb commitimise katse veaga.
4. Seejärel lisa see tekst ci.md.

   5. Ühenda/rebase kommid masterist. Tee testid ühinemisel õnnestuma.  
   6. Avalda funktsiooni haru koos peidetud veaga tootmisesse.  
   7. Kui kõik on tootmises mõne aja jooksul hästi, ühenda muudatused masterisse. 

5. Teosta ja commitige muudatused lokaalselt.
6. Avalda muudatused harusse feature.

Nüüd peaks sul olema midagi sellist

Käsklused

# Переключительна ветку 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

Ühinemis konflikt

Mine muudatuste taotlusele Sammude ülevaade.

Kuigi me ei ole midagi halba teinud ja meie koodi testid õnnestu, ei saa me ikkagi haru ühendada. feature ja master. See on, sest teine haru bugfix oli ühendatud master samal ajal, kui me töötasime selle PR-i kallal.
See loob olukorra, kus kaug harul master on uuem versioon kui see, mille peal me töötasime. feature. Seetõttu ei saa me lihtsalt HEAD-i tagasi kerida master kuni haru lõpuni. feature. Sellises olukorras peame kas tegema ühenduse (merge) või rakendama commite feature üles (rebase). masterGitHub suudab tegelikult automaatselt liita, kui konflikte pole. Kahjuks on meie olukorras mõlemal harul failis vastandlikud muudatused. ci.mdSeda olukorda tuntakse kui ühenduskonflikt (merge conflict) ja peame selle käsitsi lahendama.

Merge või rebase

Merge

• Loo täiendav ühenduskommentaar (merge commit) ja salvesta töö ajalugu.
  • Salvestab algsed kommid harude algsete ajatempleid ja autoritega.
  • Salvestab edastatud kommid ja lingid neile muudatuste taotlemise aruteludes.
• Nõuab konfliktide ühekordset lahendamist.
• Teeb ajaloo mittelineaarsseks.
  • Ajalugu võib olla raske lugeda liiga paljude harude tõttu (meenutab IDE kaablit).
  • Raskendab automaatset silumist, näiteks muudab git bisect vähem kasulikuks – see leiab ainult ühenduskommi.

Rebase

• Korrastab kommid praegusest harust baasi kohal ükshaaval.
  • Luues uusi komme uute SHA-dega, seega kommid GitHubis vastavad algsetele pull requestidele, kuid mitte vastavatele kommentaaridele.
  • Kommid võivad protsessi käigus ümber kombineerida ja muuta või isegi kokku liita.
• Võib osutuda vajalikuks lahendada mitu konflikti.
• Lubab säilitada lineaarsuse ajaloos.
  • Ajalugu võib olla lihtsam lugeda, kui see ei ole liiga pikk mõistlikel põhjustel.
  • Automaatne silumine ja tõrkeotsing on veidi lihtsam: teeb võimalikuks git bisect, võib muuta automaatsed tagasiviimised selgemaks ja ettearvatavamaks.
• Nõuab avaldamist harule koos liigutatud kommidega lipuga --force koos muudatuste taotlemisega.

Tavaliselt lepivad meeskonnad kokku alati sama strateegia kasutamises, kui nad peavad muutusi ühendama. See võib olla "puhas" liitmine või "puhas" kommide kohandamine üle või midagi vahepealset, nagu näiteks yapmak kommid üle interaktiivses režiimis (git rebase -i) kohalikult harude jaoks, mis ei ole avalikus hoidlas, kuid liitmine avalikele harudele.

Siin kasutame liitmist.

️ Ülesanne

1. Veenduge, et kood kohalikus harus master on värskendatud kaughoidlast.
2. Lülituge harule feature.
3. Käivitage liitmine haruga master. Teavitatakse liitumise konfliktist, mis on seotud vastandlike muudatustega. ci.md.
4. Lahendage konflikt nii, et meie CI sammude nimekiri ja selle märkused jäävad tekstis alles.
5. Avaldage sulandumiskommi kaug-oksas. feature.
6. Kontrollige GitHubi kasutajaliideses pull requesti olekut ja oodake, kuni sulandumine on lahendatud.

Käsklused

# Убедитесь, что код в локальное ветке `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, дождитесь пока слияние не будет разрешено.

Suurepärane töö!

Olete nimekirjaga lõpetanud ja nüüd peate kinnitama pull requesti. master.

️ Ülesanne: Kinnitage pull request "Steps review".

1. Avage pull request.
2. Klõpsake "Merge pull request".
3. Klõpsake "Kinnita liitmine".
4. Klõpsake "Delete branch", kuna me ei vaja seda enam.

See on teie hoidla praeguses olekus.

Viga tootmises.

Räägitakse, et "katsetamist saab kasutada vigade olemasolu näitamiseks, kuid mitte nende puudumise näitamiseks". Kuigi meil olid testid ja need ei näidanud meile mingeid vigu, hiilis kaval viga tootmisse.

Sarnases stsenaariumis peame hoolitsema järgmise eest:

• kõige üle, mis on tootmises;
• koodi haru üle, master millel on viga, millest arendajad saavad uut tööd alustada.

Kas taandada või parandada järgmises versioonis?

"Tagasiviimine"(rolling back) on varasema teadaolevalt vigadeta versiooni häälestamine tootmisemajandusse ja tõrgete sisaldavate kommiteerimise tühistamine. "Parandamine järgmises versioonis"(fixing forward) on paranduse lisamine ja master uus versioon võimalikult kiiresti kasutusele võtta. Kuna API'd ja andmebaaside skeemid muutuvad koodi tootmisemajanduses juurutamisel, on pideva kohaletoimetamise ja hea katvusega testidega tagasiviimine tavaliselt palju keerulisem ja riskantsem kui parandamine järgmises versioonis.

Kuna tagasiviimine ei too meie puhul mingeid riske, valime selle tee, kuna see võimaldab meil

• parandada viga tootmises võimalikult kiiresti;
• teha koodi master kohe uue töö alustamiseks sobivaks.

️ Ülesanne

1. Lülituge harule master kohalikult.
2. Uuendage kohalikku hoidlat kaug-hoidlast.
3. Tühistage pull requesti sulandumiskommi. Sammude ülevaade ja master.
4. Avaldage muudatused kaughoidlasse.

See on hoidla ajalugu sulandumiskommi tühistamisega.

Käsklused

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

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

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

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

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

️ Enese kontroll.

Veenduge, et ci.md ei sisaldaks enam teksti "sneaky bug" pärast sulandumiskommi tühistamist.

Parandage CI sammude nimekiri ja tagastage see masterisse.

Oleme täielikult tühistanud haru sulandumiskommi. feature. Hea uudis on see, et nüüd pole meil viga. master. Halb on halbu uudiseid, et meie väärtuslik pideva integratsiooni sammude nimekiri on kadunud. Seega, ideaalis peame me rakendama parandusi commit'ide suhtes, feature ja tooma need tagasi master koos parandustega.

Võime läheneda ülesandele erinevalt:

• tühistades (revert) commit, mis tühistab merge'i feature jot master;
• liigitama commit'id endisest feature.

Erinevad arendustiimid kasutavad antud juhul erinevaid lähenemisi, meie liigume eduka commit'iga eraldi harusse ja loome selle uue haru jaoks eraldi pull request'i.

️ Ülesanne

1. Looge haru nimega feature-fix ja lülitage see sisse.

2. Liigutage kõik commit'id endisest harust feature uude harusse. Lahendage ühinemis konfliktid, mis tekkisid selle liigutamise ajal.

   

3. Lisage regressioonitest ci.test.js:

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

4. Käitage testid kohaliku masinaga, et veenduda, et need ei lõppe edukalt.
5. Eemaldage tekst " with a sneaky bug" ci.md.
6. Lisage indeksi muutused testides ja muudatused sammude nimekirjas ja commit'ige need.
7. Avaldage haru kaugserverisse.

Kasutajatel peaks olema midagi sarnast

Käsklused

# Создайте ветку под названием 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

Looge pull request.

Looge pull request pealkirjaga Fixing the feature. Määrake feature-fix nagu "head branch", ja master kui "base branch".
Palun oodake, kuni testid on lõpule viidud. Saate näha testide staatust PR arutelu allosas.

Veenduge, et olete määranud master oma forgis hoidlast kui "base branch", ma ei vasta kursuse materjalide hoidlasse esitatud muudatuste päringutele.

Kinnitage pull request "Fixing the feature"

Aitäh paranduse eest! Palun kinnitage muudatused master pull request'ist.

️ Ülesanne

1. Klõpsake "Merge pull request".
2. Klõpsake "Kinnita liitmine".
3. Klõpsake "Delete branch", kuna me ei vaja seda enam.

See on see, mis teil hetkel peaks olema

Palju õnne!

Olete teinud kõik toimingud, mida inimesed tavaliselt teevad pideva integratsiooni protsessis.

Kui te märkate kursuse osas mingeid probleeme või teate, kuidas seda parandada, looge issue kursuse materjalide hoidlas.Sellel kursusel on ka interaktiivne versioon millel on GitHub Learning Labi platvormi kasutamine.

Allikas: habr.com