Olete uurinud Git'i käsklusi, kuid soovite aru saada, kuidas pidev integreerimine (Continuous Integration, CI) reaalsuses toimub? Või võib-olla soovite optimeerida oma igapäevaseid tegevusi? See kursus annab teile praktilised oskused pideva integreerimise valdkonnas, kasutades GitHubi hoidlat. Kursus ei ole mõeldud lihtsalt juhendi, mida klikkida, vastupidi, teete samu toiminguid, mida inimesed reaalselt töötavad, täpselt nii, nagu nad seda teevad. Selgitan teooriat, kui läbite vastavad sammud.

Mida me teeme?

Protsessi käigus koostame järk-järgult tüüpiliste CI sammude loendi, mis on suurepärane viis selle loendi meeldejätmiseks. Teisisõnu, loome tegevuste nimekirja, mida arendajad teevad pideva integreerimise elluviimisel. Samuti kasutame lihtsat testide komplekti, et viia meie CI protsess lähemale reaalsusele.

See GIF illustreerib teie repozitooriumi committe, kui te kursusel edasi liigute. Nagu näete, pole siin midagi keerulist, vaid ainult vajalikud asjad.

Te läbite selliseid CI-standardeid stsenaariume:

• Funktsiooni arendamine;
• Automaatsete testide rakendamine kvaliteedi tagamiseks;
• Prioriteetse ülesande teostamine;
• Filiaalide ühinemise konflikti lahendamine (merge conflict);
• Viga tootmises.

Mida te õpite?

Te saate vastata sellistele küsimustele:

• Mis on pidev integreerimine (CI)?
• Milliseid automaatseid teste kasutataks CI-s ja millistele tegevustele need käivitatakse?
• Mis on pull request ja millal need on vajalikud?
• Mis on testipõhine arendus (Test Driven Development, TDD) ja kuidas see seondub CI-iga?
• Teha ühinemine (merge) või rakendada muudatusi (rebase)?
• Tagasi võtta või parandada järgmises versioonis?

Alguses tõlkisin ma igal pool asju nagu "pull request", kuid lõpuks otsustasin mõnes kohas ingliskeelsed fraasid tagasi tuua, et tekstis olevat segadust vähendada. Mõnikord kasutan ma "programmistikuri" nagu toredat verbi "commitida", kus inimesed tegelikult töö juures seda kasutavad.

Mis on pidev integreerimine?

Jätkuv integreerimine, või CI, on tehniline praktika, kus iga meeskonna liige integreerib oma koodi ühisse, vähemalt üks kord päevas, ning tulemuseks olev kood peab olema vähemalt tõrkedeta kompileeritav.

Selle termini osas on erinevaid tõlgendusi

Vaieldavaks küsimuseks on integreerimise sagedus. Mõned väidavad, et koodi ühendamine vaid kord päevas ei ole tegelikult pidev integreerimine. Näiteks tuuakse välja meeskond, kus kõik võtavad hommikul värske koodi ja integreerivad seda üks kord õhtul. Kuigi see on mõistlik vastuväide, peetakse siiski üldiselt, et määratlemine 'kord päevas' on piisavalt praktiline, konkreetne ja sobib erineva suurusega meeskondadele.

Teine vastuväide on see, et C++ ei ole enam ammu ainus keel, mida arengus kasutatakse, ja lihtne nõue veatu koostamise kohta, kui valideerimise viis, tundub nõrk. Teatud testide kogum (näiteks üksustestid, mis käivitatakse kohapeal) peab samuti edukalt lõpule viima. Hetkel kalduvad kogukonna liikmed sellele, et see nõue muutuks kohustuslikuks, ja tulevikus näib, et "koostamine + üksustestide" kombinatsioon muutub tavapäraseks, kui see ei ole juba juhtunud.

Jätkuv integreerimine erineb järjepidevast tarnimisest (Continuous Delivery, CD) selle poolest, et see ei nõua igas integratsioonitsüklis kandidaati väljalaskmiseks.

Sammude nimekiri, mida me kursuse jooksul kasutame

