Tanulmányoztad a Git parancsokat, de szeretnéd látni, hogyan történik a folyamatos integráció (Continuous Integration, CI) valójában? Vagy lehet, hogy az napi tevékenységeid optimalizálására törekszel? Ez a kurzus gyakorlati készségeket nyújt a folyamatos integrációról a GitHub-on található tároló használatával. Ez a kurzus nem csupán egy varázsló, amelyet egyszerűen végig lehet kattintani, hanem valóban ugyanolyan lépéseket fogsz megtenni, mint amit az emberek a munkahelyükön tesznek, éppen úgy, ahogyan azt ők is csinálják. A gyakorlatok során elmagyarázom a szükséges elméletet.

Mit fogunk csinálni?

Ahogy előre haladunk, fokozatosan létrehozzuk a CI-tipikus lépések listáját, ami nagyszerű módja annak, hogy megjegyezzük ezt a listát. Más szavakkal, a folyamatos integráció során a fejlesztők által végzett lépéseket fogjuk dokumentálni, és egyszerű tesztek segítségével a CI folyamatunkat a valósághoz közelítjük.

Ez a GIF vázlatosan mutatja be a webhelyed tárolójában lévő elköteleződéseket, ahogy haladsz a kurzus során. Ahogy látod, ez nem bonyolult, csak a legszükségesebb dolgokat tartalmazza.

Ilyen standard CI forgatókönyveken fogsz áthaladni:

• Funkció fejlesztése;
• Automatikus tesztek alkalmazása a minőség biztosítására;
• Fontos feladat végrehajtása;
• Merge konfliktus megoldása;
• Hiba előfordulása a termelési környezetben.

Mit fogsz megtanulni?

Képes leszel válaszolni a következő kérdésekre:

• Mi az a folyamatos integráció (CI)?
• Milyen típusú automatikus teszteket használnak a CI során, és milyen eseményekre aktiválódnak?
• Mi az a pull request és mikor van szükség rájuk?
• Mi az a tesztvezérelt fejlesztés (Test Driven Development, TDD) és hogyan kapcsolódik a CI-hez?
• Elvégezzem a merge-t vagy a változásokat rakjam rá (rebase)?
• Visszavonjam vagy javítsam a következő verzióban?

Kezdetben mindenhol fordítottam az olyan kifejezéseket, mint a "pull request", de végül úgy döntöttem, hogy visszahozom az angol kifejezéseket néhány helyen, hogy csökkentsem a szöveg zűrzavarát. Néha meg fogom használni a "programozói zsargont", mint a "commit" igét ott, ahol az emberek valójában ezt használják a munkahelyükön.

Mi az a folyamatos integráció?

Folyamatos integráció, vagy CI, egy technikai gyakorlat, amely azt jelenti, hogy a csapat minden tagja a nap folyamán legalább egyszer integrálja a kódját a közös tárolóba, ráadásul az eredményül kapott kódnak legalább hibamentesen kell összeállnia.

Vannak eltérések a kifejezést illetően.

A vita tárgya az integráció gyakorisága. Néhányan azt állítják, hogy a kód napi egy alkalommal történő egyesítése nem elegendő, valóban folyamatosan kell integrálódni. Példaként említenek egy csapatot, ahol mindenki reggel friss kódot vesz, és este integrálódik egyszer. Bár ez ésszerű ellenérv, mégis általánosan elmondható, hogy a napi egy alkalom definíciója elegendően praktikus, konkrét, és megfelel különböző méretű csapatok számára.

Egy másik ellenérv az, hogy a C++ régóta nem az egyetlen nyelv, amelyet a fejlesztés során használnak, és a hibamentes fordítás egyszerű követelménye, mint validálási módszer, gyenge. Egy bizonyos tesztkészlet (például moduláris, helyben futtatható) is sikeresen kell, hogy véget érjen. Jelenleg a közösség hajlik arra, hogy ez a követelmény kötelező legyen, és a jövőben 'fordítás + moduláris tesztek' egyértelműen általánosan elfogadottá válhat, ha ez már meg nem történt.

Folyamatos integráció különbözik a folytonos szállítástól (Continuous Delivery, CD) abban, hogy nem követeli meg a kiadási jelölt létrehozását minden egyes integrációs ciklus után.

