Da li ste naučili Git komande, ali želite da zamislite kako kontinuirana integracija (CI) funkcioniše u stvarnosti? Ili možda želite optimizirati svoje dnevne aktivnosti? Ovaj kurs će vam dati praktične vještine u kontinuiranoj integraciji pomoću GitHub repozitorija. Ovaj kurs nije zamišljen da bude čarobnjak kroz koji možete jednostavno kliknuti; naprotiv, izvodit ćete iste radnje koje ljudi zapravo rade na poslu, na isti način na koji to rade. Objasnit ću teoriju dok budete prolazili kroz navedene korake.

Šta da radimo?

Kako napredujemo, postepeno ćemo kreirati listu tipičnih CI koraka, što je odličan način da zapamtite ovu listu. Drugim riječima, kreirat ćemo listu radnji koje programeri poduzimaju dok rade kontinuiranu integraciju, radeći kontinuiranu integraciju. Također ćemo koristiti jednostavan skup testova kako bismo naš CI proces približili stvarnom.

Ovaj GIF šematski prikazuje urezivanje u vašem spremištu kako napredujete kroz kurs. Kao što vidite, ovdje nema ništa komplikovano i samo najpotrebnije.

Proći ćete kroz sljedeće standardne CI scenarije:

• Rad na osobini;
• Primjena automatiziranih testova za osiguranje kvaliteta;
• Realizacija prioritetnog zadatka;
• Rješavanje konflikata pri spajanju grana (konflikt spajanja);
• Došlo je do greške u proizvodnom okruženju.

šta ćeš naučiti?

Moći ćete odgovoriti na sljedeća pitanja:

• Šta je kontinuirana integracija (CI)?
• Koje vrste automatiziranih testova se koriste u CI i kao odgovor na koje akcije se pokreću?
• Šta su pull zahtevi i kada su potrebni?
• Šta je razvoj vođen testom (TDD) i kako je povezan sa CI?
• Da li da spojim ili ponovo baziram promjene?
• Vratiti ili popraviti u sljedećoj verziji?

U početku sam svuda prevodio stvari poput „povuci zahtjeve“, ali sam kao rezultat odlučio da na nekim mjestima vraćam fraze na engleskom kako bih smanjio stepen ludosti u tekstu. Ponekad ću koristiti "programer surzhik" kao divan glagol "počiniti" gdje ga ljudi zapravo koriste na poslu.

Šta je kontinuirana integracija?

Kontinuirana integracija, ili CI, je tehnička praksa u kojoj svaki član tima integriše svoj kod u zajedničko spremište barem jednom dnevno, a rezultirajući kod mora biti izgrađen bez grešaka.

Postoje nesuglasice oko ovog pojma

Poenta spora je učestalost integracije. Neki tvrde da spajanje koda samo jednom dnevno nije dovoljno za kontinualnu integraciju. Naveden je primjer tima gdje svi uzimaju svježi kod ujutro i integriraju ga jednom uveče. Iako je ovo razuman prigovor, općenito se vjeruje da je definicija jednom dnevno razumno praktična, specifična i pogodna za timove različitih veličina.

Još jedan prigovor je da C++ više nije jedini jezik koji se koristi u razvoju, a jednostavno zahtijevanje asemblera bez grešaka kao načina validacije je slabo. Neki skup testova (na primjer, jedinični testovi koji se izvode lokalno) također se moraju uspješno završiti. U ovom trenutku, zajednica se kreće ka tome da ovo postane uslov, a u budućnosti će "build + unit testovi" vjerovatno postati uobičajena praksa, ako već nije.

Kontinuirana integracija razlikuje se od kontinuirana isporuka (Kontinuirana isporuka, CD) jer ne zahtijeva kandidata za izdavanje nakon svakog ciklusa integracije.

Lista koraka koje ćemo koristiti tokom kursa

