Jeste li naučili Git naredbe, ali želite zamisliti kako kontinuirana integracija (CI) funkcionira u stvarnosti? Ili možda želite optimizirati svoje dnevne aktivnosti? Ovaj tečaj pružit će vam praktične vještine kontinuirane integracije pomoću GitHub repozitorija. Ovaj tečaj nije namijenjen 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 uključene korake.

Što nam je činiti?

Kako napredujemo, postupno ćemo stvarati popis tipičnih CI koraka, što je sjajan način da zapamtite ovaj popis. Drugim riječima, napravit ćemo popis radnji koje programeri poduzimaju tijekom kontinuirane integracije, radeći kontinuiranu integraciju. Također ćemo koristiti jednostavan skup testova kako bismo naš CI proces približili stvarnom.

Ovaj GIF shematski prikazuje obveze u vašem repozitoriju kako napredujete kroz tečaj. Kao što vidite, ovdje nema ništa komplicirano i samo najpotrebnije.

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

• Rad na značajci;
• Primjena automatiziranih testova za osiguranje kvalitete;
• Provedba prioritetnog zadatka;
• Rješavanje sukoba pri spajanju grana (konflikt spajanja);
• Dolazi do pogreške u proizvodnom okruženju.

Što ćeš naučiti?

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

• Što je kontinuirana integracija (CI)?
• Koje se vrste automatiziranih testova koriste u CI-ju i kao odgovor na koje radnje se pokreću?
• Što su zahtjevi za povlačenjem i kada su potrebni?
• Što je Test Driven Development (TDD) i kako se odnosi na CI?
• Trebam li spojiti ili promijeniti bazu promjena?
• Vratiti ili popraviti u sljedećoj verziji?

Isprva sam posvuda prevodio stvari poput "zahtjeva za povlačenjem", ali kao rezultat toga odlučio sam na nekim mjestima vratiti fraze na engleskom kako bih smanjio stupanj ludila u tekstu. Ponekad ću koristiti "programerski suržik" poput divnog glagola "počiniti" tamo gdje ga ljudi zapravo koriste na poslu.

Što je kontinuirana integracija?

Kontinuirana integracija, ili CI, tehnička je praksa u kojoj svaki član tima integrira svoj kod u zajednički repozitorij barem jednom dnevno, a rezultirajući kod mora biti barem izgrađen bez pogrešaka.

Oko ovog termina postoje neslaganja

Točka prijepora je učestalost integracije. Neki tvrde da spajanje koda samo jednom dnevno nije dovoljno za kontinuiranu integraciju. Naveden je primjer tima u kojem svi uzimaju svježi kod ujutro i integriraju ga jednom navečer. Iako je ovo razuman prigovor, općenito se vjeruje da je definicija jednom dnevno razumno praktična, specifična i prikladna 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 sklapanja bez grešaka kao načina provjere valjanosti je slabo. Neki skup testova (na primjer, jedinični testovi koji se izvode lokalno) također moraju biti uspješno završeni. Trenutačno se zajednica kreće prema tome da ovo postane uvjet, au budućnosti će "build + unit tests" vjerojatno postati uobičajena praksa, ako već nije.

Kontinuirana integracija različito od kontinuirana isporuka (Continuous Delivery, CD) utoliko što ne zahtijeva kandidata za izdanje nakon svakog ciklusa integracije.

Popis koraka koje ćemo koristiti tijekom tečaja

1. Unesite najnoviji kod. Stvorite granu iz master. Početi raditi.
2. Stvorite obveze na svojoj novoj grani. Izgradite i testirajte lokalno. Proći? Idite na sljedeći korak. Iznevjeriti? Ispravite pogreške ili testirajte i pokušajte ponovno.
3. Gurnite u svoje udaljeno spremište ili udaljenu podružnicu.
4. Kreirajte zahtjev za povlačenjem. Raspravljajte o promjenama, dodajte još obvezivanja dok se rasprava nastavlja. Neka testovi prođu na grani značajki.
5. Spajanje/ponovno baziranje obveza iz glavnog. Neka testovi prođu rezultat spajanja.
6. Implementirajte od značajke do proizvodnje.
7. Ako je sve u redu u proizvodnji neko vrijeme, spojite promjene u master.

️ Priprema

Provjerite imate li pravi softver

Za pohađanje ovog tečaja trebat će vam Node.js и Git klijent.

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

Provjerite imate li instaliran Git klijent koji podržava naredbeni redak