1. Tõmmake uusim kood. Looge haru master. Alustage töötamist.
2. Looge oma uuel harul commit'id. Koostage ja testige kohapeal. Läbige? Liikuge järgmise sammu juurde. Ebaõnnestuge? Parandage vead või testid ja proovige uuesti.
3. Pange oma kaughoidlasse või kaugharu.
4. Looge tõmbepäring. Arutage muudatusi, lisage arutelus jätkuvalt uusi commit'e. Veenduge, et testid lähevad läbi funktsiooniharus.
5. Ühendage/masterist commit'id. Veenduge, et testid lähevad läbi ühendamise tulemuse peal.
6. Käivitage funktsiooniharust tootmisse.
7. Kui kõik on tootmises mõne aja jooksul hea, ühendage muudatused masteriga.

️ Valmistamine

Veenduge, et vajalik tarkvara on olemas

Kursuse läbimiseks vajate Node.js ja Git-klienti.

Saate kasutada ükskõik millist Git-klienti, kuid ma annan käsud ainult käsureale.

Veenduge, et teil oleks installitud käsureaga Git-klient.

Kui teil pole veel installitud käsureaga Git-klienti, leiate installimise juhised. siit.

Valmistage ette oma hoidla.

Peate looma isikliku koopiaga (fork) kursuse koodide šablooni hoidlast GitHubis. Kutsume seda isiklikku koopiat kursuse hoidla nimeks..

Tehtud? Kui te ei ole vaikeseadeid muutnud, siis teie kursuse hoidla nimi on tõenäoliselt continuous-integration-team-scenarios-students.See asub teie GitHubi kontol ja URL näeb välja selline:

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

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

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

Veenduge, et GitHub actions on sisselülitatud selle kursuse hoidla jaoks. Kui need pole sisse lülitatud, palun aktiveerige need, vajutades suurtele nupule lehe keskel, kuhu pääsete, klikkides GitHubi liideses Actions.

Te ei saa kursusest läbi minna, järgides minu juhiseid, kui GitHub Actions ei ole aktiveeritud.

Sa saad alati kasutada GitHubi võimet Markdown'i kuvamiseks, et näha olemasolevat nimekirja, mille me siin kokku paneme.

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

Küsimused

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

Kui tunned, et ei saa aru, mida teha, ja ei saa edasi liikuda, võid vaadata haru solution, mis on sinu algses reposis olemas.
Palun ära tee ühinemisi solution ühes master kursuse ajal. Sa saad kasutada seda haru, et aru saada, mida teha, või et võrrelda oma koodi autorikoodiga, kasutades kõiki, mida Git meile pakub. Kui oled täiesti eksinud, võid oma haru täielikult asendada master haruga solution ja seejärel taastada oma töökausta sel tasemele, mis sul kursusest vajalik on.

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

Kinnita oma kood

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

Need käsud

• edasinimenevad master ühes master-backup;
• edasinimenevad solution ühes master;
• lülituvad (checkout) uuele harule master ja kirjutatakse töökausta sisu ümber;
• looge haru "solution" harust "master" (mis varem oli "solution"), juhuks kui teil peaks tulevikus haru "solution" vaja minema.

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

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

git reset --hard

Kui olete tulemusega rahul, peate mingil hetkel oma hoidla versiooni avaldama kaughoidlas (remote). Ära unusta selgelt märkida kaugusharu, kui seda teed.

git push --force origin master

Palun pange tähele, et me kasutame git push --force. Vähestel juhtudel võib teil seda soovida, kuid meil on väga spetsiifiline stsenaarium ühe hoidla kasutajaga, kes naabrilt, teab, mida ta teeb.

Alustame tööd

Alustame meie CI sammude loetelu koostamist. Tavaliselt alustate seda sammu, tõmmates viimase koodi versiooni kaughoidlast, kuid meil ei ole veel lokaalset hoidlat, seega kloonime selle kaugelt.

️ Ülesanne: värskendage kohalikku hoidlat, looge haru master, alustage tööd

1. Kloonige kursuse hoidla <URL репозитория>.
2. Käivitage npm install kursuse hoidla kataloogis; seda on meil vaja Jest'i installimiseks, mida kasutame testide käivitamiseks.
3. Looge haru ja nimetage see feature. Lülitage sellele harule.