1. Ubacite najnoviji kod. Kreirajte granu iz master. Počnite raditi.
2. Kreirajte urezivanje na vašoj novoj grani. Izgradite i testirajte lokalno. Proći? Idite na sljedeći korak. Fail? Ispravite greške ili testove i pokušajte ponovo.
3. Gurnite u vaše udaljeno spremište ili udaljenu granu.
4. Kreirajte zahtjev za povlačenjem. Razgovarajte o promjenama, dodajte još urezivanja kako se diskusija nastavi. Učinite da testovi prođu na grani karakteristika.
5. Spajanje/rebaziranje urezivanja sa mastera. Neka testovi prođu rezultat spajanja.
6. Postavite od grane funkcije do proizvodnje.
7. Ako je sve dobro u produkciji neko vrijeme, spojite promjene u master.

️ Priprema

Provjerite imate li pravi softver

Za pohađanje ovog kursa trebaće vam node.js и Git klijent.

Možete koristiti bilo koji Git klijent, ali ja ću dati samo naredbe za komandnu liniju.

Uvjerite se da imate instaliran Git klijent koji podržava komandnu liniju

Ako još nemate Git klijenta koji podržava komandnu liniju, možete pronaći upute za instalaciju ovdje.

Pripremite spremište

Morat ćete kreirati ličnu kopiju (fork) spremište šablona sa kodom za kurs na GitHubu. Hajde da se dogovorimo da ovu ličnu kopiju nazovemo spremište kurseva.

Gotovo? Ako niste promijenili zadane postavke, najvjerovatnije će biti pozvano vaše spremište kursa continuous-integration-team-scenarios-students, nalazi se na vašem GitHub nalogu i URL izgleda ovako

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

Ja ću jednostavno nazvati ovu adresu <URL репозитория>.

Ugaone zagrade kao <тут> znači da morate zamijeniti takav izraz odgovarajućom vrijednošću.

Budi siguran da GitHub akcije uključeno za ovaj repozitorij kursa. Ako nisu omogućeni, omogućite ih tako što ćete kliknuti na veliko dugme na sredini stranice, na koje možete doći klikom na Akcije u GitHub interfejsu.

Nećete moći završiti kurs slijedeći moje upute ako GitHub Akcije nisu omogućene.

Uvijek možete koristiti GitHubovu sposobnost za renderiranje Markdowna da vidite trenutno stanje liste koju sastavljamo ovdje

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

O odgovorima

Iako je najbolji način da završite ovaj kurs da to uradite sami, možda ćete imati poteškoća.

Ako smatrate da ne razumijete šta da radite i da ne možete nastaviti, možete pogledati temu solution, koji se nalazi u vašem startnom spremištu.
Molimo nemojte spajati solution в master tokom kursa. Možete koristiti ovu granu da shvatite šta da radite ili da uporedite svoj kod sa autorskim, koristeći sve mogućnosti koje nam Git pruža. Ako ste potpuno izgubljeni, možete potpuno zamijeniti svoju granu master na grani solution a zatim resetirajte svoj radni direktorij na korak kursa koji vam je potreban.

Koristite ovo samo ako vam je zaista potrebno

Uključite svoj kod

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

Ove komande

• preimenovati master в master-backup;
• preimenovati solution в master;
• odjava u novu poslovnicu master i prepisati sadržaj radnog direktorija;
• Kreirajte granu "solution" od "master" (što je nekada bilo "solution") u slučaju da vam zatreba grana "solution" u budućnosti.

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

Nakon ovih koraka možete koristiti git log master da shvatite koje urezivanje vam je potrebno.
Možete resetirati svoj radni direktorij na ovo urezivanje na sljedeći način:

git reset --hard <the SHA you need>

Ako ste zadovoljni rezultatom, u nekom trenutku ćete morati objaviti svoju verziju spremišta u udaljenom spremištu. Nemojte zaboraviti eksplicitno navesti udaljenu granu kada to radite.

git push --force origin master

Imajte na umu da koristimo git push --force. Malo je vjerovatno da ćete htjeti da to radite vrlo često, ali ovdje imamo vrlo specifičan scenario sa jednim korisnikom spremišta koji, pored toga, razumije šta radi.

Početak rada

Počnimo sa sastavljanjem naše liste CI koraka. Obično biste započeli ovaj korak tako što ćete provjeriti najnoviju verziju koda iz udaljenog spremišta, ali još uvijek nemamo lokalno spremište, pa ga umjesto toga kloniramo iz udaljenog.

️ Zadatak: ažuriranje lokalnog spremišta, kreiranje grane iz master, počnite raditi

