Kas olete õppinud Giti käske, kuid soovite ette kujutada, kuidas pidev integreerimine (CI) tegelikkuses töötab? Või äkki soovid optimeerida oma igapäevaseid tegevusi? See kursus annab teile praktilisi oskusi pidevaks integreerimiseks GitHubi hoidla abil. See kursus ei ole mõeldud viisardina, mida saate lihtsalt klõpsata, vaid vastupidi, teete samu toiminguid, mida inimesed tegelikult tööl teevad, samal viisil, nagu nad seda teevad. Selgitan teooriat, kui te läbite sellega seotud samme.

Mida me siis teeme?

Edenedes koostame järk-järgult tüüpiliste CI etappide loendi, mis on suurepärane viis selle loendi meeldejätmiseks. Teisisõnu loome loendi toimingutest, mida arendajad teevad pideva integreerimise ja pideva integreerimise ajal. Kasutame ka lihtsat testide komplekti, et tuua oma CI-protsess tegelikule lähemale.

See GIF näitab skemaatiliselt teie hoidlas olevaid sisseviimisi, kui kursuse jooksul liigute. Nagu näete, pole siin midagi keerulist ja ainult kõige vajalikum.

Läbite järgmised standardsed CI stsenaariumid.

• Töötage funktsiooniga;
• Automatiseeritud testide rakendamine kvaliteedi tagamiseks;
• Prioriteetse ülesande elluviimine;
• Konfliktide lahendamine filiaalide ühendamisel (ühendamise konflikt);
• Tootmiskeskkonnas ilmneb viga.

Mida sa õpid?

Saate vastata järgmistele küsimustele:

• Mis on pidev integratsioon (CI)?
• Mis tüüpi automatiseeritud teste CI-s kasutatakse ja millistele toimingutele need käivitatakse?
• Mis on tõmbamistaotlused ja millal neid vaja on?
• Mis on testipõhine arendus (TDD) ja kuidas see on seotud CI-ga?
• Kas ma peaksin muudatused liitma või uuesti määrama?
• Kas tühistada või järgmises versioonis parandada?

Alguses tõlkisin igal pool selliseid asju nagu “tõmba taotlusi”, kuid selle tulemusena otsustasin mõnes kohas ingliskeelseid fraase tagastada, et tekstis hullumeelsust vähendada. Ma kasutan mõnikord "programmeerija surzhik" nagu imelist tegusõna "pühendada", kui inimesed seda tegelikult tööl kasutavad.

Mis on pidev integratsioon?

Pidev integreerimine, ehk CI, on tehniline praktika, mille puhul iga meeskonnaliige integreerib oma koodi ühisesse hoidlasse vähemalt kord päevas ja sellest tulenev kood peab olema vähemalt vigadeta üles ehitatud.

Selle termini osas on lahkarvamusi

Vaidluspunkt on integreerimise sagedus. Mõned väidavad, et koodi ühendamisest ainult üks kord päevas ei piisa pidevaks integreerimiseks. Näide on toodud meeskonnast, kus kõik võtavad hommikul värske koodi ja integreerivad selle korra õhtul. Kuigi see on mõistlik vastuväide, arvatakse üldiselt, et kord päevas määratlus on mõistlikult praktiline, konkreetne ja sobib erineva suurusega meeskondadele.

Teine vastuväide on see, et C++ pole enam ainus arenduses kasutatav keel ja lihtsalt veavaba kokkupaneku nõudmine valideerimise viisina on nõrk. Mõni testide komplekt (nt kohapeal teostatud ühikutestid) peab samuti edukalt lõpule jõudma. Hetkel liigub kogukond selle poole, et see nõue oleks ja edaspidi saavad "ehitamine + ühiktestid" ilmselt tavapäraseks tavaks, kui see veel pole.

Pidev integreerimine erineb pidev tarnimine (Continuous Delivery, CD), kuna see ei nõua väljalaskekandidaati pärast iga integreerimistsüklit.

Loetelu sammudest, mida kogu kursuse jooksul kasutame