Ako još nemate Git klijent koji podržava naredbeni redak, možete pronaći upute za instalaciju здесь.

Pripremite spremište

Morat ćete izraditi osobnu kopiju (fork) spremište predložaka s kodom za tečaj na GitHubu. Dogovorimo se da ovo nazovemo osobnom kopijom repozitorij tečajeva.

Gotovo? Ako niste promijenili zadane postavke, najvjerojatnije je pozvano vaše spremište tečaja continuous-integration-team-scenarios-students, nalazi se na vašem GitHub računu i URL izgleda ovako

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

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

Uglaste zagrade poput <тут> značit će da takav izraz morate zamijeniti odgovarajućom vrijednošću.

Uvjerite se da GitHub akcije uključeno u ovaj repozitorij tečaja. Ako nisu omogućeni, omogućite ih klikom na veliki gumb na sredini stranice, do kojeg možete doći klikom na Radnje u GitHub sučelju.

Nećete moći dovršiti tečaj slijedeći moje upute ako GitHub radnje nisu omogućene.

Uvijek možete koristiti GitHubovu mogućnost renderiranja Markdowna kako biste vidjeli trenutačno stanje popisa koji ovdje sastavljamo

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 tečaj da to učinite sami, možda ćete imati poteškoća.

Ako osjećate da ne razumijete što učiniti i ne možete nastaviti, možete pogledati temu solution, koji se nalazi u vašem početnom spremištu.
Molimo nemojte spajati solution в master tijekom tečaja. Možete koristiti ovu granu da shvatite što učiniti ili da usporedite svoj kod s autorovim, koristeći sve mogućnosti koje nam daje Git. Ako ste potpuno izgubljeni, možete potpuno zamijeniti svoju granu master na grani solution a zatim resetirajte svoj radni imenik na korak tečaja koji vam je potreban.

Koristite ovo samo ako vam je stvarno potrebno

Utvrdite svoj kod

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

Ove naredbe

• preimenovati master в master-backup;
• preimenovati solution в master;
• naplata u novu poslovnicu master i prepisati sadržaj radnog imenika;
• Stvorite granu "rješenje" iz "master" (koja je prije bila "rješenje") u slučaju da vam u budućnosti zatreba grana "rješenje".

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 koji commit trebate.
Možete resetirati svoj radni direktorij na ovu predaju ovako:

git reset --hard <the SHA you need>

Ako ste zadovoljni rezultatom, u nekom trenutku morat ćete objaviti svoju verziju repozitorija u udaljenom repozitoriju. Ne zaboravite eksplicitno navesti udaljenu granu kada to radite.

git push --force origin master

Imajte na umu da koristimo git push --force. Malo je vjerojatno da ćete to htjeti raditi vrlo često, ali ovdje imamo vrlo specifičan scenarij s jednim korisnikom repozitorija koji, osim toga, razumije što radi.

Početak rada

Počnimo sastavljati naš popis CI koraka. Obično biste ovaj korak započeli provjerom najnovije verzije koda iz udaljenog repozitorija, ali mi još nemamo lokalni repozitorij, pa ga umjesto toga kloniramo iz udaljenog repozitorija.

️ Zadatak: ažurirajte lokalno spremište, napravite granu iz master, početi raditi

1. Klonirajte repozitorij tečaja iz <URL репозитория>.
2. Trčanje npm install u imeniku repozitorija tečajeva; Treba nam da instaliramo Jest, koji koristimo za pokretanje testova.
3. Napravite granu i dajte joj ime feature. Prijeđi na ovu temu.

4. Dodajte testni kod u ci.test.js između komentara koji me traže da to učinim.

   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 s 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.  

   naredbe

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

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

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

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

Stvorite obveze na novoj grani, izgradite i testirajte lokalno

Postavit ćemo testove za pokretanje prije predaje, a zatim izvršiti kod.

Tipični scenariji kada se testovi pokreću automatski

• Lokalno:
  • Kontinuirano ili kao odgovor na odgovarajuće promjene koda;
  • O spremanju (za interpretirane ili JIT-kompilirane jezike);
  • Tijekom sklapanja (kada je potrebna kompilacija);
  • On commit;
  • Prilikom objavljivanja u zajedničkom repozitoriju.

• Na poslužitelju za izgradnju ili okruženju za izgradnju:
  • Kada se kod objavi u osobnoj grani/repozitoriju.
  • Kod u ovoj temi se testira.
  • Potencijalni rezultat spajanja se testira (obično s master).
  • Kao stadij kontinuirane integracije/cjevovod kontinuirane isporuke