1. Klonirajte spremište kursa iz <URL репозитория>.
2. Bježi npm install u direktorijumu repozitorija kursa; Potreban nam je za instalaciju Jesta, koji koristimo za pokretanje testova.
3. Kreirajte granu i dajte joj naziv feature. Prebacite se na ovu temu.

4. Dodajte probni kod u ci.test.js između komentara u kojima se od mene traži da to uradim.

   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. Dodajte tekst sa prva 4 koraka u datoteku 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.  

   Komande

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

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

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

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

Kreirajte urezivanje na novoj grani, izgradite i testirajte lokalno

Postavićemo testove za pokretanje prije urezivanja, a zatim urezati kod.

Tipični scenariji kada se testovi pokreću automatski

• lokalno:
  • Kontinuirano ili kao odgovor na odgovarajuće promjene koda;
  • O čuvanju (za interpretirane jezike ili jezike kompajlirane JIT-om);
  • Tokom asemblera (kada je potrebna kompilacija);
  • On commit;
  • Prilikom objavljivanja u zajedničkom spremištu.

• Na serveru za izgradnju ili okruženju za izgradnju:
  • Kada se kod objavi u ličnoj grani/spremište.
  • Kod u ovoj temi se testira.
  • Potencijalni rezultat spajanja se testira (obično sa master).
  • Kao faza kontinuirane integracije/kontinuirana isporuka

Tipično, što brže radi testni paket, češće si možete priuštiti njegovo pokretanje. Tipična scenska distribucija bi mogla izgledati ovako.

• Brzi testovi jedinica - tokom izgradnje, u CI cevovodu
• Spori jedinični testovi, brzi testovi komponenti i integracije - pri urezivanju, u CI pipelineu
• Spori testovi komponenti i integracije - u CI pipelineu
• Sigurnosno testiranje, testiranje opterećenja i drugi dugotrajni ili skupi testovi - u CI/CD cjevovodima, ali samo u određenim načinima/fazama/cjevovodima gradnje, na primjer, kada se priprema kandidat za izdanje ili kada se pokreće ručno.

️Zadatak

Predlažem da prvo pokrenete testove ručno koristeći naredbu npm test. Nakon toga, dodajmo git kuku za pokretanje naših testova prilikom urezivanja. Postoji jedna kvaka: Git kuke se ne smatraju dijelom spremišta i stoga se ne mogu klonirati sa GitHuba zajedno s ostatkom materijala za kurs. Da biste instalirali kuku, morate pokrenuti install_hook.sh ili kopirajte datoteku repo/hooks/pre-commit u lokalni imenik .git/hooks/.
Kada urezujete, vidjet ćete da se pokreću testovi i oni provjeravaju da li su određene ključne riječi prisutne na listi.

1. Pokrenite testove ručno pokretanjem naredbe npm test u folderu vašeg spremišta kursa. Provjerite jesu li testovi završeni.
2. Postavite zakačicu za urezivanje (pre-urezivanje zakačicu) pokretanjem install_hook.sh.
3. Urežite svoje promjene u svoje lokalno spremište.
4. Uvjerite se da su testovi pokrenuti prije urezivanja.

Vaše spremište bi trebalo izgledati ovako nakon što slijedite ove korake.

Komande

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

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

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

Objavite kod u udaljeno spremište ili udaljenu granu

Kada završe s radom na lokalnom nivou, programeri obično čine svoj kod javno dostupnim kako bi se na kraju mogao integrirati u javnost. Sa GitHub-om, to se obično postiže objavljivanjem rada ili u ličnoj kopiji spremišta (personal fork) ili u ličnoj grani.