A lépések listája, amelyet a tanfolyam során használni fogunk.

1. Húzd be a legfrissebb kódot. Hozz létre egy ágat a master. Kezdj el dolgozni.
2. Hozz létre elkötelezéseket az új ágon. Építsd és teszteld helyben. Megfelel? Folytasd a következő lépéssel. Nem teljesít? Javítsd ki a hibákat vagy teszteket, és próbáld újra.
3. Push a távoli tárolódba vagy távoli ágadba.
4. Hozz létre egy pull kérést. Beszélgess a változtatásokról, adj hozzá további elkötelezéseket, amíg a diskurzus folyik. Biztosítsd, hogy a tesztek megfeleljenek a funkció ágban.
5. Egyesítsd/rebase-t az elkötelezéseket a masterből. Biztosítsd, hogy a tesztek megfeleljenek az egyesített eredményen.
6. Telepítsd a funkció ágból a termelésbe.
7. Ha a termelésben minden rendben van némi időn keresztül, egyesítsd a változtatásokat a masterbe.

️ Előkészítés

Győződj meg arról, hogy a szükséges szoftver rendelkezésre áll.

Ehhez a tanfolyamhoz szükséged lesz Node.js és Git kliensre..

Használhatsz bármilyen Git klienst, de csak a parancssori parancsokat fogom bemutatni.

Győződj meg arról, hogy a parancssoros Git kliens telepítve van nálad.

Ha még nincs telepítve a parancssoros Git kliens, akkor találhatsz telepítési útmutatót. itt.

Készítsd elő a tárolót.

Szükséged lesz egy személyes másolat (fork) létrehozására a tanfolyamhoz szükséges sablon tárolóból a GitHub-on. Nevezzük el ezt a személyes másolatot a tanfolyam tárolójának..

Készen áll? Ha nem változtattad meg az alapértelmezett beállításokat, a kurzusod repozitóriuma valószínűleg a következőképpen hívják: continuous-integration-team-scenarios-students, az a GitHub fiókodban található, és a URL így néz ki:

https://github.com//

Ez a cím egyszerűen <URL репозитория>.

Az éles szögű zárójelek, mint <тут> azt jelentik, hogy ezt a kifejezést a megfelelő értékre kell cserélni.

Győződj meg róla, hogy GitHub actions engedélyezve van ehhez a kurzus repozitóriumhoz. Ha nincsenek engedélyezve, kérlek, engedélyezd őket a középső oldalon található nagy gomb megnyomásával, amely a GitHub felületén az Actions-re kattintva érhető el.

Nem tudod végigcsinálni a kurzust az utasításaim szerint, ha a GitHub Actions nincsenek engedélyezve.

Mindig használhatod a GitHub Markdown megjelenítési képességét, hogy megnézd az aktuális állapotát a listának, amit itt állítunk össze:

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

A válaszokról

Bár a legjobb módja a kurzus befejezésének, ha mindent saját magad csinálsz, lehetnek nehézségeid.

Ha úgy érzed, nem érted, mit kell tenned és nem tudsz tovább menni, megnézheted a solutionágat, amely a kezdő repozitóriumodban található.
Kérlek, ne végezz összevonásokat solution be. master a kurzus során. Felhasználhatod ezt az ágat, hogy megértsd, mit kell tenned, vagy hogy összehasonlítsd a kódodat a szerzőével, kihasználva a Git összes lehetőségét. Ha teljesen elvesztél, a saját ágad teljesen kicserélheted master az ágra solution és aztán visszaállíthatod a munkakönyvtáradat a kurzusnak azon lépésére, amire szükséged van.

Csak akkor használd ezt, ha tényleg szükséged van rá.

Készítsd el a commit-ot a kódodhoz:

git add .
git commit -m "A munkám mentése"

Ezek a parancsok

• átnevezik master be. master-backup;
• átnevezik solution be. master;
• átkapcsolják az új ágra master és felülírják a munkakönyvtár tartalmát;
• létrehozzák a "solution" ágat a "master"-ből (amely korábban "solution" volt), arra az esetre, ha szükséged lenne a "solution" ágra a jövőben.

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

