Naučili jste se příkazy Git, ale chcete si představit, jak kontinuální integrace (CI) funguje ve skutečnosti? Nebo možná chcete optimalizovat své každodenní aktivity? Tento kurz vám dá praktické dovednosti v nepřetržité integraci pomocí úložiště GitHub. Tento kurz není zamýšlen jako průvodce, kterým se jednoduše proklikáte, naopak budete provádět stejné úkony, jaké lidé ve skutečnosti dělají v práci, stejným způsobem, jakým to dělají. Vysvětlím vám teorii, když projdete jednotlivými kroky.

Co děláme?

Jak budeme postupovat, budeme postupně vytvářet seznam typických kroků CI, což je skvělý způsob, jak si tento seznam zapamatovat. Jinými slovy, vytvoříme seznam akcí, které vývojáři provádějí při průběžné integraci, při průběžné integraci. Použijeme také jednoduchou sadu testů, abychom náš proces CI přiblížili skutečnému.

Tento GIF schematicky ukazuje odevzdání ve vašem úložišti, jak postupujete kurzem. Jak vidíte, není zde nic složitého a jen to nejnutnější.

Projdete si následujícími standardními scénáři CI:

• Práce na prvku;
• Aplikace automatizovaných testů k zajištění kvality;
• Realizace prioritního úkolu;
• Řešení konfliktů při slučování větví (konflikt sloučení);
• V produkčním prostředí dojde k chybě.

co se naučíš?

Budete moci odpovědět na následující otázky:

• Co je kontinuální integrace (CI)?
• Jaké typy automatických testů se používají v CI a v reakci na jaké akce jsou spouštěny?
• Co jsou požadavky na stažení a kdy jsou potřeba?
• Co je to Test Driven Development (TDD) a jak souvisí s CI?
• Mám sloučit nebo znovu založit změny?
• Vrátit zpět nebo opravit v další verzi?

Nejprve jsem všude překládal věci jako „pull request“, ale ve výsledku jsem se rozhodl na některá místa vrátit fráze v angličtině, abych snížil míru šílenství v textu. Někdy použiji „programátorský surzhik“ jako úžasné sloveso „zavázat se“, kde ho lidé skutečně používají v práci.

Co je kontinuální integrace?

Průběžná integrace, neboli CI, je technická praxe, při které každý člen týmu alespoň jednou denně integruje svůj kód do společného úložiště a výsledný kód musí být alespoň sestaven bez chyb.

Ohledně tohoto termínu panují neshody

Sporným bodem je frekvence integrace. Někteří tvrdí, že sloučení kódu pouze jednou denně nestačí k tomu, aby se integroval nepřetržitě. Je uveden příklad týmu, kde si každý ráno vezme čerstvý kód a jednou večer ho integruje. I když je to rozumná námitka, obecně se má za to, že definice jednou denně je přiměřeně praktická, specifická a vhodná pro týmy různých velikostí.

Další námitkou je, že C++ již není jediným jazykem používaným při vývoji a jednoduše vyžadovat bezchybné sestavení jako způsob ověření je slabé. Některé sady testů (například jednotkové testy prováděné lokálně) musí být také úspěšně dokončeny. V tuto chvíli komunita směřuje k tomu, aby to byl požadavek a v budoucnu se „build + unit testy“ pravděpodobně stanou běžnou praxí, pokud se tak již nestalo.

Průběžná integrace jiné než nepřetržité doručování (Continuous Delivery, CD) v tom, že nevyžaduje kandidáta na vydání po každém integračním cyklu.

Seznam kroků, které budeme v průběhu kurzu používat

1. Vytáhněte nejnovější kód. Vytvořte větev z master. Začít pracovat.
2. Vytvořte commity na vaší nové větvi. Vytvářejte a testujte lokálně. Složit? Přejděte k dalšímu kroku. Selhat? Opravte chyby nebo testy a zkuste to znovu.
3. Push do vašeho vzdáleného úložiště nebo vzdálené pobočky.
4. Vytvořte požadavek na stažení. Diskutujte o změnách, přidávejte další commity, jak diskuse pokračuje. Zajistěte, aby testy prošly ve větvi funkcí.
5. Sloučit/rebase odevzdat z hlavního. Zajistěte, aby testy předaly výsledek sloučení.
6. Nasazení z hlavní větve do produkce.
7. Pokud je v produkci po určitou dobu vše v pořádku, sloučte změny do masteru.