4. Lisage testikood ci.test.js kommentaaride vahele, paludes seda teha.

   it('1. tõmmake uusim kood', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. lisage kommid', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. pushige kaug- harule sama nimega', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. looge pulli taotlus ja jätkake tööd', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Lisage teksti esimestest 4 sammast faili ci.md.

   1. Tõmmake uusim kood. Looge haru `master`-ist. Alustage tööd.    
   2. Looge oma uuel harul kommid. Koguge ja testige kohapeal.  
   Eksamiküsimus? Minge järgmisse sammu. Ebaõnnestumine? Parandage vead või testid ja proovige uuesti.  
   3. Pushige oma kaug-hoidlasse või kaug-harul.  
   4. Looge pulli taotlus. Arutage muutusi, lisage rohkem komme  
   arutelu jätkudes. Laske testidel feature harul läbida.  

   Meeskonnad

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

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

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

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

Looge kommid uues harus, tehke kogumine ja testimine kohapeal.

Kavatseme seadistada testid, et need käivituksid enne kommit, ja seejärel koodi kommitida.

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

• Kohapeal:
  • Pideva või vastusena koodi vastavatele muudatustele;
  • Salvestamise ajal (interpreteeritud või JIT-kompileeritavate keelte puhul);
  • Kokku kogumise ajal (kui vajatakse kompileerimist);
  • Komiteerimise ajal;
  • Avalikustamine ühisesse reposse.

• Kogumise serveris või kogumise keskkonnas:
  • Kui kood avalikustatakse isiklikus haru / repos;
  • Kood testitakse selles harus.
  • Testitakse potentsiaalset sulandumist (tavaliselt koos) master).
  • Jätkuva integratsiooni / pideva tarnimise etappina

Üldiselt, mida kiiremini testide komplekt käivitatakse, seda sagedamini võite endale lubada selle käitamist. Tüüpiline jaotus etappide vahel võib olla järgmine.

• Kiired moodulitestid — kokku kogumise ajal, CI konveieris
• Aeglasemad moodulitestid, kiired komponendi- ja integratsioonitestid — komiteerimise ajal, CI konveieris
• Aeglasemad komponendi- ja integratsioonitestid — CI konveieris
• Turvatestimine, koormustestimine ja muud pikaajalised või kulukad testid — CI/CD konveierites, kuid ainult teatud režiimides/etappides/kogumise konveierites, näiteks väljaandekandidaadi ettevalmistamisel või käsitsi käivitamisel.

️ Ülesanne

Soovitame kõigepealt testid käsitsi käivitada, kasutades käsku npm test. Pärast seda lisame git hook'i, et testid käivituksid kohandamisel. On üks nüanss: Git hook'id ei ole osa repositooriumist, seega ei saa neid GitHubist koos teiste kursuse materjalidega klonida. Hook'i seadistamiseks peate käivitama install_hook.sh või kopeerima faili repo/hooks/pre-commit kohalikku katalooge .git/hooks/.
Kohandamisel näete, et testid käivitatakse ja need kontrollivad, kas loendis on teatud märksõnad.

1. Käivitage testid käsitsi, andes käsu npm test oma kursuse repositooriumi kaustas. Veenduge, et testid oleksid läbitud.
2. Seadistage kohandamise hook (pre-commit hook), käivitades install_hook.sh.
3. Tehke muudatused kohalikku repositooriumisse.
4. Veenduge, et testid käivitatakse enne kohandamist.

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

Meeskonnad

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

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

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

Kandke kood kaugrepositooriumisse või kaugfiliaali

Pärast kohalikku töötamise lõpetamist teevad arendajad oma koodi tavaliselt avalikuks, et see saaks lõpuks üldise projektiga integreeritud. GitHubi abil saavutatakse see tavaliselt töö avaldamise kaudu kas isiklikus repozitooriumis (personal fork) või eraldiseisvas harus.

• Forkide kasutamisel kloonib arendaja kaugjuhtimise all oleva üldise repozitooriumi, luues oma isikliku kaugklooni, mida nimetatakse ka forkkiks. Pärast seda kloonib ta selle isikliku repozitooriumi, et töötada sellega kohalikult. Kui töö on lõpetatud ja commit'id on loodud, laadib ta need oma forki, kus need on teistele kättesaadavad ning neid saab integreerida üldisse repozitooriumi. Seda lähenemist kasutatakse tavaliselt avatud lähtekoodiga projektides GitHubis. Seda kasutatakse ka minu edasijõudnud kursusel [Team Work and CI with Git]http://devops.redpill.solutions/).
• Teine lähenemisviis on kasutada ainult ühte kaugrepozitooriumi ja arvestada ainult haru master koostatud "turvalisest" hoiust. Sel juhul avaldavad erinevad arendajad oma koodi kaughoiustamise harudes, et teised saaksid seda koodi vaadata ja vajadusel ühendada. master ühiselt kasutatavast hoiust.