Ezek után használhatod a git log master parancsot, hogy megtudd, melyik commit-ra van szükséged.
Visszaállíthatod a munkakönyvtáradat erre a commit-ra így:

git reset --hard 

Ha elégedett az eredménnyel, elérkezik az idő, amikor publikálnia kell a távoli tárolóba (remote) a verzióját. Ne felejtse el kifejezetten megadni a távoli ágat, amikor ezt teszi.

git push --force origin master

Kérjük, vegye figyelembe, hogy mi használjuk git push --force. Valószínűleg nem fog gyakran így járni, de itt egy nagyon specifikus forgatókönyv van egy felhasználóval a tárolóhoz, aki ráadásul tudja, mit csinál.

Kezdjük el a munkát

Kezdjük el összeállítani a CI lépések listáját. Általában ezt a lépést az utolsó kódverzió letöltésével kezdi a távoli tárolóból, de nekünk még nincs helyi tárolónk, ezért most inkább klónozzuk a távoli tárolóból.

️Feladat: Frissítse a helyi tárolót, hozzon létre ágat a master, kezdje el a munkát

1. Klónozza a kurzus tárolóit a <URL репозитория>.
2. Indítsa el npm install a kurzus tároló könyvtárába; szükségünk van rá a Jest telepítéséhez, amit a tesztek futtatására használunk.
3. Hozzon létre egy ágat, és nevezze el feature. Váltsa át ezt az ágat.