️ Příprava

Ujistěte se, že máte správný software

K absolvování tohoto kurzu budete potřebovat Node.js и Klient Git.

Můžete použít libovolného klienta Git, ale já poskytnu pouze příkazy pro příkazový řádek.

Ujistěte se, že máte nainstalovaného klienta Git, který podporuje příkazový řádek

Pokud ještě nemáte klienta Git, který podporuje příkazový řádek, najdete pokyny k instalaci zde.

Připravte úložiště

Budete si muset vytvořit osobní kopii (fork) úložiště šablon s kódem pro kurz na GitHubu. Dohodněme se, že tuto osobní kopii nazveme úložiště kurzů.

Hotovo? Pokud jste nezměnili výchozí nastavení, pravděpodobně se nazývá vaše úložiště kurzu continuous-integration-team-scenarios-students, nachází se ve vašem účtu GitHub a adresa URL vypadá takto

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

Jednoduše zavolám na tuto adresu <URL репозитория>.

Úhlové závorky jako <тут> bude znamenat, že musíte nahradit takový výraz příslušnou hodnotou.

Ujistit se, že Akce GitHubu součástí tohoto úložiště kurzů. Pokud nejsou povoleny, povolte je prosím kliknutím na velké tlačítko uprostřed stránky, na které se dostanete kliknutím na Akce v rozhraní GitHubu.

Pokud nejsou povoleny akce GitHub, nebudete moci dokončit kurz podle mých pokynů.

Vždy můžete použít schopnost GitHubu vykreslit Markdown, abyste viděli aktuální stav seznamu, který zde vytváříme

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

O odpovědích

I když nejlepší způsob, jak tento kurz dokončit, je udělat si to sami, můžete mít určité potíže.

Pokud máte pocit, že nerozumíte tomu, co máte dělat, a nemůžete pokračovat, můžete se podívat do vlákna solution, který je ve vašem počátečním úložišti.
Prosím neslučujte solution в master během kurzu. Pomocí této větve můžete zjistit, co dělat, nebo porovnat svůj kód s kódem autora s využitím všech možností, které nám Git poskytuje. Pokud jste úplně ztraceni, můžete svou ratolest zcela nahradit master na větvi solution a poté resetujte svůj pracovní adresář na krok kurzu, který potřebujete.

Používejte jej pouze v případě, že to opravdu potřebujete

Zadejte svůj kód

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

Tyto příkazy

• přejmenovat master в master-backup;
• přejmenovat solution в master;
• pokladna do nové pobočky master a přepsat obsah pracovního adresáře;
• Vytvořte větev „řešení“ z „master“ (což bývalo „řešení“) pro případ, že byste v budoucnu potřebovali větev „řešení“.

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

Po těchto krocích můžete použít git log master abyste zjistili, který závazek potřebujete.
Svůj pracovní adresář můžete resetovat na toto potvrzení takto:

git reset --hard <the SHA you need>

Pokud jste s výsledkem spokojeni, v určitém okamžiku budete muset publikovat svou verzi úložiště do vzdáleného úložiště. Když to uděláte, nezapomeňte explicitně specifikovat vzdálenou větev.

git push --force origin master

Vezměte prosím na vědomí, že používáme git push --force. Je nepravděpodobné, že to budete chtít dělat velmi často, ale máme zde velmi specifický scénář s jedním uživatelem úložiště, který navíc rozumí tomu, co dělá.

Začátek práce

Začněme sestavovat náš seznam kroků CI. Normálně byste tento krok začali kontrolou nejnovější verze kódu ze vzdáleného úložiště, ale zatím nemáme místní úložiště, takže jej místo toho naklonujeme ze vzdáleného úložiště.

️ Úkol: aktualizovat místní úložiště, vytvořit větev z master, začít pracovat