Selles konkreetses kursuses kasutame töövoogu harudega.

Avaldame meie koodi.

️ Ülesanne

• Avaldage muudatused kaugusele harule, mille nimi on sama mis teie töötamise haru.

Meeskonnad

git push --set-upstream origin feature

Looge pull request

Looge pull request pealkirjaga Steps review. Määrake feature nagu "head branch" ja master nagu "base branch".

Veenduge, et olete määranud master oma kloonis hoiust nagu "base branch", ma ei reageeri muudatusettepanekutele kursuse materjalidega koos hoius.

GitHubi slängis on "base branch" haru, millele oma töö rajate, ja "head branch" on haru, mis sisaldab pakutavaid muudatusi.

Arutage muudatusi, lisage uusi commit'e, kui arutelu jätkub

Pull request(PR)

Pull request(PR) — see on viis arutada ja dokumenteerida koodi ning teha koodivaatamist (code review). Pull request on nimetatud ühise viisi järgi eraldi muudatuste integreerimiseks üldisesse koodi. Üldiselt kopeerib inimene projektist kaugrepositooriumi ja töötab koodiga kohapeal. Pärast seda paneb ta koodi oma isiklikku kaugrepositooriumisse ja palub ametnike vastutajatele ametlikku repositooriumi, et võtta (pull) tema kood oma kohalikesse repositooriumitesse, kus nad vaatavad seda üle ja integriitrivad (merge) selle. Seda kontseptsiooni tuntakse ka teiste nimede all, nagu näiteks, merge request.

Tegelikult ei pea te kasutama GitHubi või sarnaste platvormide pull request funktsiooni. Arendajate meeskonnad võivad kasutada muid suhtlemisviise, sealhulgas isiklikku vestlust, kõnesid või e-posti, kuid on siiski rida põhjusi, miks kasutada selliseid pull requeste arutelu stiilis. Siin on mõned neist:

• korraldatud arutelud, mis on seotud konkreetsete muudatustega koodis;
• näiteks koht, kus vaadata tagasisidet lõpetamata töö kohta nii automaatsete testide kui ka kolleegide poolt;
• koodikontrollide formaliseerimine;
• et hiljem selgitada koodifragmentide taga olevaid põhjuseid ja kaalutlusi.

Tavaliselt loote pull request'i, kui peate midagi arutama või tagasisidet saama. Näiteks, kui töötate funktsiooni kallal, mida saab rakendada mitmel viisil, võite luua muudatusettepaneku juba enne esimese koodirea kirjutamist, et jagada oma ideid ja arutada oma plaane kaasautoritega. Kui töö on lihtsam, avatakse pull request, kui midagi on juba valmis, salvestatud ja arutamiseks ettenähtud. Mõnel juhul võite avada PR-i ainult kvaliteedikontrolli kaalutlustel: automaatsete testide käivitamiseks või koodi ülevaatamise algatamiseks. Olenemata teie valikutest, ärge unustage @mainida inimesi, kelle heakskiit on teie pull request'is vajalik.

Tavaliselt teete PR-i loomisel järgmist.

• Määrate, mida soovite muuta ja kus.
• Kirjutate kirjelduse, mis selgitab muudatuste eesmärki. Võite soovida:
  • lisage midagi olulist, mis ei ole koodist ilmselge, või midagi kasulikku konteksti mõistmiseks, näiteks seotud #vead ja commitide numbrid;
  • @mainige kõiki, kellega soovite koos töötada, või saate neid hiljem kommentaarides @mainida;
  • paluge kolleegidel aidata millegi või midagi konkreetset kontrollida.

Pärast PR-i avamist käivitatakse testid, mis on seadistatud sellele juhtumile. Meie puhul on see sama testide komplekt, mida me kohapeal jooksime, kuid reaalsetes projektides võivad olla lisatestid ja kontrollid.

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

️ Lisage märkuse kasutatavuse kohta CI sammude loendisse

Kursusel kasutatud loend on subjektiivne ja me peame sellest märkuse lisama.