4. Adja hozzá a tesztkódot a ci.test.js kommentárok közé, amik kérik a megtételét.

   it('1. húzza le a legújabb kódot', () => {
     expect(/.*pull.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('2. adjon hozzá commitokat', () => {
     expect(/.*commit.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('3. nyomja meg a távoli ágra az ugyanazzal a névvel', () => {
     expect(/.*push.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('4. hozzon létre egy pull kérést, és folytassa a munkát', () => {
     expect(/.*pulls+request.*\/ig.test(fileContents)).toBe(true);
   });

5. Adjon hozzá szöveget az első 4 lépéshez a fájlban ci.md.

   1. Húzza be a legújabb kódot. Hozzon létre egy ágat a `master`-ből. Kezdje el a munkát.    
   2. Hozzon létre commitokat az új ágán. Építse és tesztelje helyben.  
   Átmegy? Menjen a következő lépésre. Nem sikerült? Javítsa ki a hibákat vagy teszteket, és próbálja újra.  
   3. Nyomja meg a tárolójába vagy távoli ágára.  
   4. Hozzon létre egy pull kérést. Beszéljen meg a változásokról, adjon hozzá még commitokat, ahogy a megbeszélés folytatódik. Tegye működőképessé a teszteket a funkció ágán.  

   Csapatok

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

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

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

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

Hozzon létre commitokat az új ágon, végezzen buildet és tesztelje helyben

Beállítjuk a teszteket, hogy a commit előtt fussanak, majd commitáljuk a kódot.

Tipikus forgatókönyvek, amikor a tesztek automatikusan futnak

• Helyben:
  • Folyamatosan vagy a kód releváns változásaira válaszként;
  • Mentéskor (értelmezett vagy JIT-compile nyelvek esetén);
  • Építéskor (amikor a fordítás szükséges);
  • Commitáláskor;
  • Publikáláskor a közös tárolóba.

• A build szerveren vagy a build környezetben:
  • Amikor a kód publikálva van egy személyes ágra / tárolóra.
  • A kód tesztelve van ezen az ágon.
  • A potenciális összevonási eredmény tesztelése (általában a master).
  • A folyamatos integráció/folyamatos szállítási csővezeték lépjeként

Általában minél gyorsabban fut egy tesztcsoport, annál gyakrabban engedhetjük meg magunknak a futtatását. A tipikus lépések eloszlása így nézhet ki.

• Gyors moduláris tesztek – build során, CI folyamatban
• Lassú moduláris tesztek, gyors komponens- és integrációs tesztek – commit során, CI folyamatban
• Lassú komponens- és integrációs tesztek – CI folyamatban
• Biztonsági tesztelés, terheléses és egyéb hosszú vagy költséges tesztek – CI/CD folyamatokban, de csak meghatározott módok/lépések/összeszerelési folyamatok során, például a kiadási jelölt előkészítésekor vagy manuális futtatáskor.

️ Feladat

Elsőként azt javaslom, hogy manuálisan futtassuk a teszteket a következő paranccsal npm test. Ezt követően adjunk hozzá git hook-ot a tesztjeink commit során történő futtatásához. Van egy kis bonyodalom: a Git hook-ok nem képezik a repository részét, ezért nem klónozhatók a GitHub-ból a kurzus többi anyagával együtt. A hook telepítéséhez futtassa a következőt: install_hook.sh vagy másolja a fájlt repo/hooks/pre-commit a helyi mappába .git/hooks/.
A commit során láthatja, hogy a tesztek futnak, és ellenőrzik, hogy bizonyos kulcsszavak szerepelnek-e a listában.

1. Futtassa a teszteket manuálisan a következő parancs kiadásával npm test a kurzus repository mappájában. Győződjön meg arról, hogy a tesztek végrehajtódtak.
2. Állítsa be a hook-ot a commit-ra (pre-commit hook) futtatva install_hook.sh.
3. Commit-olja a változtatásokat a helyi repository-ba.
4. Győződjön meg arról, hogy a tesztek futnak a commit előtt.

A repository-nak így kell kinéznie ezen lépések végrehajtása után.

Csapatok

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

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

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

Publikálja a kódot egy távoli repository-ba vagy távoli ágba

Miután befejezte a helyi munkát, a fejlesztők általában a kódjukat nyilvánossá teszik, hogy végül integrálni lehessen a közössel. A GitHub segítségével ez általában a munka személyes repository másolatba (personal fork) vagy személyes ágba történő publikálásával érhető el.

• A fork allows a developer to clone a remote public repository, creating their own remote copy known as a fork. After that, they clone this personal repository to work on it locally. Once the work is completed and commits are made, they push them to their fork, making them accessible to others and potentially integrating them into the main repository. This approach is commonly used in open-source projects on GitHub. It is also utilized in my advanced course [Team Work and CI with Git]http://devops.redpill.solutions/).
• Another approach is to use a single remote repository and consider only the branch master of the shared repository as "protected." In this scenario, individual developers publish their code to branches of the remote repository for others to review, and if everything is satisfactory, merge it with master the main repository.

In this specific course, we will use a workflow involving branches.

Let's publish our code.

️ Feladat

• Publish changes to a remote branch with the same name as your working branch

Csapatok

git push --set-upstream origin feature

Create a pull request

Create a pull request titled Steps review. Set feature as the "head branch" and master as the "base branch."

Make sure you set master in your fork of the repository as the "base branch," I will not respond to change requests in the repository with course materials.

In GitHub slang, the "base branch" is the branch you base your work on, while the "head branch" is the branch containing the proposed changes.

Discuss the changes, add new commits as the discussion continues

Pull request (PR)

Pull request (PR) is a way to discuss and document code, as well as conduct a code review. Pull requests are named after the common method of integrating individual changes into the main code. Typically, a person clones the remote official repository of the project and works on the code locally. After that, they place the code in their personal remote repository and request that the maintainers of the official repository pullpull) their code into their local repositories, where they review and possibly integratemerge) it. This concept is also known by other names, such as merge request.

Valójában nem kell használnod a pull request funkciót a GitHubon vagy hasonló platformokon. A fejlesztőcsapatok más kommunikációs módokat is használhatnak, beleértve a személyes beszélgetéseket, hanghívásokat vagy e-maileket, de mégis számos ok van arra, hogy a fórum stílusú pull requesteket használj. Íme néhány ezek közül:

• szervezett megbeszélések a kód specifikus módosításaival kapcsolatban;
• mint helye az előzetes munka véleményezésének, akár automatizált tesztektől, akár kollégáktól;
• a kódellenőrzések formalizálása;
• hogy később tisztázhassuk a kód egyes részei mögött álló okokat és megfontolásokat.

Általában pull requestet akkor készítesz, amikor valamit meg szeretnél vitatni vagy visszajelzést szeretnél kapni. Például, ha dolgozol egy funkción, amelyet többféleképpen meg lehet valósítani, létrehozhatsz egy módosítást kérő javaslatot még azelőtt, hogy megírtad volna az első kódsort, hogy megoszthasd az ötleteidet és megbeszélhesd a terveidet a társalkotókkal. Ha a munka egyszerűbb, a pull request akkor nyílik meg, amikor már valami készen van, rögzítve van és megvitatható. Egyes helyzetekben a PR-t csak minőségellenőrzés céljából nyithatod meg: automatizált tesztek futtatásához vagy kódellenőrzés kezdeményezéséhez. Akárhogy is döntesz, ne felejtsd el @megemlíteni azokat az embereket, akinek a jóváhagyása szükséges a pull requestedhez.

Általában, amikor PR-t készítesz, a következőket teszed.

• Megadod, hogy mit szeretnél módosítani és hol.
• Írsz egy leírást, amely magyarázza a változtatások célját. Lehet, hogy szeretnéd:
  • hozzáadni azokat a fontos információkat, amelyek nem nyilvánvalóak a kódból, vagy hasznosakat a kontextus megértéséhez, például a vonatkozó #bugokat és commit számokat;
  • @megemlíteni mindenkit, akivel együtt szeretnél dolgozni, vagy később @megemlítheted őket a megjegyzésekben;
  • kérdezni a kollégáidat, hogy segítsenek valamiben vagy ellenőrizzék valami konkrétat.

Miután megnyitottad a PR-t, a tesztek futnak, amelyeket beállítottak arra, hogy ilyen esetekben fussanak. A mi esetünkben ez ugyanaz a tesztkészlet lesz, amelyet helyben futtattunk, de egy valódi projektben lehetnek további tesztek és ellenőrzések.

Kérjük, várjon, amíg a tesztek befejeződnek. A tesztek állapotát a PR megbeszélésének alsó részén láthatja a GitHub felületén. Folytassa, amikor a tesztek befejeződtek.

️ Adjon hozzá megjegyzést a CI lépések önkényességéről.

A tanfolyamon használt lista önkényes és szubjektív, meg kell jegyeznünk ezt.

️ Feladat: pull request létrehozása a megjegyzéshez.

1. Váltson a master.
2. Hozzon létre egy ágat a következő névvel: verziók. Ezt a.
3. Adja hozzá a megjegyzés szövegét a fájl végéhez. ci.md.

   > **GitHub folyamat** néha egy olyan törzs-alapú fejlesztési íz névként használt kifejezés, 
   mikor a kód közvetlenül a funkcióágakról van telepítve. Ez a lista csak egy értelmezés 
   , amelyet a [DevOps kurzusaimban](http://redpill.solutions) használok. 
   A hivatalos útmutató [itt található](https://guides.github.com/introduction/flow/).

4. Kötelezze el a változtatásokat.
5. Publish the branch. verziók. Ezt a a távoli tárolóba.
6. Hozzon létre egy pull requestet a következő névvel: Megjegyzés hozzáadása a fő ággal verziók. Ezt a és az alap ággalmaster.

Make sure you set master in your fork of the repository as the "base branch," I will not respond to change requests in the repository with course materials.

Így kell kinéznie a tárolójának.

Csapatok

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

Hagyja jóvá a "Megjegyzés hozzáadása" pull requestet.

️ Feladat

1. Hozzon létre egy pull requestet.
2. Kattintson a "Merge pull request" gombra.
3. Kattintson a "Confirm merge" gombra.
4. Kattintson a "Delete branch" gombra, már nincs szükség rá.

Ez a merge utáni elkötelezési diagramos.

️ Folytassa a munkát, és adjon hozzá teszteket.

A pull request-ek közös munkája gyakran további munka szükségességéhez vezet. Ez általában a kódellenőrzés vagy a megbeszélés eredménye, de a tanfolyamon ezt a CI lépések listájába új elemek hozzáadásával fogjuk modellezni.

Folyamatos integráció során általában alkalmaznak bizonyos tesztlefedettséget. A tesztlefedettség követelményei változóak, és általában egy "szerzői útmutató"-nak nevezett dokumentumban találhatóak. Mi most egyszerűen annyit teszünk, hogy egy tesztet adunk minden egyes sorhoz a listánkban.

A feladatok elvégzése során először próbáljon meg teszteket elkötelezni. Ha helyesen állította be a pre-commit hook-ot korábban, az éppen hozzáadott teszt futtatásra kerül, nem fog átmenni, és semmi sem lesz elkötelezve. Vegye figyelembe: így tudjuk, hogy a tesztjeink valóban ellenőrzik a dolgokat. Érdekes, hogy ha a kódot a tesztek előtt kezdtük volna el, a tesztek áthaladása jelenthette volna, hogy a kód úgy működik, ahogy vártuk, vagy hogy a tesztek valójában semmit nem ellenőriznek. Ezenkívül, ha egyáltalán nem írtunk volna teszteket, elfelejthettük volna őket, mivel semmi sem emlékeztetett volna minket erre.

Tesztelés alapú fejlesztés (TDD)

A TDD tanácsolja, hogy a teszteket a kód előtt írjuk meg. A TDD használatával végzett szokásos munkafolyamat a következőképpen néz ki.

1. Adjon hozzá tesztet.
2. Futtassa az összes tesztet, és győződjön meg arról, hogy az új teszt nem teljesít sikeresen.
3. Írja meg a kódot.
4. Futtassa a teszteket, és győződjön meg arról, hogy az összes teszt sikeresen teljesül.
5. Refaktorálja a kódot.
6. Ismételje meg.

Mivel a nem sikerült tesztek eredményei általában pirossal, a sikeresen teljesültek pedig zölddel jelennek meg, ezt a ciklust "piros-zöld-refaktorálásnak" nevezik.

️ Feladat

Először próbálja meg elkötelezni a teszteket, és hagyja, hogy kudarcot valljanak, majd adja hozzá és kötelezze el a CI lépések szövegét. Látni fogja, hogy a tesztek sikeresek ("zöldek").
Ezután publikálja az új kódot a távoli tárolóba, és nézze meg, hogyan futnak a tesztek a GitHub felületén a lekérdezési javaslat alján, és frissül a PR státusz.

1. Váltson a feature.

2. Adja hozzá ezeket a teszteket ci.test.js az utolsó hívás után it (...);.

   it('5. Olvassza össze/rebase a commitokat a masterből. A tesztek sikeres teljesítése a merge eredményénél.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Telepítse a funkcióágat a termelésre.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Ha a termelésben minden rendben van egy ideig, olvassza össze a változásokat a masterbe.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Próbálja meg elkötelezni a teszteket. Ha pre-commit a hook be van állítva, az elkötelezés kísérlete hibával zárul.
4. Ezután adja hozzá ezt a szöveget ci.md.

   5. Olvassza össze/rebase a commitokat a masterből. A tesztek sikeres teljesítése a merge eredményénél.  
   6. Telepítse a funkcióágat egy rejtett hibával a termelésre.
   7. Ha a termelésben minden rendben van egy ideig, olvassza össze a változásokat a masterbe. 

5. Készítse el és kötelezze el a változtatásokat helyben.
6. Publikálja a változtatásokat az ágon feature.

Most valami ilyesminek kellene lennie

Csapatok

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

Összeolvadási konfliktus

Navigáljon a pull requesthez Steps review.

Bár nem tettünk semmi rosszat, és a tesztek sikeresen teljesültek a kódunkhoz, még mindig nem tudjuk végrehajtani az ág egyesítését. feature és master. Ennek oka, hogy egy másik ág verziók. Ezt a össze lett vonva a master míg mi ezen a PR-en dolgoztunk.
Ez olyan helyzetet teremt, ahol a távoli ág master újabb verzióval rendelkezik, mint amit az alapként használtunk az águnk. feature. Emiatt nem tudjuk egyszerűen visszafelé léptetni a HEAD-ot master az ág végéhez. feature. Ebben a helyzetben vagy össze kell olvasztanunk (merge), vagy alkalmaznunk kell a commitokat feature a tetejére (rebase). masterA GitHub valóban képes automatikusan végrehajtani a merge-t, ha nincsenek konfliktusok. Sajnos a mi esetünkben mindkét ágon versengő változások vannak a fájlban. ci.mdEzt a helyzetet merge konfliktusnak hívják, és manuálisan kell megoldanunk.

Merge vagy rebase

Merge

• További merge commit-ot hoz létre, és megőrzi a munka történetét.
  • Megőrzi az ágon lévő eredeti commitokat az eredeti időbélyegekkel és szerzőkkel.
  • Megőrzi a commit SHA-ját és a hivatkozásokat a pull requestek vitáiban.
• Egyszeri konfliktusok megoldását igényli.
• Nelineárissá teszi a történetet.
  • A történet nehezen olvasható lehet a sok ág miatt (IDE kábelhez hasonlít).
  • Megnehezíti az automatikus hibakeresést, például megnehezíti a git bisect használatát, ami kevesebb hasznos, mivel csak a merge commitot találja meg.

Rebase

• A jelenlegi ágon lévő commitokat egymás után reprodukálja az alap fölött.
  • Új commitok keletkeznek új SHA-kal, így a GitHubon található commitok a kiindulási pull requestekhez tartoznak, de nem a megfelelő megjegyzésekhez.
  • A commitok rekombinálhatók és módosíthatók a folyamat során, vagy akár egybe is vonhatók.
• Lehet, hogy több konfliktust kell megoldani.
• Lehetővé teszi a lineáris történet fenntartását.
  • A történet könnyebben olvasható lehet, ha nem túl hosszú, ésszerű okok nélkül.
  • Az automatikus hibakeresés és a hibaelhárítás kissé egyszerűbb: lehetővé teszi, a git bisect használatát,hogy az automatikus visszavonások világosabbak és kiszámíthatóbbak legyenek.
• Megköveteli az ágat a migrált commitokkal a jelzővel --force pull requestek során.

Általában a csapatok egyetértenek abban, hogy mindig ugyanazt a stratégiát használják, amikor változásokat kell összevonniuk. Ez lehet egy "tiszta" merge vagy "tiszta" commit alkalmazás az alap fölé, vagy valami köztes, például a commitok interaktív módban alkalmazásának végrehajtása (git rebase -i) helyben, az egyes ágon, amelyeket nem osztottak meg a közös tárolóban, de merge a "nyilvános" ágakhoz.

Itt merge-t fogunk használni.

️ Feladat

1. Győződjön meg arról, hogy a kód a helyi ágon master frissítve van a távoli tárolóból.
2. Váltson a feature.
3. Indítson el egy merge-t az ággal master. Konfliktus lép fel a versengő változásokkal kapcsolatos merge előtt. ci.md.
4. Oldja meg a konfliktust úgy, hogy a szövegben megmaradjon a mi CI lépéseink listánk és a róla szóló megjegyzés.
5. Tegye közzé a visszavonásos elágazás újabb változatát a távoli ágon feature.
6. Ellenőrizze a pull request státuszát a GitHub felhasználói felületén, várja meg, amíg a megoldás nem kész.

Csapatok

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

Nagyszerű munka!

Befejezte a lista feldolgozását, most pedig jóvá kell hagynia a pull request-et a következő helyen master.

️ Feladat: Jóváhagyja a pull request-et "Steps review"

1. Nyissa meg a pull request-et.
2. Kattintson a "Merge pull request" gombra.
3. Kattintson a "Confirm merge" gombra.
4. Kattintson a "Branch törlése" gombra, mivel már nincs rá szükségünk.

Ez az Ön adattára jelenleg

Hiba a termelési környezetben

Azt mondják, hogy "a tesztelés felhasználható a hibák meglétének bizonyítására, de soha nem a hiányukra". Annak ellenére, hogy voltak tesztjeink, és azok nem mutattak hibákat, egy alattomos hiba becsúszott a termelésbe.

Ebben a helyzetben figyelmet kell fordítanunk:

• arra, ami a termelési környezetben van telepítve;
• a hibás kódra, amelyből a fejlesztők új munkát kezdhetnek. master Visszaállítjuk vagy javítjuk a következő verzióban?

"Visszaállítás" (rolling back) – egy korábban bevált változat telepítése a termelési környezetbe és azok a commitok visszavonása (revert), amelyek hibát tartalmaznak. "Javítás a következő verzióban" (fixing forward) – tényként a javítás hozzáadása a

majd a lehető leggyorsabban új verzió telepítése. Mivel az API és az adatbázis sémái folyamatosan változnak a kód termelési környezetbe történő telepítése során, a folyamatos szállítás mellett és a megfelelő tesztelési lefedettség biztosításával a visszaállítás általában sokkal bonyolultabb és kockázatosabb, mint a következő verzióban történő javítás. master Mivel a visszaállítás esetünkben nem jár kockázattal, ezt az utat választjuk, hiszen ez lehetővé teszi számunkra, hogy

a hibát a lehető leggyorsabban kijavítsuk a termelésben;

• a kódot
• azonnal alkalmasnak tegyük új munka megkezdésére. master helyben.

️ Feladat

1. Váltson a master Frissítse a helyi adattárát a távoli adattárból.
2. Vonja vissza a pull request visszavonásos commitját
3. Közzétenni a változásokat a távoli adattárban. Steps review be. master.
4. Ez az adattár története a visszavont visszavonásos commit után

️ Önvizsgálat

Csapatok

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

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

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

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

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

többé nem tartalmazza a "sneaky bug" szöveget a visszavont commit után.

Bizonyosodjon meg arról, hogy ci.md Javítsa ki a CI lépések listáját, és térjen vissza a master ágba

Teljesen visszavontuk a visszavonásos commitot az ágból

. A jó hír az, hogy mostantól nincs hiba a feature. A jó hír az, hogy most már nincs hibánk a masterA rossz hír az, hogy eltűnt a kedves folyamatos integrációs lépéseink listája. Így az ideális az, hogy alkalmazzuk a javítást a commitokra, feature és visszaállítsuk őket master a javítással együtt.

Különböző módokon közelíthetjük meg a feladatot:

• visszavonni (revert) a commitot, ami visszavonja a merge-t feature a master;
• áthelyezni a commitokat a korábbi feature.

Különböző fejlesztői csapatok különböző megközelítéseket használnak ebben az esetben, mi hasznos commitokat a külön branchbe helyezünk, és létrehozunk egy külön pull request-et ehhez az új branchhez.

️ Feladat

1. Hozzon létre egy branch-et a következő névvel: feature-fix és váltson át rá.

2. Helyezze át az összes commitot a korábbi branchből feature az új branchbe. Oldja meg a merge konfliktusokat, amelyek áthelyezéskor merültek fel.

   

3. Adjon hozzá regressziós tesztet a ci.test.js:

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

4. Futtassa a teszteket helyben, hogy megbizonyosodjon róla, hogy nem végződnek sikeresen.
5. Törölje a " with a sneaky bug" szöveget a ci.md.
6. Adja hozzá az indexhez a tesztváltozásokat és a lépéslisták módosításait, majd commitálja őket.
7. Publikálja a branch-et a távoli repository-ban.

Az eredménynek ilyennek kell lennie

Csapatok

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

Hozzon létre egy pull requestet.

Create a pull request titled Fixing the feature. Set feature-fix mint "head branch", és master as the "base branch."
Kérjük, várjon, amíg befejeződnek a tesztek. Megnézheti a tesztek állapotát a PR megbeszélésének alján.

Make sure you set master in your fork of the repository as the "base branch," I will not respond to change requests in the repository with course materials.

Húzza meg a pull requestet az "Fixing the feature"

Köszönjük a javítást! Kérjük, hagyja jóvá a változásokat a master a pull requestből.

️ Feladat

1. Kattintson a "Merge pull request" gombra.
2. Kattintson a "Confirm merge" gombra.
3. Kattintson a "Branch törlése" gombra, mivel már nincs rá szükségünk.

Ez az, aminek most lennie kellene

Gratulálok!

Minden lépést megtett, amit az emberek általában egy folyamatos integrációs folyamat során végeznek.

Ha bármilyen problémát észlel a kurzussal kapcsolatban vagy tudja, hogyan lehetne javítani, hozzon létre egy issue-t a kurzus anyagait tartalmazó repository-ban.Ennek a kurzusnak van egy interaktív változata amely a GitHub Learning Lab-ot használja platformként.

Forrás: habr.com