Obično, što se testni paket brže izvodi, to češće možete priuštiti njegovo pokretanje. Tipična raspodjela pozornica mogla bi izgledati ovako.

• Brzi jedinični testovi - tijekom izgradnje, u CI cjevovodu
• Spori jedinični testovi, brzi komponentni i integracijski testovi - pri predaji, u CI cjevovodu
• Testovi spore komponente i integracije - u CI cjevovodu
• Sigurnosno testiranje, testiranje opterećenja i drugi dugotrajni ili skupi testovi - u CI/CD cjevovodima, ali samo u određenim načinima/fazama/cjevovodima izgradnje, na primjer, kada se priprema kandidat za izdanje ili kada se pokreće ručno.

️Zadatak

Predlažem da prvo ručno pokrenete testove pomoću naredbe npm test. Nakon toga, dodajmo git hook za izvođenje naših testova pri predaji. Postoji jedna začkoljica: Git hookovi se ne smatraju dijelom repozitorija i stoga se ne mogu klonirati s GitHuba zajedno s ostalim materijalima tečaja. Za instaliranje kuke morate trčati install_hook.sh ili kopirajte datoteku repo/hooks/pre-commit u lokalni imenik .git/hooks/.
Kada se obvezate, vidjet ćete da se izvode testovi koji provjeravaju jesu li određene ključne riječi prisutne na popisu.

1. Pokrenite testove ručno pokretanjem naredbe npm test u mapi repozitorija tečaja. Provjerite jesu li testovi dovršeni.
2. Postavite kuku za uvrštavanje (prethodnu kuku) pokretanjem install_hook.sh.
3. Obavijestite svoje promjene u svoje lokalno spremište.
4. Provjerite jesu li testovi pokrenuti prije predaje.

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

naredbe

# Установите 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 udaljenom repozitoriju ili udaljenoj grani

Nakon što završe s lokalnim radom, programeri svoj kod obično čine javno dostupnim kako bi se na kraju mogao integrirati u javnost. S GitHubom se to obično postiže objavljivanjem rada u osobnoj kopiji repozitorija (osobni fork) ili osobnoj grani.