1. Naklonujte úložiště kurzů z <URL репозитория>.
2. Běh npm install v adresáři úložiště kurzů; Potřebujeme ho k instalaci Jestu, který používáme ke spouštění testů.
3. Vytvořte větev a pojmenujte ji feature. Přejít na toto vlákno.

4. Přidejte testovací kód do ci.test.js mezi komentáři, které mě žádají, abych to udělal.

   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. Přidejte do souboru text s prvními 4 kroky 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.  

   Týmy

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

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

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

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

Vytvářejte odevzdání na nové větvi, sestavujte a testujte lokálně

Nastavíme testy tak, aby se spustily před potvrzením, a poté potvrdíme kód.

Typické scénáře, kdy se testy spouštějí automaticky

• Lokálně:
  • Průběžně nebo v reakci na příslušné změny kódu;
  • Při ukládání (pro tlumočené jazyky nebo jazyky kompilované JIT);
  • Během sestavování (když je vyžadována kompilace);
  • Při odevzdání;
  • Při publikování do sdíleného úložiště.

• Na sestavení serveru nebo prostředí sestavení:
  • Když je kód publikován do osobní pobočky/úložiště.
  • Kód v tomto vlákně se testuje.
  • Testuje se potenciální výsledek fúze (obvykle s master).
  • Jako kontinuální integrační stupeň/průběžné zásobovací potrubí

Obvykle platí, že čím rychleji testovací sada běží, tím častěji si ji můžete dovolit spouštět. Typické rozložení jeviště může vypadat takto.

• Rychlé testy jednotek - během stavby, v CI potrubí
• Pomalé testy jednotek, rychlé testy komponent a integrace – při odevzdání, v CI pipeline
• Pomalé testy komponent a integrace - v potrubí CI
• Testování zabezpečení, zátěžové testování a další časově náročné nebo drahé testy – v kanálech CI/CD, ale pouze v určitých režimech/fázích/potrubích sestavení, například při přípravě kandidáta na vydání nebo při ručním spouštění.

️ Zadání

Doporučuji nejprve spustit testy ručně pomocí příkazu npm test. Poté přidáme git hook pro spuštění našich testů při odevzdání. Má to jeden háček: Git hooky nejsou považovány za součást úložiště, a proto je nelze klonovat z GitHubu spolu se zbytkem materiálů kurzu. Chcete-li nainstalovat hook, musíte spustit install_hook.sh nebo zkopírujte soubor repo/hooks/pre-commit do místního adresáře .git/hooks/.
Když provedete potvrzení, uvidíte, že jsou spuštěny testy a kontrolují, zda jsou v seznamu přítomna určitá klíčová slova.

1. Spusťte testy ručně spuštěním příkazu npm test ve složce úložiště kurzu. Ověřte, že testy byly dokončeny.
2. Spuštěním nastavte háček pro odevzdání (pre-commit hook). install_hook.sh.
3. Odešlete změny do místního úložiště.
4. Před potvrzením se ujistěte, že jsou spuštěny testy.

Vaše úložiště by po provedení těchto kroků mělo vypadat takto.

Týmy

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

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

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

Publikování kódu do vzdáleného úložiště nebo vzdálené pobočky

Jakmile dokončí práci na místě, vývojáři obvykle zpřístupní svůj kód veřejně, aby jej bylo možné případně integrovat s veřejností. U GitHubu se toho obvykle dosahuje publikováním díla buď do osobní kopie úložiště (osobní vidlice) nebo do osobní pobočky.