• Pomoću forks-a, programer klonira udaljeno zajedničko spremište, stvarajući njegovu ličnu udaljenu kopiju, također poznatu kao fork. Zatim klonira ovo osobno spremište za rad s njim lokalno. Kada je posao završen i urezivanja su napravljena, on ih gura u svoju viljušku, gdje su dostupni drugima i mogu se integrirati u zajedničko spremište. Ovaj pristup se obično koristi u projektima otvorenog koda na GitHubu. Takođe se koristi u mom naprednom kursu [Timski rad i CI sa Gitom] (http://devops.redpill.solutions/).
• Drugi pristup je korištenje samo jednog udaljenog spremišta i brojanje samo grana master dijeljeno spremište "zaštićeno". U ovom scenariju, pojedinačni programeri objavljuju svoj kod u granama udaljenog spremišta kako bi drugi mogli pogledati ovaj kod, ako je sve u redu, spojite ga sa master zajedničko spremište.

U ovom konkretnom kursu koristićemo radni tok koji koristi grane.

Hajde da objavimo naš kod.

️Zadatak

• Objavite promjene na udaljenoj grani s istim imenom kao i vaša radna grana

Komande

git push --set-upstream origin feature

Kreirajte zahtjev za povlačenjem

Kreirajte zahtjev za povlačenjem s naslovom Pregled koraka... Instaliraj feature kao "glavna grana" i master kao "osnovna grana".

Provjerite jeste li instalirali master u njegovom fork the repozitorijum Kao "osnovna grana", neću odgovarati na zahtjeve za izmjene u spremištu materijala za kurs.

U GitHub lingu, "osnovna grana" je grana na kojoj zasnivate svoj rad, a "glavna grana" je grana koja sadrži predložene izmene.

Razgovarajte o promjenama, dodajte nova urezivanja kako se diskusija nastavi

Povlačenje zahtjeva (PR)

Povlačenje zahtjeva (PR) je način da se diskutuje i dokumentuje kod, kao i da se izvrši pregled koda. Zahtjevi za povlačenje su nazvani prema opštem načinu integracije pojedinačnih promjena u cjelokupni kod. Tipično, osoba klonira udaljeno službeno spremište projekta i radi na kodu lokalno. Nakon toga, on stavlja kod u svoje lično udaljeno spremište i traži od odgovornih za službeno spremište da ga preuzmu (povući) njegov kod u njihova lokalna spremišta, gdje pregledavaju i eventualno integriraju(spojiti) njegov. Ovaj koncept je poznat i pod drugim nazivima, npr. zahtjev za spajanje.

Zapravo ne morate koristiti funkciju zahtjeva za povlačenjem na GitHub-u ili sličnim platformama. Razvojni timovi mogu koristiti druge metode komunikacije, uključujući komunikaciju licem u lice, glasovne pozive ili e-poštu, ali još uvijek postoji niz razloga za korištenje zahtjeva za povlačenjem u stilu foruma. Evo nekih od njih:

• organizirane diskusije vezane za specifične promjene koda;
• kao mjesto za pregled povratnih informacija o radu u toku od strane autotestera i kolega;
• formalizacija pregleda koda;
• tako da kasnije možete saznati razloge i razmatranja iza ovog ili onog dijela koda.

Obično kreirate zahtjev za povlačenje kada trebate razgovarati o nečemu ili dobiti povratnu informaciju. Na primjer, ako radite na funkciji koja bi se mogla implementirati na više načina, možete kreirati zahtjev za povlačenje prije nego što napišete prvi red koda kako biste podijelili svoje ideje i razgovarali o svojim planovima sa svojim suradnicima. Ako je posao jednostavniji, otvara se zahtjev za povlačenjem kada je nešto već urađeno, predano i može se razgovarati. U nekim scenarijima, možda ćete želeti da otvorite PR samo iz razloga kontrole kvaliteta: da pokrenete automatizovane testove ili pokrenete pregled koda. Šta god da odlučite, ne zaboravite da @pomenete ljude čije odobrenje želite u svom zahtjevu za povlačenje.

Obično, kada kreirate PR, radite sljedeće.

• Navedite šta predlažete da promijenite i gdje.
• Napišite opis koji objašnjava svrhu promjena. Možda želite:
  • dodajte bilo šta važno što nije očigledno iz koda, ili nešto korisno za razumijevanje konteksta, kao što su relevantne #bugove i brojevi urezivanja;
  • @pomeni svakoga sa kim želiš da počneš da radiš, ili ga možeš @pomenuti u komentarima kasnije;
  • zamolite kolege da vam pomognu oko nečega ili provjerite nešto konkretno.

Jednom kada otvorite PR, izvršavaju se testovi konfigurirani za pokretanje u takvim slučajevima. U našem slučaju, to će biti isti skup testova koji smo pokrenuli lokalno, ali u stvarnom projektu može biti dodatnih testova i provjera.

Molimo pričekajte dok se testovi završe. Status testova možete vidjeti na dnu PR diskusije u GitHub interfejsu. Nastavite kada se testovi završe.

️ Dodajte napomenu o nasumičnosti liste CI koraka

Lista koja se koristi u ovom kursu je proizvoljna i subjektivna, o tome treba dodati napomenu.

️ Zadatak: kreirati pull request za ovaj komentar

1. Prebacite se na granu master.
2. Kreirajte granu pod nazivom bugfix.
3. Dodajte tekst napomene na kraj datoteke 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. Utvrdite promjene.
5. Objavite temu bugfix u udaljeno spremište.
6. Kreirajte zahtjev za povlačenje pod nazivom Dodavanje napomene sa granom glave bugfix i baznu granumaster.

Provjerite jeste li instalirali master u njegovom fork the repozitorijum Kao "osnovna grana", neću odgovarati na zahtjeve za izmjene u spremištu materijala za kurs.

Ovako bi trebalo da izgleda vaše spremište.

Komande

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

Odobravanje zahtjeva za povlačenje "Dodavanje napomene"

️Zadatak

1. Kreirajte zahtjev za povlačenjem.
2. Kliknite na "Merge pull request".
3. Kliknite na "Potvrdi spajanje".
4. Kliknite na "Izbriši granu", više nam nije potrebna.

Ovo je dijagram urezivanja nakon spajanja.

️ Nastavite sa radom i dodajte testove

Saradnja na zahtjevu za povlačenjem često rezultira dodatnim radom. Ovo je obično rezultat pregleda koda ili rasprave, ali u našem kursu ćemo to modelirati dodavanjem novih stavki na našu listu CI koraka.

Kontinuirana integracija obično uključuje pokrivenost testom. Zahtjevi za pokrivenost testom variraju i obično se nalaze u dokumentu koji se zove nešto poput "smjernica za doprinos". Održat ćemo to jednostavnim i dodati test za svaki red na našoj kontrolnoj listi.

Kada izvršavate zadatke, pokušajte prvo izvršiti testove. Ako ste pravilno instalirali pre-commit zakačite ranije, novi dodani test će se pokrenuti, neće uspjeti i ništa neće biti urezano. Imajte na umu da na ovaj način znamo da naši testovi zapravo nešto testiraju. Zanimljivo je da ako počnemo s kodom prije testova, prolazak testova može značiti ili da je kod radio kako se očekivalo, ili da testovi zapravo ništa ne testiraju. Osim toga, da nismo uopće napisali testove, možda bismo ih potpuno zaboravili, jer nas ništa ne bi podsjetilo na to.

Test vođen razvoj (TDD)

TDD preporučuje pisanje testova prije koda. Tipičan tok rada koji koristi TDD izgleda ovako.

1. Dodajte test.
2. Pokrenite sve testove i uvjerite se da novi test ne uspije.
3. Napišite kod.
4. Pokrenite testove, provjerite jesu li svi testovi prošli.
5. Refaktorirajte svoj kod.
6. Ponovi.

Budući da su rezultati testova koji nisu uspjeli obično prikazani crvenom bojom, a oni koji su prošli obično su prikazani zelenom bojom, ciklus je također poznat kao crveno-zeleni-refaktor.

️Zadatak

Prvo, pokušajte da izvršite testove i pustite ih da ne uspeju, a zatim dodajte i urezujte tekst same liste koraka CI. Vidjet ćete da testovi prolaze ("zeleno").
Zatim objavite novi kod u udaljenom spremištu i gledajte kako se izvode testovi u GitHub interfejsu na dnu rasprave o zahtjevu za povlačenjem i ažuriranju PR statusa.

1. Prebacite se na granu feature.

2. Dodajte ove testove u ci.test.js posle poslednjeg poziva 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. Pokušajte izvršiti testove. Ako pre-commit hook je instaliran, pokušaj urezivanja neće uspjeti.
4. Zatim dodajte ovaj tekst u 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. Napravite i unesite promjene lokalno.
6. Objavite promjene u grani feature.

Trebalo bi da imate ovako nešto

Komande

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

Idite na Zahtjev za promjenu Pregled koraka.

Iako nismo učinili ništa loše i testovi za naš kod su prošli, još uvijek ne možemo spojiti granu feature и master. To je zbog druge teme bugfix je spojena sa master dok smo radili na ovom PR-u.
Ovo stvara situaciju u kojoj je udaljena grana master ima noviju verziju od one na kojoj smo bazirali granu feature. Zbog toga ne možemo samo premotati HEAD master do kraja niti feature. U ovoj situaciji, moramo ili spojiti ili primijeniti urezivanja feature rebase master. GitHub zapravo može izvršiti automatsko spajanje ako nema sukoba. Nažalost, u našoj situaciji, obje grane imaju konkurentne promjene u datoteci ci.md. Ova situacija je poznata kao sukob spajanja i moramo je ručno riješiti.

Spojite ili ponovo bazirajte

Spoji se

• Kreira dodatno urezivanje spajanja i čuva radnu historiju.
  • Čuva originalna urezivanja grana sa njihovim originalnim vremenskim oznakama i autorima.
  • Čuva SHA urezivanja i veze na njih u raspravama o zahtjevima za promjenu.
• Zahtijeva jednokratno rješavanje sukoba.
• Čini priču nelinearnom.
  • Priča može biti teška za čitanje zbog velikog broja grana (podsjeća na IDE kabel).
  • Otežava automatsko otklanjanje grešaka, npr. git bisect manje korisno - naći će samo urezivanje spajanja.

Rebase

• Ponavlja urezivanja iz trenutne grane na vrhu osnovne grane jedan za drugim.
  • Generišu se nova urezivanja sa novim SHA-ovima, što dovodi do toga da se urezivanja u GitHubu podudaraju sa originalnim zahtevima za povlačenje, ali ne i sa odgovarajućim komentarima.
  • Urezivanja se mogu rekombinovati i modifikovati u procesu, ili čak spojiti u jedno.
• Možda će biti potrebno riješiti više sukoba.
• Omogućava vam da održite linearnu priču.
  • Priču je možda lakše čitati sve dok nije predugačka bez razumnog razloga.
  • Automatsko otklanjanje grešaka i rješavanje problema je malo lakše: čini to mogućim git bisect, može učiniti automatsko vraćanje jasnijim i predvidljivijim.
• Zahtijeva objavljivanje grane sa migriranim urezima sa zastavicom --force kada se koristi sa zahtjevima za povlačenjem.

Tipično, timovi se slažu da uvijek koriste istu strategiju kada trebaju spojiti promjene. Ovo može biti "čisto" stapanje ili "čisto" urezivanje na vrhu, ili nešto između, kao što je interaktivno obavljanje urezivanja na vrhu (git rebase -i) lokalno za grane koje nisu objavljene u javnom spremištu, ali se spajaju za "javne" grane.

Ovdje ćemo koristiti spajanje.

️Zadatak

1. Provjerite je li kod u lokalnoj grani master ažurirano iz udaljenog spremišta.
2. Prebacite se na granu feature.
3. Pokrenite stapanje sa granom master. Konflikt spajanja zbog konkurentskih promjena u ci.md.
4. Riješite konflikt tako da i naša lista CI koraka i napomena o tome ostanu u tekstu.
5. Objavite urezivanje spajanjem na udaljenu granu feature.
6. Provjerite status zahtjeva za povlačenjem u GitHub korisničkom sučelju i pričekajte dok se spajanje ne riješi.

Komande

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

Odlično!

Završili ste sa listom i sada morate odobriti zahtjev za povlačenje master.

️ Zadatak: Odobravanje zahtjeva za povlačenje "Pregled koraka"

1. Otvorite zahtjev za povlačenjem.
2. Kliknite na "Merge pull request".
3. Kliknite na "Potvrdi spajanje".
4. Kliknite na "Izbriši granu" jer nam više nije potrebna.

Ovo je trenutno vaše spremište

Greška proizvoda

Kaže se da se „testiranje može koristiti da se pokaže prisustvo grešaka, ali nikada da se pokaže njihovo odsustvo“. Iako smo imali testove i nisu nam pokazali greške, podmukla greška se uvukla u proizvodnju.

U ovakvom scenariju moramo voditi računa o:

• šta se koristi u proizvodnji;
• kod u niti master s greškom, od koje programeri mogu započeti novi posao.

Da li da se vratim ili da to popravim u sledećoj verziji?

Vraćanje unazad je proces postavljanja poznate dobre ranije verzije u produkciju i vraćanja urezivanja koji sadrže grešku. "Fiksiranje naprijed" je dodatak popravke master i implementaciju nove verzije što je prije moguće. Budući da se API-ji i šeme baze podataka mijenjaju kako se kod postavlja u proizvodnju, uz kontinuiranu isporuku i dobru pokrivenost testom, vraćanje je obično mnogo teže i rizičnije od popravljanja u sljedećoj verziji.

Pošto vraćanje unazad ne nosi nikakav rizik u našem slučaju, mi ćemo ići ovim putem, jer nam to dozvoljava

• otkloniti grešku na proizvodu što je prije moguće;
• napravi kod master odmah pogodan za početak novog posla.

️Zadatak

1. Prebacite se na granu master lokalno.
2. Ažurirajte lokalno spremište iz udaljenog spremišta.
3. Vratite urezivanje PR spajanja Pregled koraka в master.
4. Objavite promjene u udaljenom spremištu.

Ovo je istorija spremišta sa vraćenim urezivanjem spajanja

Komande

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

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

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

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

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

️ Samotestiranje

Budi siguran da ci.md više ne sadrži tekst "sneaky bug" nakon vraćanja urezivanja spajanja.

Popravite listu CI koraka i vratite je na master

Potpuno smo vratili urezivanje stapanja grane. feature. Dobra vijest je da sada nemamo greške master. Loša vijest je da je nestala i naša dragocjena lista kontinuiranih koraka integracije. Dakle, u idealnom slučaju, moramo primijeniti ispravku na urezivanje iz feature i vratite ih master zajedno sa popravkom.

Problemu možemo pristupiti na različite načine:

• vrati urezivanje koje poništava stapanje feature с master;
• premjestiti urezivanja iz prethodnog feature.

Različiti razvojni timovi koriste različite pristupe u ovom slučaju, ali mi ćemo premjestiti korisna urezivanja u zasebnu granu i kreirati poseban zahtjev za povlačenjem za ovu novu granu.

️Zadatak

1. Kreirajte nit pod nazivom feature-fix i prebacite se na njega.

2. Migrirajte sva urezivanja iz prethodne grane feature u novu temu. Riješite sukobe spajanja koji su se dogodili tokom migracije.

   

3. Dodajte regresijski test u ci.test.js:

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

4. Pokrenite testove lokalno kako biste bili sigurni da neće uspjeti.
5. Uklonite tekst "sa skrivenom greškom". ci.md.
6. Dodajte promjene testa i promjene liste koraka u indeks i urezujte ih.
7. Objavite granu u udaljeno spremište.

Trebalo bi da dobijete nešto slično ovome:

Komande

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

Kreirajte zahtjev za povlačenjem.

Kreirajte zahtjev za povlačenjem s naslovom Popravljanje funkcije... Instaliraj feature-fix kao "glavna grana" i master kao "osnovna grana".
Molimo pričekajte dok se testovi završe. Status testova možete vidjeti na dnu PR diskusije.

Provjerite jeste li instalirali master u njegovom fork the repozitorijum Kao "osnovna grana", neću odgovarati na zahtjeve za izmjene u spremištu materijala za kurs.

Odobravanje zahtjeva za povlačenje "Popravljanje funkcije"

Hvala na ispravci! Molimo vas da odobrite izmjene na master iz zahtjeva za povlačenje.

️Zadatak

1. Kliknite na "Merge pull request".
2. Kliknite na "Potvrdi spajanje".
3. Kliknite na "Izbriši granu" jer nam više nije potrebna.

Ovo je ono što biste trebali imati u ovom trenutku.

Čestitamo!

Završili ste sve korake koje ljudi obično poduzimaju tokom kontinuirane integracije.

Ako primijetite bilo kakve probleme sa kursom ili znate kako da ga poboljšate, molimo vas da napravite problem u spremišta sa materijalima za kurs. Ovaj kurs takođe ima interaktivna verzija koristeći GitHub Learning Lab kao platformu.

izvor: www.habr.com