• S račvama, programer klonira udaljeno dijeljeno spremište, stvarajući njegovu osobnu udaljenu kopiju, također poznatu kao fork. Zatim klonira ovo osobno spremište za lokalni rad. Kada je posao dovršen i izvršena su komitiranja, on ih gura u svoju vilicu, gdje su dostupni drugima i mogu se integrirati u zajednički repozitorij. Ovaj pristup se obično koristi u projektima otvorenog koda na GitHubu. Također se koristi u mom naprednom tečaju [Timski rad i CI s Gitom] (http://devops.redpill.solutions/).
• Drugi pristup je korištenje samo jednog udaljenog repozitorija i samo brojanje grana master zajedničko spremište "zaštićeno". U ovom scenariju, pojedinačni programeri objavljuju svoj kod u ograncima udaljenog repozitorija tako da drugi mogu pogledati ovaj kod, ako je sve u redu, spojiti ga s master zajedničko spremište.

U ovom konkretnom tečaju koristit ćemo tijek rada koji koristi grane.

Objavimo naš kod.

️Zadatak

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

naredbe

git push --set-upstream origin feature

Kreirajte zahtjev za povlačenjem

Stvorite zahtjev za povlačenje s naslovom Pregled koraka... Instalirati feature poput "glavne grane" i master poput "bazne grane".

Provjerite jeste li instalirali master u njegovom fork spremište Kao "osnovni ogranak", neću odgovarati na zahtjeve za izmjenama repozitorija materijala za tečaj.

U GitHub žargonu, "osnovna grana" je grana na kojoj temeljite svoj rad, a "glavna grana" je grana koja sadrži predložene promjene.

Raspravljajte o promjenama, dodajte nove obaveze dok se rasprava nastavlja

Zahtjev za povlačenje (PR)

Zahtjev za povlačenje (PR) je način za raspravu i dokumentiranje koda, kao i za provođenje pregleda koda. Zahtjevi za povlačenjem nazvani su prema općem načinu integriranja pojedinačnih promjena u cjelokupni kod. Tipično, osoba klonira udaljeni službeni repozitorij projekta i radi na kodu lokalno. Nakon toga, on stavlja kod u svoj osobni udaljeni repozitorij i traži od onih koji su odgovorni za službeni repozitorij da ga pokupe(povući) svoj kod u svoja lokalna spremišta, gdje pregledavaju i eventualno integriraju (spojiti) njegov. Ovaj koncept je poznat i pod drugim imenima, npr. zahtjev za spajanje.

Zapravo ne morate koristiti značajku zahtjeva za povlačenjem GitHuba ili sličnih platformi. 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. Ovo su neki od njih:

• organizirane rasprave vezane uz određene izmjene kodeksa;
• kao mjesto za pregled povratnih informacija o radu u tijeku od 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 značajci koja bi se mogla implementirati na više od jednog načina, možete stvoriti zahtjev za povlačenjem prije pisanja prve linije koda kako biste podijelili svoje ideje i raspravili svoje planove sa svojim suradnicima. Ako je posao jednostavniji, pull request se otvara kada je nešto već učinjeno, angažirano i može se raspravljati. U nekim scenarijima možda ćete htjeti otvoriti PR samo iz razloga kontrole kvalitete: radi pokretanja automatiziranih testova ili pokretanja pregleda koda. Što god odlučili, ne zaboravite @spomenuti osobe čije odobrenje želite u svom zahtjevu za povlačenjem.

Kada kreirate PR, obično radite sljedeće.

• Navedite što predlažete promijeniti i gdje.
• Napišite opis koji objašnjava svrhu promjena. Možda želite:
  • dodati bilo što važno što nije očito iz koda, ili nešto korisno za razumijevanje konteksta, kao što su relevantni #bugovi i brojevi predaja;
  • @spomenite bilo koga s kim želite započeti suradnju ili ih možete kasnije @spomenuti u komentarima;
  • zamolite kolege da vam pomognu oko nečega ili provjerite nešto konkretno.

Nakon što otvorite PR, izvršavaju se testovi konfigurirani za pokretanje u takvim slučajevima. U našem slučaju, to će biti isti skup testova koje smo izvodili lokalno, ali u stvarnom projektu mogu postojati dodatni testovi i provjere.

Pričekajte dok se testovi završe. Status testova možete vidjeti na dnu PR rasprave u GitHub sučelju. Nastavite kada se testovi završe.

️ Dodajte napomenu o nasumičnosti popisa CI koraka

Popis koji se koristi u ovom tečaju je proizvoljan i subjektivan, o čemu bismo trebali dodati napomenu.

️ Zadatak: izradite zahtjev za povlačenjem za ovaj komentar

1. Prijeđi na poslovnicu master.
2. Stvorite granu pod nazivom bugfix.
3. Dodajte tekst bilješke 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. Potvrdite promjene.
5. Objavi temu bugfix u udaljeno spremište.
6. Stvorite zahtjev za povlačenje pod nazivom Dodavanje primjedbe s glavičastom granom bugfix i bazne granemaster.

Provjerite jeste li instalirali master u njegovom fork spremište Kao "osnovni ogranak", neću odgovarati na zahtjeve za izmjenama repozitorija materijala za tečaj.

Ovako bi trebao izgledati vaš repozitorij.

naredbe

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

Odobri zahtjev za povlačenjem "Dodavanje primjedbe"

️Zadatak

1. Kreirajte zahtjev za povlačenjem.
2. Kliknite "Zahtjev za spajanje povlačenja".
3. Kliknite "Potvrdi spajanje".
4. Kliknite "Izbriši granu", više nam ne treba.

Ovo je dijagram predaja nakon spajanja.

️ Nastavite s radom i dodavanjem testova

Suradnja na zahtjevu za povlačenjem često rezultira dodatnim radom. To je obično rezultat pregleda koda ili rasprave, ali u našem tečaju to ćemo modelirati dodavanjem novih stavki na naš popis CI koraka.

Kontinuirana integracija obično uključuje određenu pokrivenost testom. Zahtjevi za pokrivenost testom razlikuju se i obično se nalaze u dokumentu koji se zove nešto poput "smjernica za doprinos". Bit ćemo jednostavniji i dodat ćemo test za svaki redak na našem popisu za provjeru.

Kada izvodite zadatke, pokušajte prvo predati testove. Ako ste ispravno instalirali pre-commit zakačiti ranije, novododani test će se pokrenuti, neće uspjeti i ništa se neće predati. Imajte na umu da ovo je način na koji znamo da naši testovi zapravo testiraju nešto. Zanimljivo, ako smo počeli s kodom prije testova, prolazak testova može značiti da je kod radio kako se očekivalo ili da testovi zapravo ništa ne testiraju. Osim toga, da nismo napisali testove, možda bismo na njih posve zaboravili, jer nas ništa ne bi podsjećalo na to.

Testom vođen razvoj (TDD)

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

1. Dodajte test.
2. Pokrenite sve testove i osigurajte da novi test ne uspije.
3. Napiši kod.
4. Pokrenite testove, pobrinite se da svi testovi prođu.
5. Prepravite svoj kod.
6. Ponoviti.

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 predati testove i pustiti da padnu, a zatim dodajte i potvrdite sam tekst popisa CI koraka. Vidjet ćete da testovi prolaze ("zeleno").
Zatim objavite novi kod u udaljenom repozitoriju i gledajte kako se testovi izvode u sučelju GitHub na dnu rasprave o zahtjevu za povlačenjem i ažuriranju PR statusa.

1. Prijeđi na poslovnicu feature.

2. Dodajte ove testove u ci.test.js nakon posljednjeg 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 položiti testove. Ako pre-commit kuka instalirana, pokušaj predaje 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 potvrdite promjene lokalno.
6. Objavi promjene u grani feature.

Sada biste trebali imati ovako nešto

naredbe

# Переключительна ветку 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 zato što druga nit bugfix bio je spojen s master dok smo radili na ovom PR-u.
To stvara situaciju u kojoj udaljena grana master ima noviju verziju od one na kojoj smo temeljili granu feature. Zbog toga ne možemo samo premotati HEAD master do kraja konca feature. U ovoj situaciji moramo ili spojiti ili primijeniti obveze feature ponovno bazirati master. GitHub zapravo može izvršiti automatsko spajanje ako nema sukoba. Jao, u našoj situaciji, obje grane imaju konkurentske promjene u datoteci ci.md. Ova situacija je poznata kao sukob spajanja i moramo je riješiti ručno.

Spajanje ili ponovno postavljanje

Spojiti

• Stvara dodatno obvezu spajanja i sprema radnu povijest.
  • Čuva izvorne predaje ogranaka s njihovim izvornim vremenskim oznakama i autorima.
  • Sprema SHA obveza i povezuje se s njima u raspravama zahtjeva za promjenama.
• Zahtijeva jednokratno rješavanje sukoba.
• Čini priču nelinearnom.
  • Priča može biti teška za čitanje zbog velikog broja ogranaka (podsjeća na IDE kabel).
  • Otežava automatsko otklanjanje pogrešaka, npr. git bisect manje korisno - pronaći će samo predaju spajanja.

Prebazirati

• Ponavlja predaje iz trenutne grane na vrh osnovne grane jednu za drugom.
  • Generiraju se nove obveze s novim SHA-ovima, zbog čega se obveze u GitHubu podudaraju s izvornim zahtjevima za povlačenje, ali ne i odgovarajućim komentarima.
  • Obaveze se mogu rekombinirati i modificirati u procesu ili čak spojiti u jednu.
• Možda će biti potrebno riješiti više sukoba.
• Omogućuje vam održavanje linearne priče.
  • Priča bi mogla biti lakša za čitanje sve dok nije preduga bez razumnog razloga.
  • Automatsko otklanjanje pogrešaka i rješavanje problema malo je lakše: čini ga mogućim git bisect, može automatsko vraćanje učiniti jasnijim i predvidljivijim.
• Zahtijeva objavljivanje grane s migriranim obvezama s oznakom --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 bi moglo biti "čisto" spajanje ili "čisto" predanje na vrhu, ili nešto između, kao što je interaktivno izvršavanje predaje na vrhu (git rebase -i) lokalno za grane koje nisu objavljene u javnom repozitoriju, ali se spajaju za "javne" grane.

Ovdje ćemo koristiti spajanje.

️Zadatak

1. Provjerite nalazi li se kôd u lokalnoj podružnici master ažuriran iz udaljenog repozitorija.
2. Prijeđi na poslovnicu feature.
3. Pokreni spajanje s granom master. Sukob spajanja zbog konkurentskih promjena na ci.md.
4. Riješite sukob tako da i naš popis CI koraka i bilješka o tome ostanu u tekstu.
5. Objavite predaju spajanja u udaljenu granu feature.
6. Provjerite status zahtjeva za povlačenjem u korisničkom sučelju GitHub i pričekajte dok se spajanje ne riješi.

naredbe

# Убедитесь, что код в локальное ветке `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čan posao!

Završili ste s popisom i sada morate odobriti zahtjev za povlačenje master.

️ Zadatak: odobriti zahtjev za povlačenje "Pregled koraka"

1. Otvorite zahtjev za povlačenjem.
2. Kliknite "Zahtjev za spajanje povlačenja".
3. Kliknite "Potvrdi spajanje".
4. Kliknite "Izbriši granu" jer nam više ne treba.

Ovo je trenutno vaše spremište

Greška proizvoda

Rečeno je da se "testiranje može koristiti da pokaže prisutnost grešaka, ali nikada da pokaže njihovu odsutnost." Iako smo imali testove i nisu nam pokazali nikakve pogreške, u proizvodnju se uvukao podmukli bug.

U ovakvom scenariju moramo voditi računa o:

• što se koristi u proizvodnji;
• kod u temi master s pogreškom, od koje programeri mogu započeti novi posao.

Trebam li to vratiti ili popraviti u sljedećoj verziji?

Vraćanje na staro stanje je proces postavljanja poznate dobre ranije verzije u proizvodnju i vraćanja obveza koje sadrže pogrešku. "Popravljanje naprijed" je dodavanje popravka na master i implementaciju nove verzije što je prije moguće. Budući da se API-ji i sheme baze podataka mijenjaju kako se kod postavlja u produkciju, uz kontinuiranu isporuku i dobru pokrivenost testom, vraćanje na staro stanje obično je mnogo teže i riskantnije od popravljanja u sljedećoj verziji.

Budući da vraćanje unatrag ne nosi nikakav rizik u našem slučaju, ići ćemo ovim putem jer nam to dopušta

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

️Zadatak

1. Prijeđi na poslovnicu master lokalno.
2. Ažurirajte lokalno spremište iz udaljenog spremišta.
3. Poništi predaju PR spajanja Pregled koraka в master.
4. Objavite promjene u udaljenom repozitoriju.

Ovo je povijest repozitorija s poništenim predanjem spajanja

naredbe

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

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

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

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

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

️ Samotestiranje

Uvjerite se u to ci.md više ne sadrži tekst "podmukli bug" nakon vraćanja predaje spajanja.

Popravite popis CI koraka i vratite ga masteru

Potpuno smo vratili predaju spajanja grane. feature. Dobra vijest je da sada nemamo pogreške u master. Loša vijest je da je nestao i naš dragocjeni popis koraka stalne integracije. Dakle, u idealnom slučaju, trebamo primijeniti popravak na predaje iz feature i vratiti ih u master zajedno s popravkom.

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

• vrati predanje koje poništava spajanje feature с master;
• premjestiti obvezuje iz bivšeg feature.

Različiti razvojni timovi koriste različite pristupe u ovom slučaju, ali mi ćemo premjestiti korisne obveze u zasebnu granu i stvoriti zaseban zahtjev za povlačenjem za ovu novu granu.

️Zadatak

1. Stvorite nit tzv feature-fix i prebaciti se na njega.

2. Premjestite sve obveze iz prethodne grane feature na novu nit. Riješite sukobe spajanja koji su se dogodili tijekom 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 pasti.
5. Uklonite tekst "s podmuklom greškom". ci.md.
6. Dodajte testne promjene i promjene popisa koraka u indeks i potvrdite ih.
7. Objavite granu u udaljenom repozitoriju.

Trebali biste završiti s nečim sličnim ovome:

naredbe

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

Stvorite zahtjev za povlačenje s naslovom Popravljanje značajke... Instalirati feature-fix poput "glavne grane" i master poput "bazne grane".
Molimo pričekajte dok se testovi završe. Status testova možete vidjeti na dnu PR rasprave.

Provjerite jeste li instalirali master u njegovom fork spremište Kao "osnovni ogranak", neću odgovarati na zahtjeve za izmjenama repozitorija materijala za tečaj.

Odobri zahtjev za povlačenjem "Popravljanje značajke"

Hvala na ispravku! Molimo odobrite promjene na master iz zahtjeva za povlačenjem.

️Zadatak

1. Kliknite "Zahtjev za spajanje povlačenja".
2. Kliknite "Potvrdi spajanje".
3. Kliknite "Izbriši granu" jer nam više ne treba.

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

Čestitamo!

Dovršili ste sve korake koje ljudi obično poduzimaju tijekom kontinuirane integracije.

Ako primijetite probleme s tečajem ili znate kako ga poboljšati, napravite problem u spremišta s materijalima za tečajeve. Ovaj tečaj također ima interaktivna verzija koristeći GitHub Learning Lab kao platformu.

Izvor: www.habr.com