• Pomocí forků vývojář naklonuje vzdálené sdílené úložiště a vytvoří jeho osobní vzdálenou kopii, známou také jako fork. Poté naklonuje toto osobní úložiště, aby se s ním mohlo pracovat lokálně. Když je práce dokončena a jsou provedeny commity, vloží je do své vidlice, kde jsou k dispozici ostatním a mohou být integrovány do společného úložiště. Tento přístup se běžně používá v open source projektech na GitHubu. Používá se také v mém pokročilém kurzu [Týmová práce a CI s Git] (http://devops.redpill.solutions/).
• Dalším přístupem je použít pouze jedno vzdálené úložiště a počítat pouze větev master sdílené úložiště "chráněné". V tomto scénáři jednotliví vývojáři publikují svůj kód do větví vzdáleného úložiště, aby se ostatní mohli na tento kód podívat, pokud je vše v pořádku, sloučit jej s master sdílené úložiště.

V tomto konkrétním kurzu budeme používat pracovní postup, který využívá větve.

Pojďme publikovat náš kód.

️ Zadání

• Publikujte změny ve vzdálené větvi se stejným názvem, jako má vaše pracovní větev

Týmy

git push --set-upstream origin feature

Vytvořte žádost o stažení

Vytvořte požadavek na stažení s názvem Kontrola kroků... Nainstalujte feature jako "hlavní větev" a master jako "základní větev".

Ujistěte se, že jste nainstalovali master v jeho rozvětvete úložiště Jako „základní pobočka“ nebudu reagovat na žádosti o změny v úložišti studijních materiálů.

V jazyce GitHub je „základní větev“ větev, na které zakládáte svou práci, a „hlavní větev“ je větev obsahující navrhované změny.

Diskutujte o změnách, přidávejte nové odevzdání, jak diskuse pokračuje

Pull request (PR)

Pull request (PR) je způsob, jak diskutovat a dokumentovat kód, stejně jako provádět přezkum kódu. Pull requesty jsou pojmenovány podle obecného způsobu integrace jednotlivých změn do celkového kódu. Osoba obvykle klonuje vzdálené oficiální úložiště projektu a pracuje na kódu lokálně. Poté umístí kód do svého osobního vzdáleného úložiště a požádá osoby odpovědné za oficiální úložiště, aby vyzvedli(táhnout) jeho kód do svých místních úložišť, kde zkontrolují a případně integrují(spojit) jeho. Tento pojem je znám i pod jinými názvy, např. žádost o sloučení.

Ve skutečnosti nemusíte používat funkci pull request GitHubu nebo podobných platforem. Vývojové týmy mohou používat jiné způsoby komunikace, včetně osobní komunikace, hlasových hovorů nebo e-mailu, ale stále existuje řada důvodů, proč používat žádosti o stažení ve stylu fóra. Tady jsou některé z nich:

• organizované diskuse týkající se konkrétních změn kódu;
• jako místo pro zobrazení zpětné vazby o probíhající práci od autotesterů i kolegů;
• formalizace kontrol kódu;
• abyste později mohli zjistit důvody a úvahy za tím či oním kódem.

Obvykle vytvoříte žádost o stažení, když potřebujete něco prodiskutovat nebo získat zpětnou vazbu. Pokud například pracujete na funkci, kterou lze implementovat více než jedním způsobem, můžete před napsáním prvního řádku kódu vytvořit požadavek na stažení, abyste mohli sdílet své nápady a prodiskutovat své plány se svými spolupracovníky. Pokud je práce jednodušší, otevře se požadavek na stažení, když již bylo něco provedeno, potvrzeno a lze o tom diskutovat. V některých scénářích můžete chtít otevřít PR pouze z důvodů kontroly kvality: pro spuštění automatických testů nebo zahájení kontroly kódu. Ať už se rozhodnete jakkoli, nezapomeňte ve své žádosti o stažení @zmínit lidi, jejichž souhlas chcete.

Při vytváření PR obvykle uděláte následující.

• Uveďte, co navrhujete změnit a kde.
• Napište popis vysvětlující účel změn. Možná budete chtít:
  • přidejte cokoliv důležitého, co není zřejmé z kódu, nebo něco užitečného pro pochopení kontextu, jako jsou relevantní #chyby a čísla odevzdání;
  • @zmiňte se o někom, s kým chcete začít pracovat, nebo se o nich můžete @zmínit v komentářích později;
  • požádat kolegy, aby s něčím pomohli nebo ověřili něco konkrétního.

Jakmile otevřete PR, provedou se testy nakonfigurované pro spuštění v takových případech. V našem případě se bude jednat o stejnou sadu testů, které jsme spustili lokálně, ale ve skutečném projektu mohou existovat další testy a kontroly.

Počkejte prosím na dokončení testů. Na stav testů se můžete podívat dole v PR diskuzi v rozhraní GitHubu. Po dokončení testů pokračujte.

️ Přidejte poznámku o náhodnosti seznamu kroků CI

Seznam použitý v tomto kurzu je libovolný a subjektivní, k tomu bychom měli přidat poznámku.

️ Úkol: vytvořte žádost o stažení tohoto komentáře

1. Přepnout na pobočku master.
2. Vytvořte větev s názvem bugfix.
3. Přidejte text poznámky na konec souboru 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. Potvrďte změny.
5. Publikovat vlákno bugfix do vzdáleného úložiště.
6. Vytvořte požadavek na stažení s názvem Přidání poznámky s hlavní větví bugfix a základní větevmaster.

Ujistěte se, že jste nainstalovali master v jeho rozvětvete úložiště Jako „základní pobočka“ nebudu reagovat na žádosti o změny v úložišti studijních materiálů.

Takto by měl vypadat váš repozitář.

Týmy

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

Schválit žádost o stažení "Přidání poznámky"

️ Zadání

1. Vytvořte žádost o stažení.
2. Klikněte na "Merge pull request".
3. Klikněte na "Potvrdit sloučení".
4. Klikněte na "Odstranit větev", již ji nepotřebujeme.

Toto je diagram odevzdání po sloučení.

️ Pokračujte v práci a přidávejte testy

Spolupráce na žádosti o stažení často vede k další práci. Obvykle je to výsledek kontroly kódu nebo diskuse, ale v našem kurzu to budeme modelovat přidáním nových položek do našeho seznamu kroků CI.

Nepřetržitá integrace obvykle zahrnuje určité testovací pokrytí. Požadavky na pokrytí testů se liší a obvykle se nacházejí v dokumentu zvaném něco jako „pokyny pro příspěvky“. Budeme to dělat jednoduše a přidáme test pro každý řádek v našem kontrolním seznamu.

Při spouštění úkolů zkuste nejprve odevzdat testy. Pokud jste správně nainstalovali pre-commit háček dříve, nově přidaný test bude spuštěn, selže a nic nebude potvrzeno. Všimněte si, že takto víme, že naše testy skutečně něco testují. Zajímavé je, že pokud jsme s kódem začali před testy, úspěšné absolvování testů by mohlo znamenat, že kód fungoval podle očekávání, nebo že testy ve skutečnosti nic netestovaly. Navíc, kdybychom ty testy na začátku nenapsali, možná bychom na ně úplně zapomněli, protože by nám to nic nepřipomínalo.

Testem řízený vývoj (TDD)

TDD doporučuje psát testy před kódem. Typický pracovní postup využívající TDD vypadá takto.

1. Přidejte test.
2. Spusťte všechny testy a ujistěte se, že nový test selže.
3. Napište kód.
4. Spusťte testy a ujistěte se, že všechny testy prošly.
5. Refaktorujte svůj kód.
6. Opakovat.

Protože výsledky testů, které selžou, jsou obvykle zobrazeny červeně a ty, které prošly úspěšně, jsou obvykle zobrazeny zeleně, je cyklus také známý jako červeno-zelený-reaktor.

️ Zadání

Nejprve se pokuste odevzdat testy a nechat je selhat, poté přidejte a potvrďte text samotného seznamu kroků CI. Uvidíte, že testy projdou ("zelená").
Poté publikujte nový kód do vzdáleného úložiště a sledujte testy spuštěné v rozhraní GitHubu v dolní části diskuze o žádosti o stažení a aktualizaci stavu PR.

1. Přepnout na pobočku feature.

2. Přidejte tyto testy do ci.test.js po posledním hovoru 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. Zkuste podstoupit testy. Li pre-commit hák nainstalován, pokus o potvrzení se nezdaří.
4. Poté přidejte tento text do 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. Provádějte a potvrzujte změny lokálně.
6. Odešlete změny do pobočky feature.

Nyní byste měli mít něco takového

Týmy

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

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

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

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

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

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

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

Konflikt sloučení

Přejděte na Požadavek na změnu Kontrola kroků.

I když jsme neudělali nic špatného a testy pro náš kód prošly, stále nemůžeme větev sloučit feature и master. Je to kvůli tomu druhému vláknu bugfix byl sloučen s master když jsme pracovali na tomto PR.
To vytváří situaci, kdy vzdálená větev master má novější verzi, než na které jsme založili větev feature. Z tohoto důvodu nemůžeme jen přetočit HEAD master do konce vlákna feature. V této situaci musíme buď sloučit, nebo použít odevzdání feature rebase master. GitHub může skutečně provádět automatické slučování, pokud nedochází ke konfliktům. Bohužel, v naší situaci mají obě pobočky konkurenční změny v souboru ci.md. Tato situace je známá jako konflikt sloučení a musíme ji vyřešit ručně.

Sloučit nebo přetvořit

Spojit

• Vytvoří další sloučení potvrzení a uloží historii práce.
  • Zachovává původní commity větví s jejich původními časovými razítky a autory.
  • Ukládá SHA odevzdání a odkazy na ně v diskusích o požadavcích na změnu.
• Vyžaduje jednorázové řešení konfliktu.
• Dělá příběh nelineární.
  • Příběh může být obtížně čitelný kvůli velkému počtu větví (připomíná IDE kabel).
  • Znesnadňuje automatické ladění, např. git bisect méně užitečné - najde pouze začlenění commit.

rebase

• Přehraje potvrzení z aktuální větve nad základní větví jeden po druhém.
  • Generují se nová potvrzení s novými SHA, což způsobí, že potvrzení v GitHubu odpovídají původním žádostem o stažení, ale ne odpovídajícím komentářům.
  • Závazky lze v procesu znovu kombinovat a upravovat, nebo dokonce sloučit do jednoho.
• Může být nutné vyřešit více konfliktů.
• Umožňuje udržovat lineární příběh.
  • Příběh se může číst snadněji, pokud není příliš dlouhý bez rozumného důvodu.
  • Automatické ladění a odstraňování problémů je o něco jednodušší: umožňuje to git bisect, může učinit automatické vrácení zpět jasnější a předvídatelnější.
• Vyžaduje publikování větve s migrovanými potvrzeními s příznakem --force při použití s ​​požadavky na vytažení.

Týmy se obvykle dohodnou, že vždy použijí stejnou strategii, když potřebují sloučit změny. Mohlo by to být „čisté“ sloučení nebo „čisté“ odevzdání nahoře nebo něco mezi tím, například interaktivní provedení odevzdání nahoře (git rebase -i) lokálně pro pobočky nezveřejněné do veřejného úložiště, ale sloučené pro „veřejné“ pobočky.

Zde použijeme merge.

️ Zadání

1. Ujistěte se, že kód je v místní pobočce master aktualizovány ze vzdáleného úložiště.
2. Přepnout na pobočku feature.
3. Iniciujte sloučení s větví master. Konflikt sloučení kvůli konkurenčním změnám souboru ci.md.
4. Vyřešte konflikt tak, aby v textu zůstal jak náš seznam kroků CI, tak poznámka k němu.
5. Publikování slučovacího potvrzení do vzdálené větve feature.
6. Zkontrolujte stav žádosti o stažení v uživatelském rozhraní GitHubu a počkejte, dokud se sloučení nevyřeší.

Týmy

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

Dobrá práce!

Se seznamem jste hotovi a nyní musíte schválit žádost o stažení master.

️ Úkol: Schválit žádost o stažení „Kontrola kroků“

1. Otevřete žádost o stažení.
2. Klikněte na "Merge pull request".
3. Klikněte na "Potvrdit sloučení".
4. Klikněte na "Odstranit větev", protože ji již nepotřebujeme.

Toto je v tuto chvíli vaše úložiště

Chyba produktu

Říká se, že „testování lze použít k prokázání přítomnosti chyb, ale nikdy k prokázání jejich nepřítomnosti“. I když jsme měli testy a neukázaly nám žádné chyby, do výroby se vloudila zákeřná chyba.

V takovém scénáři se musíme postarat o:

• co je nasazeno ve výrobě;
• kód ve vláknu master s chybou, od které mohou vývojáři začít novou práci.

Mám to vrátit zpět nebo to opravit v další verzi?

Vrácení zpět je proces nasazení známé dobré dřívější verze do produkce a vrácení potvrzení, která obsahují chybu. "Oprava vpřed" je přidání opravy k souboru master a nasazení nové verze co nejdříve. Vzhledem k tomu, že se rozhraní API a databázová schémata mění s nasazováním kódu do produkce, s nepřetržitým doručováním a dobrým pokrytím testováním, je vrácení zpět obvykle mnohem obtížnější a riskantnější než oprava v další verzi.

Vzhledem k tomu, že rolling back v našem případě nenese žádné riziko, půjdeme touto cestou, protože nám to umožňuje

• opravit chybu na produktu co nejdříve;
• vložit kód master ihned vhodné pro nástup do nového zaměstnání.

️ Zadání

1. Přepnout na pobočku master lokálně.
2. Aktualizujte místní úložiště ze vzdáleného úložiště.
3. Vraťte potvrzení PR sloučení Kontrola kroků в master.
4. Publikujte změny ve vzdáleném úložišti.

Toto je historie úložiště s vráceným potvrzením sloučení

Týmy

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

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

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

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

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

️ Vlastní test

Ujistit se, že ci.md po vrácení sloučení již neobsahuje text „záludná chyba“.

Opravte seznam kroků CI a vraťte jej na hlavní

Kompletně jsme zrušili začlenění větve. feature. Dobrou zprávou je, že nyní nemáme žádnou chybu master. Špatnou zprávou je, že náš drahocenný seznam kontinuálních integračních kroků je také pryč. V ideálním případě tedy musíme opravu použít na commity z feature a vrátit je zpět master spolu s opravou.

K problému můžeme přistupovat různými způsoby:

• vrátit potvrzení, které zruší sloučení feature с master;
• přesun se zavazuje z býv feature.

Různé vývojové týmy v tomto případě používají různé přístupy, ale užitečné commity přesuneme do samostatné větve a vytvoříme pro tuto novou větev samostatný požadavek na stažení.

️ Zadání

1. Vytvořte vlákno s názvem feature-fix a přepnout na něj.

2. Migrujte všechna potvrzení z bývalé větve feature do nového vlákna. Vyřešte konflikty sloučení, ke kterým došlo během migrace.

   

3. Přidejte regresní test do ci.test.js:

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

4. Spusťte testy lokálně, abyste se ujistili, že neselžou.
5. Odstraňte text „se záludnou chybou“. ci.md.
6. Přidejte testovací změny a změny seznamu kroků do indexu a potvrďte je.
7. Publikovat větev do vzdáleného úložiště.

Měli byste skončit s něčím podobným:

Týmy

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

Vytvořte žádost o stažení.

Vytvořte požadavek na stažení s názvem Oprava funkce... Nainstalujte feature-fix jako "hlavní větev" a master jako "základní větev".
Počkejte prosím na dokončení testů. Na stav testů se můžete podívat dole v PR diskuzi.

Ujistěte se, že jste nainstalovali master v jeho rozvětvete úložiště Jako „základní pobočka“ nebudu reagovat na žádosti o změny v úložišti studijních materiálů.

Schválení požadavku na stažení „Oprava funkce“

Díky za opravu! Prosím o schválení změn master z požadavku na vytažení.

️ Zadání

1. Klikněte na "Merge pull request".
2. Klikněte na "Potvrdit sloučení".
3. Klikněte na "Odstranit větev", protože ji již nepotřebujeme.

To je to, co byste v tuto chvíli měli mít.

Gratulujeme!

Dokončili jste všechny kroky, které lidé obvykle provádějí během nepřetržité integrace.

Pokud si všimnete jakýchkoli problémů s kurzem nebo víte, jak jej zlepšit, vytvořte problém v repozitáře s učebními materiály. Tento kurz má také interaktivní verze pomocí GitHub Learning Lab jako platformy.

Zdroj: www.habr.com