1. Tõmmake sisse uusim kood. Looge filiaal master. Hakka tööle.
2. Looge oma uues harus kohustusi. Ehitage ja testige kohapeal. Üle andma? Minge järgmise sammu juurde. Ebaõnnestumine? Parandage vead või testid ja proovige uuesti.
3. Lükake oma kaughoidlasse või kaugemasse haru.
4. Looge tõmbetaotlus. Arutage muudatusi, lisage arutelu jätkudes rohkem kohustusi. Pange testid funktsiooniharule edasi.
5. Ühenda/taasbaasi rakendab ülemseadmelt. Pange testid liitmise tulemust edasi andma.
6. Juurutage funktsiooniharust tootmisse.
7. Kui tootmises on kõik mõnda aega hästi, ühendage muudatused masteriks.

️ Ettevalmistus

Veenduge, et teil oleks õige tarkvara

Selle kursuse läbimiseks vajate Node.js и Anna klient.

Võite kasutada mis tahes Giti klienti, kuid annan ainult käsurea käsud.

Veenduge, et teil oleks installitud Giti klient, mis toetab käsurida

Kui teil pole veel käsurida toetavat Giti klienti, leiate installijuhised siin.

Valmistage hoidla ette

Peate looma isikliku koopia (kahvel) mallihoidla kursuse koodiga GitHubis. Lepime kokku, et nimetame seda isiklikuks koopiaks kursuste hoidla.

Kas tehtud? Kui te pole vaikesätteid muutnud, kutsutakse tõenäoliselt teie kursuse hoidlat continuous-integration-team-scenarios-students, asub see teie GitHubi kontol ja URL näeb välja selline

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

Ma lihtsalt helistan sellele aadressile <URL репозитория>.

Nurksulgud nagu <тут> tähendab, et peate asendama sellise avaldise sobiva väärtusega.

Veendu, et GitHubi toimingud selle kursuse hoidla jaoks kaasatud. Kui need pole lubatud, lubage need, klõpsates lehe keskel suurt nuppu, mille juurde pääsete, klõpsates GitHubi liideses valikul Toimingud.

Kui GitHubi toimingud pole lubatud, ei saa te kursust minu juhiseid järgides läbida.

Siin koostatava loendi hetkeseisu nägemiseks saate alati kasutada GitHubi võimalust Markdowni renderdamiseks

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

Vastuste kohta

Kuigi parim viis selle kursuse läbimiseks on seda ise teha, võib teil tekkida raskusi.

Kui tunnete, et te ei saa aru, mida teha, ega saa jätkata, võite teemat uurida solution, mis asub teie stardihoidlas.
Palun ärge ühendage solution в master kursuse ajal. Saate kasutada seda haru, et välja mõelda, mida teha, või võrrelda oma koodi autori koodiga, kasutades kõiki Giti pakutavaid võimalusi. Kui olete täiesti kadunud, saate oma haru täielikult välja vahetada master oksal solution ja seejärel lähtestage oma töökataloog vajalikule kursuse etapile.

Kasutage seda ainult siis, kui seda tõesti vajate

Kinnitage oma kood

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

Need käsud

• ümber nimetada master в master-backup;
• ümber nimetada solution в master;
• kassasse uude esindusse master ja kirjutage ümber töökataloogi sisu;
• Looge "ülemast" (mis varem oli "lahendus") "lahendus" haru juhuks, kui vajate tulevikus "lahenduse" haru.

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

Pärast neid samme saate kasutada git log master et välja selgitada, millist kohustust vajate.
Saate oma töökataloogi sellele kohustusele lähtestada järgmiselt:

git reset --hard <the SHA you need>

Kui olete tulemusega rahul, peate mingil hetkel avaldama hoidla versiooni kaughoidlas. Ärge unustage seda tehes selgelt määratleda kaugharu.

git push --force origin master

Pange tähele, et kasutame git push --force. On ebatõenäoline, et soovite seda väga sageli teha, kuid meil on siin väga konkreetne stsenaarium ühe hoidla kasutajaga, kes lisaks mõistab, mida ta teeb.

Tööle asumine

Alustame oma CI etappide loendi koostamist. Tavaliselt alustate seda sammu koodi uusima versiooni kontrollimisega kaughoidlast, kuid meil pole veel kohalikku hoidlat, seega kloonime selle hoopis kaughoidlast.

️ Ülesanne: värskendage kohalikku hoidlat, looge sellest haru master, hakka tööle