️ Ülesanne: pull requesti loomine antud tähelepanekule

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

   > **GitHub flow** on mõnikord kasutatav hüüdnimi, et viidata trunk-põhisele arendusele, 
   kus kood läheb otse funktsioonivõrkudest. See nimekiri on lihtsalt tõlgendus, 
    mida kasutan oma [DevOps kursustes](http://redpill.solutions). 
   Ametlik õpetus on [siin](https://guides.github.com/introduction/flow/).

4. Tehke commit muutustest.
5. Avaldage haru bugfix kaugrepositoris.
6. Looge pull request nimega Lisades märkuse peaharuga bugfix ja baasiharugamaster.

Veenduge, et olete määranud master oma kloonis hoiust nagu "base branch", ma ei reageeri muudatusettepanekutele kursuse materjalidega koos hoius.

Nii peaks teie repositoorium välja nägema.

Meeskonnad

# Переключитесь на ветку 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 "Lisades märkuse"

️ Ülesanne

1. Looge pull request.
2. Kliki "Merge pull request".
3. Kliki "Confirm merge".
4. Kliki "Delete branch", me ei vaja seda enam.

See on diagramm commit'idest pärast ühinemist.

️ Jätkake töötamist ja lisage teste

Pull requestiga koostöös on sageli vajalik teha lisatööd. See on tavaliselt tingitud koodi ülevaatusest või arutelust, kuid meie kursusel simuleerime seda, lisades meie CI sammude loendisse uusi elemente.

Jätkuvas integreerimises rakendatakse tavaliselt mingisugust testimiskatvust. Testide katvuse nõuded varieeruvad ja need on tavaliselt dokumendis, mille nimi on midagi taolist nagu "autori juhend" (contribution guidelines). Me hakkame lihtsalt ja lisame igale meie kontrollnimekirja reele testi.

Töid ülesannete täitmise ajal proovige esmalt testid commitida. Kui olete õigesti seadistanud pre-commit hook'i, siis käivitatakse just lisatud test, see ei läbida ja midagi ei commitita. Pange tähele: nii saame teada, et meie testid tõepoolest midagi kontrollivad. Huvi pärast, kui me oleksime alustanud koodist enne teste, siis testide läbimine võiks tähendada kas seda, et kood töötab nagu oodatud, või et testid ei kontrolli tegelikult midagi. Lisaks, kui me ei oleks testide kirjutamisele esmakordselt mõelnud, võisime need sootuks unustada, kuna miski ei tuletaks meelde.

Testimise kaudu arendamine (TDD)

TDD soovitab kirjutada testid enne koodi. Tüüpiline TDD abil töötamise protsess näeb välja järgmine.

1. Lisage test.
2. Käivitage kõik testid ja veenduge, et uus test ei läbi edukalt.
3. Kirjutage kood.
4. Käivitage testid, veenduge, et kõik testid läbivad edukalt.
5. Refaktorige koodi.
6. Korrake.

Kuna testitulemused, mis ei ole edukalt läbitud, kuvatakse tavaliselt punaselt ja edukalt läbitud roheliselt, tuntakse seda tsüklit ka kui "punane-roheline-refaktoreerimine" (red-green-refactor).

️ Ülesanne

Proovige esmalt kommidade testid ja laske neil ebaõnnestuda, seejärel lisage ja kommidage CI sammu loetelu tekst. Näete, et testid läbivad ('rohelised').
Seejärel avaldage uus kood kaugrepositorioo ja vaadake, kuidas testid toimivad GitHubi liidese all pool muudatuste taotluse arutelu ning PR-i staatust uuendatakse.

1. Lülituge harule feature.

2. Lisage need testid ci.test.js pärast viimast väljakutset it (...);.

   it('5. Ühenda/rebase katked masterist. Veenduge, et testid õnnestuvad ühendamise tulemuses.', () => {
     expect(/.*merge.*commits.*tests+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Kasutage funktsiooniharu tootmiseks.', () => {
     expect(/.*Deploy.*to+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Kui tootmises on kõik mõne aja jooksul korras, ühenda muudatused masterisse.', () => {
     expect(/.*merge.*to+master.*/ig.test(fileContents)).toBe(true);
   });

3. Proovige testid kommidada. Kui pre-commit hook on sisse seatud, kommi katse lõpeb tõrkega.
4. Seejärel lisage see tekst ci.md.

   5. Ühenda/rebase commits masterist. Veendu, et testid läheksid pärast liitmist läbi.  
   6. Tõsta funktsiooniharu koos väikese veaga tootmisse.
   7. Kui tootmises on kõik mingil ajal korras, ühenda muudatused masteriga. 

5. Tehke muudatused ja tehke need kohaliku depoos kirjeldatuks.
6. Avaldage muudatused harusse feature.

Nüüd peaks teil olema midagi sellist nagu see

Meeskonnad

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

Liitmis konflikt

Liiguta muudatuste esitamise taotlusele Steps review.

Kuigi me ei teinud midagi halba ja meie koodi testid läbisid edukalt, ei saa me siiski haru liita feature ja master. See on sellepärast, et teine haru bugfix oli ühendatud master seni, kuni me töötasime selle PR-i kallal.
See loob olukorra, kus eemalolev haru master on uuem versioon kui see, millel me oma haru põhinesime feature. Seetõttu ei saa me lihtsalt HEAD-i tagasi kerida master haru lõpuni. feature. Sellises olukorras peame kas tegema liitumise (merge) või rakendama commit-e feature peale (rebase) master. GitHub suudab tegelikult automaatset liitumist teha, kui konflikte pole. Kahjuks on meie olukorras mõlemal harul failis konkurentsivõimelised muudatused ci.md. Seda olukorda tuntakse kui liitmis konflikt (merge conflict) ja me peame selle käsitsi lahendama.

Liitu või rebase

Ühenda

• Loob täiendava ühinemise kommi ja salvestab töö ajaloo.
  • Salvestab algsed kommid harude algsete ajatembrite ja autoritega.
  • Salvestab kommit SHA-d ja lingid nendele muudatuste päringute aruteludes.
• Nõuab ühekordset konfliktide lahendamist.
• Muudab ajaloo mittelineaarsena.
  • Ajalugu võib olla raske lugeda suurte harude arvu tõttu (meenutab IDE kaablit).
  • Tõukab automaatset tõrkeotsingut keerulisemaks, näiteks muudab git bisect vähem kasulikuks — see leiab ainult ühinemise kommi.

Rebase

• Toodab kommid praegusest harust üle baas ühe kaupa.
  • Kujunevad uued kommid uute SHA-dega, mille tulemusena kommid GitHubis vastavad algsetele tõmbe päringutele, kuid mitte vastavatele kommentaaridele.
  • Komme saab kombineerida ja muuta protsessi käigus või isegi ühendada üheks.
• Võib olla vajalik lahendada mitu konflikti.
• Lubab säilitada lineaarselt ajalugu.
  • Ajalugu võib olla lihtsam lugeda, kui see ei ole liiga pikk ilma tõsiste põhjusteta.
  • Automaatne tõrkeotsing ja probleemide lahendamine on veidi lihtsam: teeb võimalikuks git bisect, võib teha automaatsete tagasiviikude selgemaks ja ennustatavamaks.
• Nõutav on haru avaldamine koos edastatud commit’idega lipuga --force muudatusettepanekute kasutamisel.

Tavaliselt lepivad meeskonnad kokku alati kasutada sama strateegiat, kui neil on vaja muudatusi ühendama. See võib olla „puhas” ühinemine või „puhas” commit’ide rakendamine peal või midagi vahepealset, näiteks commit’ide rakendamine interaktiivses režiimisgit rebase -i) kohapeal harude jaoks, mis ei ole avalikus hoidlasse avaldatud, kuid ühendamine „avalike” harude jaoks.

Siin kasutame me ühinemist.

️ Ülesanne

1. Veenduge, et kood kohalikus harus master on uuendatud kaughoidlast.
2. Lülituge harule feature.
3. Initsieerige ühinemine haruga master. Ühinemise konfliktist, mis on seotud konkurseerivate muudatustega, antakse teada. ci.md.
4. Lahendage konflikt nii, et tekstis jääks peale meie CI sammude loendi ka märkus selle kohta.
5. Avaldage ühinemise commit kaug-haru. feature.
6. Kontrollige pull request’i staatust GitHubi kasutajaliideses, oodake, kuni ühinemine on lahendatud.

Meeskonnad

# Убедитесь, что код в локальное ветке `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 lõpetanud töö nimekirjaga ja nüüd peate kinnitama pull requesti master.

️ Ülesanne: Kinnitage pull request "Steps review"

1. Avage pull request.
2. Kliki "Merge pull request".
3. Kliki "Confirm merge".
4. Klõpsake "Delete branch", kuna see pole enam vajalik.

See on teie hoidla hetkel

Tootmises on viga

Kuidas öeldakse: "testimist saab kasutada, et tõestada vigade olemasolu, kuid mitte kunagi, et tõestada nende puudumist". Kuigi meil olid testid ja need ei tuvastanud mingeid vigu, on salakaval viga jõudnud tootmisse.

Sarnases stsenaariumis peame hoolitsema:

• kelle jaoks see on tootmises;
• koodi haru master veaga, millelt arendajad saavad alustada uut tööd.

Tagasi keerata või parandada järgmisel versioonil?

"Tagasi keeramine" (rolling back) on eelnevalt õigeks deemontitud versiooni tootmisse töötlemine ja vigadega commitite tühistamine (revert). "Parandamine järgmisel versioonil" (fixing forward) tähendab paranduse lisamist master ja uue versiooni võimalikult kiiret rakendamist. Kuna API-d ja andmebaasi skeemid muutuvad koodi juurutamisega tootmiskeskkonnas, on pideva tarnimise ja hea kattega testide olemasolu tõttu tagasitõmbamine tavaliselt palju keerulisem ja riskantsem kui parandamine järgmises versioonis.

Kuna tagasitõmbamine ei kanna meie puhul mingit riskitsooni, läheme seda teed, kuna see võimaldab meil

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

️ Ülesanne

1. Lülituge harule master kohapeal.
2. Uuendage kohalikku hoidlat kaug-repositooriumist.
3. Tühistage PR-i sulandumiskommit. Steps review ühes master.
4. Avaldage muudatused kaug-repositooriumisse.

See on repositooriumi ajalugu tühistatud sulandumiskommiga.

Meeskonnad

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

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

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

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

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

️ Enesekontroll

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

Parandage CI sammude nimekiri ja tagastage see masterisse.

Me oleme täielikult tühistanud sulandumiskommi harust feature. Hea uudis on see, et nüüd meil pole enam viga master. Halb uudis on aga see, et ka meie väärtuslik CI sammude nimekiri kadus. Seega, ideaalis, peame me paranduse rakendama kommitesse feature ja need tagasi tooma. master koos parandamisega.

Me saame läheneda ülesandele erinevalt:

• kummata (revert) kommit, mis tühistab ühendamise feature koos master;
• kanda commite endisest feature.

Erinevad arendajatiimid kasutavad antud juhul erinevaid lähenemisi, meie aga kanname kasulikud commit'id eraldi haru ja loome selle uue haru jaoks eraldi pull request'i.

️ Ülesanne

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

2. Kandke kõik commid endisest harust feature uude haru. Lahendage ühinemiskonfliktid, mis tekkisid üleviimisel.

   

3. Lisage regressioonitest ci.test.js:

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

4. Käivitage testid kohapeal, et veenduda, et need ei lõpe edukalt.
5. Kustutage tekst " with a sneaky bug" ci.md.
6. Lisage indeksi muudatused testides ja muudatused tegevuste nimekirjas ja kommitage need.
7. Avaldage haru kaugkaustas.

Te peaksite tulemuseks saama midagi sarnast

Meeskonnad

# Создайте ветку под названием 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 nagu "base branch".
Palun oodake, kuni testid lõpevad. Saate testide staatust näha PR arutelu alumises osas.

Veenduge, et olete määranud master oma kloonis hoiust nagu "base branch", ma ei reageeri muudatusettepanekutele kursuse materjalidega koos hoius.

Kinnitage pull request "Fixing the feature"

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

️ Ülesanne

1. Kliki "Merge pull request".
2. Kliki "Confirm merge".
3. Klõpsake "Delete branch", kuna see pole enam vajalik.

See, mis teil hetkel peab olema.

Palju õnne!

Olete läbinud kõik toimingud, mida inimesed tavaliselt teevad pideva integreerimise protsessis.

Kui märkate kursuse käigus mingeid probleeme või teate, kuidas seda parandada, looge issue kursuse materjalide repos.Sellel kursusel on samuti interaktiivne versioon , mis kasutab GitHub Learning Labi platvormina.

Allikas: habr.com