1. Kloonige kursuse hoidla asukohast <URL репозитория>.
2. Jookse npm install kursuste hoidla kataloogis; Vajame seda Jesti installimiseks, mida kasutame testide käitamiseks.
3. Looge haru ja andke sellele nimi feature. Lülitu sellele lõimele.

4. Lisage testikood ci.test.js kommentaaride vahel, mis paluvad mul seda teha.

   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. Lisage faili esimese 4 sammuga tekst 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.  

   Käsud

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

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

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

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

Looge kohustused uues harus, ehitage ja testige kohapeal

Seadistame testid käivitamiseks enne sidumist ja seejärel kinnitame koodi.

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

• Kohalikult:
  • Pidevalt või vastusena asjakohastele koodimuudatustele;
  • salvestamisel (tõlgitud või JIT-i koostatud keelte jaoks);
  • Montaaži ajal (kui kompileerimine on vajalik);
  • Pühendumisel;
  • Jagatud hoidlas avaldamisel.

• Järelserveris või ehituskeskkonnas:
  • Kui kood avaldatakse isiklikus filiaalis/hoidlas.
  • Selle lõime koodi testitakse.
  • Ühinemise võimalikku tulemust testitakse (tavaliselt koos master).
  • Pideva integreerimisetapi / pideva tarnetoruna

Tavaliselt, mida kiiremini testkomplekt töötab, seda sagedamini saate seda endale lubada. Tüüpiline lavajaotus võib välja näha selline.

• Kiired seadmetestid – ehitamise ajal, CI torujuhtmes
• Aeglased ühikutestid, kiired komponendi- ja integratsioonitestid – kinnitamisel, CI konveieril
• Aeglased komponentide ja integratsiooni testid – CI-konveier
• Turvatestid, koormustestid ja muud aeganõudvad või kallid testid – CI/CD konveierites, kuid ainult teatud režiimides/etappides/konveierites, näiteks väljalaskekandidaadi ettevalmistamisel või käsitsi käivitamisel.

️ Ülesanne

Soovitan testid esmalt käsitsi käivitada, kasutades käsku npm test. Pärast seda lisame git-konksu, et käivitada commit-testid. Siin on üks konks: Giti konkse ei peeta hoidla osaks ja seetõttu ei saa neid koos ülejäänud õppematerjalidega GitHubist kloonida. Konksu paigaldamiseks peate jooksma install_hook.sh või kopeerige fail repo/hooks/pre-commit kohalikku kataloogi .git/hooks/.
Sidumisel näete, et testid käivitatakse ja kontrollitakse, kas loendis on teatud märksõnu.

1. Käivitage testid käsitsi, käivitades käsu npm test oma kursuse hoidla kaustas. Kontrollige, kas testid on lõpule viidud.
2. Seadke kinnipanemise konks (pre-commit hook) joostes install_hook.sh.
3. Kinnitage muudatused oma kohalikku hoidlasse.
4. Veenduge, et testid oleksid enne kohustuse võtmist läbi viidud.

Teie hoidla peaks pärast nende sammude järgimist välja nägema selline.

Käsud

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

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

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

Avalda kood kaughoidlasse või kaugharusse

Kui nad on kohaliku töö lõpetanud, teevad arendajad tavaliselt oma koodi avalikult kättesaadavaks, et seda lõpuks avalikkusega integreerida. GitHubi puhul saavutatakse see tavaliselt teose avaldamisega kas hoidla isiklikus koopias (isiklikus kahvlis) või isiklikus harus.

• Kahvlite abil kloonib arendaja jagatud kaughoidla, luues sellest isikliku kaugkoopia, mida tuntakse ka kahvli nime all. Seejärel kloonib see selle isikliku hoidla kohalikuks töötamiseks. Kui töö on tehtud ja kohustused tehtud, lükkab ta need oma hargisse, kus need on teistele kättesaadavad ja integreeritavad ühisesse hoidlasse. Seda lähenemisviisi kasutatakse tavaliselt GitHubi avatud lähtekoodiga projektides. Seda kasutatakse ka minu edasijõudnute kursusel [Meeskonnatöö ja CI koos Gitiga] (http://devops.redpill.solutions/).
• Teine võimalus on kasutada ainult ühte kaughoidlat ja loendada ainult haru master jagatud hoidla "kaitstud". Selle stsenaariumi korral avaldavad üksikud arendajad oma koodi kaughoidla harudesse, et teised saaksid seda koodi vaadata, kui kõik on korras, ühendage see master jagatud hoidla.

Sellel konkreetsel kursusel kasutame töövoogu, mis kasutab harusid.

Avaldame oma koodi.

️ Ülesanne

• Avaldage muudatused teie töötava haruga sama nimega kaugharus

Käsud

git push --set-upstream origin feature

Looge tõmbetaotlus

Looge pealkirjaga tõmbamistaotlus Sammude ülevaade... Installige feature nagu "peaharu" ja master nagu "alusharu".

Veenduge, et olete installinud master tema harutage hoidla "Baasharuna" ma kursusematerjalide hoidla muudatuste taotlustele ei vasta.

GitHubi keelepruugis on "baasharu" haru, millel teie töö põhineb, ja "peaharu" on haru, mis sisaldab kavandatud muudatusi.

Arutage muudatusi, lisage arutelu jätkudes uusi kohustusi

Tõmbetaotlus (PR)

Tõmbetaotlus (PR) on viis koodi arutamiseks ja dokumenteerimiseks, samuti koodi ülevaatamiseks. Tõmbepäringud on oma nime saanud üksikute muudatuste üldisesse koodi integreerimise üldise viisi järgi. Tavaliselt kloonib inimene projekti ametliku kaughoidla ja töötab koodiga kohapeal. Pärast seda asetab ta koodi oma isiklikku kaughoidlasse ja palub ametliku hoidla eest vastutavatel isikutel üles võtta (vedama) selle koodi oma kohalikesse hoidlatesse, kus nad üle vaatavad ja võimalusel integreerivad (ühendada) tema. Seda mõistet tuntakse ka teiste nimede all, näiteks liitmistaotlus.

Te ei pea tegelikult kasutama GitHubi või sarnaste platvormide tõmbamistaotluse funktsiooni. Arendusmeeskonnad võivad kasutada muid suhtlusviise, sealhulgas näost näkku suhtlemist, häälkõnesid või e-kirju, kuid foorumi stiilis tõmbetaotluste kasutamiseks on siiski mitmeid põhjuseid. Siin on mõned neist:

• organiseeritud konkreetsete koodimuudatustega seotud arutelud;
• kui koht, kus vaadata tagasisidet pooleliolevate tööde kohta nii autotestijate kui ka kaaslaste poolt;
• koodiülevaatuste vormistamine;
• et hiljem saaksite teada selle või teise koodijupi taga olevad põhjused ja kaalutlused.

Tavaliselt loote tõmbetaotluse, kui teil on vaja midagi arutada või tagasisidet saada. Näiteks kui töötate funktsiooni kallal, mida saab rakendada mitmel viisil, saate enne esimese koodirea kirjutamist luua tõmbamistaotluse, et jagada oma ideid ja arutada oma plaane oma koostööpartneritega. Kui töö on lihtsam, avatakse tõmbetaotlus siis, kui midagi on juba tehtud, pühendunud ja seda saab arutada. Mõne stsenaariumi korral võite avada suhtekorralduse ainult kvaliteedikontrolli põhjustel: automatiseeritud testide käitamiseks või koodiülevaatuste algatamiseks. Ükskõik, mille otsustate, ärge unustage @mainima inimesi, kelle heakskiitu soovite oma tõmbamistaotluses.

Tavaliselt teete PR-i loomisel järgmist.

• Märkige, mida ja kus soovite muuta.
• Kirjutage kirjeldus, mis selgitab muudatuste eesmärki. Võite soovida:
  • lisage midagi olulist, mis pole koodist ilmne, või midagi kasulikku konteksti mõistmiseks, näiteks asjakohased #bugs ja commit numbrid;
  • @mainige kõiki, kellega soovite koostööd alustada, või saate neid hiljem kommentaarides @mainida;
  • paluge kolleegidel milleski aidata või kontrollige midagi konkreetset.

Kui avate PR-i, käivitatakse sellistel juhtudel käitamiseks konfigureeritud testid. Meie puhul on see sama testide komplekt, mida me kohapeal korraldasime, kuid reaalses projektis võib olla täiendavaid teste ja kontrolle.

Palun oodake, kuni testid on lõppenud. Testide olekut näete GitHubi liidese PR-arutelu allosas. Jätkake, kui testid on lõpetatud.

️ Lisage märge CI etappide loendi juhuslikkuse kohta

Sellel kursusel kasutatav loetelu on meelevaldne ja subjektiivne, peaksime selle kohta märkuse lisama.

️ Ülesanne: looge selle kommentaari jaoks tõmbetaotlus

1. Lülitu harule master.
2. Looge haru nimega bugfix.
3. Lisage faili lõppu märkuse tekst 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. Tehke muudatused.
5. Avalda lõim bugfix kaughoidlasse.
6. Looge tõmbetaotlus nimega Märkuse lisamine peaoksaga bugfix ja alusharumaster.

Veenduge, et olete installinud master tema harutage hoidla "Baasharuna" ma kursusematerjalide hoidla muudatuste taotlustele ei vasta.

Selline peaks teie hoidla välja nägema.

Käsud

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

Tõmbetaotluse "Märkuse lisamine" kinnitamine

️ Ülesanne

1. Looge tõmbetaotlus.
2. Klõpsake "Ühenda tõmbamistaotlus".
3. Klõpsake "Kinnita ühendamine".
4. Klõpsake "Kustuta haru", me ei vaja seda enam.

See on ühendamise järgsete kohustuste diagramm.

️ Jätkake tööd ja lisage teste

Tõmbetaotluse kallal koostöö tegemine toob sageli kaasa lisatööd. Tavaliselt on see koodi läbivaatamise või arutelu tulemus, kuid meie kursusel kavatseme seda modelleerida, lisades oma CI etappide loendisse uusi üksusi.

Pidev integreerimine hõlmab tavaliselt mõningast testi katvust. Testi katvuse nõuded on erinevad ja tavaliselt leiate need dokumendist, mida nimetatakse "panuse juhisteks". Hoiame selle lihtsana ja lisame kontrollnimekirja iga rea ​​jaoks testi.

Ülesannete täitmisel proovige esmalt testid sooritada. Kui installisite õigesti pre-commit konks varem, käivitatakse äsja lisatud test, see ebaõnnestub ja midagi ei tehta. Pange tähele, et nii teame, et meie testid testivad midagi. Huvitav on see, et kui alustasime koodiga enne teste, võib testide läbimine tähendada, et kood töötas ootuspäraselt või et testid ei testinud tegelikult midagi. Lisaks, kui me poleks teste alguses kirjutanud, oleksime need võib-olla üldse unustanud, sest miski poleks seda meile meelde tuletanud.

Testipõhine arendus (TDD)

TDD soovitab kirjutada testid enne koodi. Tüüpiline TDD-d kasutav töövoog näeb välja selline.

1. Lisa test.
2. Käivitage kõik testid ja veenduge, et uus test ebaõnnestub.
3. Kirjutage kood.
4. Käivitage testid ja veenduge, et kõik testid läbivad.
5. Refaktoreerige oma kood.
6. Korda.

Kuna ebaõnnestunud testide tulemusi näidatakse tavaliselt punasega ja edukalt läbinud testide tulemusi roheliselt, on tsükkel tuntud ka kui punane-roheline-refaktor.

️ Ülesanne

Esmalt proovige testid läbi viia ja lasta neil ebaõnnestuda, seejärel lisage ja kinnitage CI sammude loendi tekst ise. Näete, et testid läbivad ("roheline").
Seejärel avaldage uus kood kaughoidlas ja vaadake, kuidas testid käitatakse GitHubi liideses tõmbetaotluste arutelu ja PR-oleku värskenduse allosas.

1. Lülitu harule feature.

2. Lisage need testid ci.test.js pärast viimast kõnet 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. Proovige testid sooritada. Kui pre-commit konks on paigaldatud, siis sissekandmiskatse nurjub.
4. Seejärel lisage see tekst 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. Tehke ja tehke muudatusi kohapeal.
6. Postitage muudatused harusse feature.

Nüüd peaks teil olema midagi sellist

Käsud

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

Ühendage konflikt

Minge jaotisse Muudatustaotlus Sammude ülevaade.

Kuigi me ei teinud midagi valesti ja meie koodi testid läbisid, ei saa me ikkagi haru ühendada feature и master. Põhjus on selles, et teine ​​niit bugfix liideti master kui me selle PR kallal töötasime.
See loob olukorra, kus kaugharu master sellel on uuem versioon kui sellel, millel haru põhinesime feature. Seetõttu ei saa me lihtsalt HEAD-i tagasi kerida master niidi lõpuni feature. Sellises olukorras peame kas liitma või rakendama kohustusi feature rebase master. Kui konflikte pole, saab GitHub tegelikult automaatseid liitmisi teha. Kahjuks on meie olukorras mõlema filiaali failis konkureerivad muudatused ci.md. Seda olukorda nimetatakse liitmiskonfliktiks ja me peame selle käsitsi lahendama.

Ühendage või taasalustage

Merge

• Loob täiendava liitmiskohustuse ja salvestab tööajaloo.
  • Säilitab filiaalide algsed kinnitused koos nende algsete ajatemplite ja autoritega.
  • Salvestab kohustuste SHA ja lingid neile muudatustaotluste aruteludes.
• Nõuab ühekordset konflikti lahendamist.
• Muudab loo mittelineaarseks.
  • Lugu võib olla raskesti loetav suure harude arvu tõttu (meenutab IDE-kaablit).
  • Teeb automaatse silumise keerulisemaks, nt. git bisect vähem kasulik – see leiab ainult ühendamise kohustuse.

Alusta uuesti

• Kordab üksteise järel kehtiva haru kohustusi põhiharu peale.
  • Uute SHA-dega luuakse uued kohustused, mille tõttu GitHubi sissekanded vastavad algsetele tõmbamistaotlustele, kuid mitte vastavatele kommentaaridele.
  • Komitee saab protsessi käigus uuesti kombineerida ja muuta või isegi üheks liita.
• Võimalik, et tuleb lahendada mitu konflikti.
• Võimaldab säilitada lineaarset lugu.
  • Lugu võib olla lihtsam lugeda, kui see pole mõistliku põhjuseta liiga pikk.
  • Automaatne silumine ja tõrkeotsing on veidi lihtsam: teeb selle võimalikuks git bisect, võib muuta automaatsed tagasipööramised selgemaks ja prognoositavamaks.
• Nõuab migreeritud kohustustega haru avaldamist lipuga --force kui seda kasutatakse koos tõmbamistaotlustega.

Tavaliselt nõustuvad meeskonnad kasutama alati sama strateegiat, kui neil on vaja muudatusi liita. See võib olla "puhas" liitmine või "puhas" ülaosas või midagi vahepealset, näiteks interaktiivselt pealmise sissekande tegemine (git rebase -i) kohalikult filiaalide puhul, mida ei avaldata avalikku hoidlasse, kuid ühineda "avalike" filiaalide jaoks.

Siin kasutame ühendamist.

️ Ülesanne

1. Veenduge, et kood oleks kohalikus filiaalis master värskendatud kaughoidlast.
2. Lülitu harule feature.
3. Algatage liitmine haruga master. Ühendamiskonflikt konkureerivate muudatuste tõttu ci.md.
4. Lahendage konflikt nii, et teksti jääksid nii meie CI sammude loend kui ka märkus selle kohta.
5. Avaldage kaugharus liitmiskohustus feature.
6. Kontrollige tõmbamistaotluse olekut GitHubi kasutajaliideses ja oodake, kuni ühendamine on lahendatud.

Käsud

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

️ Ülesanne: kinnitage tõmbamistaotlus "Sammude ülevaatus"

1. Avage tõmbetaotlus.
2. Klõpsake "Ühenda tõmbamistaotlus".
3. Klõpsake "Kinnita ühendamine".
4. Klõpsake "Kustuta haru", kuna me ei vaja seda enam.

See on praegu teie hoidla

Toote viga

Öeldakse, et "testimist saab kasutada vigade olemasolu näitamiseks, kuid mitte kunagi nende puudumise näitamiseks." Kuigi meil olid testid ja need ei näidanud meile vigu, hiilis tootmisse salakaval viga.

Sellise stsenaariumi korral peame hoolitsema järgmise eest:

• mida tootmises kasutatakse;
• kood lõimes master veaga, millest arendajad saavad uut tööd alustada.

Kas ma peaksin selle järgmises versioonis tagasi võtma või parandama?

Tagasipööramine on protsess, mille käigus juurutatakse teadaolevalt hea varasem versioon tootmisse ja ennistatakse viga sisaldav toime. "Fixing forward" on paranduse lisamine master ja juurutada uus versioon niipea kui võimalik. Kuna API-d ja andmebaasiskeemid muutuvad, kui koodi juurutatakse tootmisse, pideva tarnimise ja hea testi katvuse korral on tagasipööramine tavaliselt palju keerulisem ja riskantsem kui selle parandamine järgmises versioonis.

Kuna tagasirullimine meie puhul riski ei too, siis läheme seda teed, sest see võimaldab

• paranda toote viga esimesel võimalusel;
• tee kood sisse master sobib koheselt uuele tööle asumiseks.

️ Ülesanne

1. Lülitu harule master lokaalselt.
2. Värskendage kohalikku hoidlat kaughoidlast.
3. Taasta PR-ühendamise kohustus Sammude ülevaade в master.
4. Avalda muudatused kaughoidlas.

See on hoidla ajalugu, mille ühendamise kohustus on tühistatud

Käsud

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

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

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

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

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

️ Enesetest

Veendu, et ci.md ei sisalda pärast ühendamiskohustuse tagasivõtmist enam teksti "sneaky bug".

Parandage CI-sammude loend ja tagastage see juhtseadmele

Oleme filiaali ühendamise kohustuse täielikult tühistanud. feature. Hea uudis on see, et meil pole nüüd viga master. Halb uudis on see, et ka meie väärtuslik pidevate integratsioonietappide loend on kadunud. Nii et ideaaljuhul peame rakendama paranduse kohustustele alates feature ja need tagasi master koos parandusega.

Saame probleemile läheneda erineval viisil:

• ühendamise tühistava kohustuse tagasivõtmine feature с master;
• liikuda kohustab endisest feature.

Erinevad arendusmeeskonnad kasutavad sel juhul erinevaid lähenemisviise, kuid me viime kasulikud kohustused eraldi harusse ja loome selle uue haru jaoks eraldi tõmbetaotluse.

️ Ülesanne

1. Loo lõim nimega feature-fix ja lülituda sellele.

2. Viige kõik endise haru kohustused üle feature uuele lõimele. Lahendage migratsiooni ajal tekkinud liitmiskonfliktid.

   

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 ebaõnnestuks.
5. Eemaldage tekst "algatava veaga". ci.md.
6. Lisage indeksisse testmuudatused ja sammuloendi muudatused ning kinnitage need.
7. Avaldage haru kaughoidlas.

Peaksite lõppema millegi sarnasega:

Käsud

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

Looge pealkirjaga tõmbamistaotlus Funktsiooni parandamine... Installige feature-fix nagu "peaharu" ja master nagu "alusharu".
Palun oodake, kuni testid on lõppenud. Testide seisu näete PR-diskussiooni allosas.

Veenduge, et olete installinud master tema harutage hoidla "Baasharuna" ma kursusematerjalide hoidla muudatuste taotlustele ei vasta.

Tõmbetaotluse „Funktsiooni parandamine” kinnitamine

Aitäh paranduse eest! Kinnitage muudatused master tõmbamistaotlusest.

️ Ülesanne

1. Klõpsake "Ühenda tõmbamistaotlus".
2. Klõpsake "Kinnita ühendamine".
3. Klõpsake "Kustuta haru", kuna me ei vaja seda enam.

See on see, mis teil praegu peaks olema.

Õnnitleme!

Olete lõpetanud kõik toimingud, mida inimesed pideva integreerimise ajal tavaliselt teevad.

Kui märkate kursusel probleeme või teate, kuidas seda parandada, looge probleem hoidlad koos kursuse materjalidega. Sellel kursusel on ka interaktiivne versioon kasutades platvormina GitHub Learning Labi.

Allikas: www.habr.com