Har du lært Git-kommandoer, men ønsker å forestille deg hvordan kontinuerlig integrasjon (CI) fungerer i virkeligheten? Eller kanskje du ønsker å optimalisere dine daglige aktiviteter? Dette kurset vil gi deg praktiske ferdigheter i kontinuerlig integrasjon ved hjelp av et GitHub-depot. Dette kurset er ikke ment å være en veiviser som du bare kan klikke deg gjennom; tvert imot vil du utføre de samme handlingene som folk faktisk gjør på jobben, på samme måte som de gjør det. Jeg vil forklare teorien mens du går gjennom trinnene som er involvert.

Hva skal vi gjøre?

Etter hvert som vi går videre, vil vi gradvis lage en liste over typiske CI-trinn, som er en fin måte å huske denne listen på. Med andre ord vil vi lage en liste over handlinger som utviklere tar mens de gjør kontinuerlig integrasjon, gjør kontinuerlig integrasjon. Vi vil også bruke et enkelt sett med tester for å bringe CI-prosessen vår nærmere den virkelige.

Denne GIF-en viser skjematisk forpliktelsene i depotet ditt mens du går gjennom kurset. Som du kan se, er det ikke noe komplisert her og bare det mest nødvendige.

Du vil gå gjennom følgende standard CI-scenarier:

• Arbeid med en funksjon;
• Anvendelse av automatiserte tester for å sikre kvalitet;
• Gjennomføring av den prioriterte oppgaven;
• Konfliktløsning ved sammenslåing av grener (sammenslåingskonflikt);
• Det oppstår en feil i et produksjonsmiljø.

Hva vil du lære?

Du vil kunne svare på følgende spørsmål:

• Hva er kontinuerlig integrasjon (CI)?
• Hvilke typer automatiserte tester brukes i CI, og som svar på hvilke handlinger utløses de?
• Hva er pull-forespørsler og når trengs de?
• Hva er Test Driven Development (TDD) og hvordan forholder det seg til CI?
• Bør jeg slå sammen eller basere endringene på nytt?
• Rulle tilbake eller fikse i neste versjon?

Til å begynne med oversatte jeg ting som "pull requests" overalt, men som et resultat bestemte jeg meg for å returnere fraser på engelsk noen steder for å redusere graden av galskap i teksten. Noen ganger vil jeg bruke "programmerer surzhik" som det fantastiske verbet "forplikte" der folk faktisk bruker det på jobb.

Hva er kontinuerlig integrasjon?

Kontinuerlig integrering, eller CI, er en teknisk praksis der hvert teammedlem integrerer koden sin i et felles depot minst én gang om dagen, og den resulterende koden må minst bygges uten feil.

Det er uenigheter om dette begrepet

Striden er frekvensen av integrering. Noen hevder at det å slå sammen kode bare én gang om dagen ikke er nok til å faktisk integreres kontinuerlig. Det gis et eksempel på et team hvor alle tar fersk kode om morgenen og integrerer den en gang om kvelden. Selv om dette er en rimelig innvending, antas det generelt at definisjonen én gang om dagen er rimelig praktisk, spesifikk og egnet for lag av forskjellige størrelser.

En annen innvending er at C++ ikke lenger er det eneste språket som brukes i utviklingen, og det er svakt å bare kreve feilfri montering som en måte å validere på. Noen sett med tester (for eksempel enhetstester utført lokalt) må også fullføres. For øyeblikket beveger samfunnet seg mot å gjøre dette til et krav, og i fremtiden vil "bygg + enhetstester" trolig bli vanlig praksis, hvis det ikke allerede har gjort det.

Kontinuerlig integrering skiller seg fra kontinuerlig levering (Kontinuerlig levering, CD) ved at den ikke krever en utgivelseskandidat etter hver integrasjonssyklus.

Liste over trinn vi skal bruke gjennom hele kurset

1. Trekk inn den siste koden. Lag en gren fra master. Begynn å jobbe.
2. Opprett forpliktelser på din nye filial. Bygg og test lokalt. Sende? Gå til neste trinn. Mislykkes? Rett opp feil eller tester og prøv igjen.
3. Skyv til det eksterne depotet eller den eksterne grenen.
4. Opprett en pull-forespørsel. Diskuter endringene, legg til flere forpliktelser etter hvert som diskusjonen fortsetter. Få tester bestått på funksjonsgrenen.
5. Merge/rebase commits fra master. Få tester til å bestå på sammenslåingsresultatet.
6. Distribuer fra funksjonsgrenen til produksjon.
7. Hvis alt er bra i produksjonen i en periode, slå sammen endringer til master.

️ Forberedelse

Sørg for at du har riktig programvare

For å ta dette kurset trenger du node.js и Git klient.

Du kan bruke hvilken som helst Git-klient, men jeg vil bare gi kommandoer for kommandolinjen.

Sørg for at du har en Git-klient installert som støtter kommandolinjen

Hvis du ennå ikke har en Git-klient som støtter kommandolinjen, kan du finne installasjonsinstruksjoner her.

Klargjør depotet

Du må lage en personlig kopi (gaffel) mallager med kode for kurset på GitHub. La oss bli enige om å kalle denne personlige kopien kursdepot.

Ferdig? Hvis du ikke har endret standardinnstillingene, kalles kursdepotet ditt mest sannsynlig continuous-integration-team-scenarios-students, den ligger i GitHub-kontoen din og URL-en ser slik ut

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

Jeg vil bare ringe denne adressen <URL репозитория>.

Vinkelbraketter som <тут> vil bety at du må erstatte et slikt uttrykk med passende verdi.

Sørge for at GitHub-handlinger inkludert for dette kursdepotet. Hvis de ikke er aktivert, vennligst aktiver dem ved å klikke på den store knappen midt på siden, som du kan komme til ved å klikke på Handlinger i GitHub-grensesnittet.

Du vil ikke kunne fullføre kurset ved å følge instruksjonene mine hvis GitHub Actions ikke er aktivert.

Du kan alltid bruke GitHubs evne til å gjengi Markdown for å se gjeldende status for listen vi lager her

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

Om svarene

Selv om den beste måten å fullføre dette kurset på er å gjøre det selv, kan du ha noen problemer.

Hvis du føler at du ikke forstår hva du skal gjøre og ikke kan fortsette, kan du se i tråden solution, som er i startlageret ditt.
Vennligst ikke slå sammen solution в master under kurset. Du kan bruke denne grenen til å finne ut hva du skal gjøre, eller for å sammenligne koden din med forfatterens, ved å bruke alle egenskapene som Git gir oss. Hvis du er helt borte, kan du erstatte grenen fullstendig master på en gren solution og tilbakestill deretter arbeidskatalogen til kurstrinnet du trenger.

Bruk denne bare hvis du virkelig trenger den

Forplikt koden din

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

Disse kommandoene

• endre navn master в master-backup;
• endre navn solution в master;
• kassen til en ny filial master og omskriv innholdet i arbeidskatalogen;
• Lag en "løsning"-gren fra "master" (som pleide å være "løsning") i tilfelle du trenger en "løsning"-gren i fremtiden.

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

Etter disse trinnene kan du bruke git log master for å finne ut hvilken forpliktelse du trenger.
Du kan tilbakestille arbeidskatalogen til denne forpliktelsen slik:

git reset --hard <the SHA you need>

Hvis du er fornøyd med resultatet, må du på et tidspunkt publisere din versjon av depotet til et eksternt depot. Ikke glem å spesifisere den eksterne grenen eksplisitt når du gjør dette.

git push --force origin master

Vær oppmerksom på at vi bruker git push --force. Det er usannsynlig at du vil gjøre dette veldig ofte, men vi har et veldig spesifikt scenario her med én depotbruker som i tillegg forstår hva han gjør.

Begynner å jobbe

La oss begynne å kompilere listen over CI-trinn. Vanligvis vil du starte dette trinnet ved å sjekke ut den nyeste versjonen av koden fra det eksterne depotet, men vi har ikke et lokalt depot ennå, så vi kloner det fra det eksterne depotet i stedet.

️ Oppgave: oppdater det lokale depotet, opprett en filial fra master, Begynn å jobbe

1. Klone kursdepotet fra <URL репозитория>.
2. Løpe npm install i kursdepotkatalogen; Vi trenger den for å installere Jest, som vi bruker til å kjøre tester.
3. Lag en gren og navngi den feature. Bytt til denne tråden.

4. Legg til testkode til ci.test.js mellom kommentarer som ber meg om å gjøre dette.

   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. Legg til tekst med de første 4 trinnene til filen 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.  

   kommandoer

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

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

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

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

Opprett forpliktelser på en ny filial, bygg og test lokalt

Vi skal sette opp testene som skal kjøres før vi forplikter dem, og deretter forplikte koden.

Typiske scenarier når tester kjøres automatisk

• Lokalt:
  • Kontinuerlig eller som svar på passende kodeendringer;
  • Ved lagring (for tolkede eller JIT-kompilerte språk);
  • Under montering (når kompilering er nødvendig);
  • På forpliktelse;
  • Når du publiserer til et delt depot.

• På byggeserveren eller byggemiljøet:
  • Når koden publiseres til en personlig filial/depot.
  • Koden i denne tråden blir testet.
  • Det potensielle resultatet av fusjonen testes (vanligvis med master).
  • Som en kontinuerlig integrasjonsfase/kontinuerlig leveringspipeline

Vanligvis, jo raskere en testpakke kjører, jo oftere har du råd til å kjøre den. En typisk scenefordeling kan se slik ut.

• Raske enhetstester - under bygging, i CI-rørledning
• Langsomme enhetstester, raske komponent- og integrasjonstester - ved commit, i CI-pipeline
• Langsomme komponent- og integrasjonstester - i CI-pipeline
• Sikkerhetstesting, lasttesting og andre tidkrevende eller kostbare tester - i CI/CD-rørledninger, men kun i visse moduser/stadier/rørledninger i bygget, for eksempel ved klargjøring av en utgivelseskandidat eller ved manuell kjøring.

️ Oppdrag

Jeg foreslår å kjøre testene manuelt først ved å bruke kommandoen npm test. Etter det, la oss legge til en git-hook for å kjøre testene våre på commit. Det er en hake: Git-hooks anses ikke som en del av depotet og kan derfor ikke klones fra GitHub sammen med resten av kursmateriellet. For å installere krok må du løpe install_hook.sh eller kopier filen repo/hooks/pre-commit til lokal katalog .git/hooks/.
Når du forplikter deg, vil du se at tester kjøres og de sjekker om visse søkeord er til stede i listen.

1. Kjør testene manuelt ved å kjøre kommandoen npm test i mappen for kursdepot. Bekreft at testene er fullført.
2. Sett en commit-hook (pre-commit-hook) ved å løpe install_hook.sh.
3. Overfør endringene til ditt lokale depot.
4. Sørg for at tester kjøres før du forplikter deg.

Depotet ditt skal se slik ut etter å ha fulgt disse trinnene.

kommandoer

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

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

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

Publiser kode til et eksternt depot eller ekstern filial

Når de er ferdige med å jobbe lokalt, gjør utviklere vanligvis koden sin offentlig tilgjengelig slik at den til slutt kan integreres med publikum. Med GitHub oppnås dette vanligvis ved å publisere verket til enten en personlig kopi av depotet (personlig gaffel) eller en personlig gren.

• Med gafler kloner en utvikler et eksternt delt depot, og lager en personlig ekstern kopi av det, også kjent som en gaffel. Den kloner deretter dette personlige depotet for å jobbe med lokalt. Når arbeidet er fullført og forpliktelsene er gjort, skyver han dem inn i gaffelen sin, hvor de er tilgjengelige for andre og kan integreres i det felles depotet. Denne tilnærmingen brukes ofte i åpen kildekode-prosjekter på GitHub. Det brukes også i mitt avanserte kurs [Teamarbeid og CI med Git] (http://devops.redpill.solutions/).
• En annen tilnærming er å bruke bare ett eksternt depot og bare telle grenen master delt depot "beskyttet". I dette scenariet publiserer individuelle utviklere koden sin til grener av et eksternt depot slik at andre kan se på denne koden, hvis alt er i orden, slå den sammen med master delt depot.

I dette spesielle kurset vil vi bruke en arbeidsflyt som bruker grener.

La oss publisere koden vår.

️ Oppdrag

• Publiser endringer til en ekstern gren med samme navn som din arbeidsgren

kommandoer

git push --set-upstream origin feature

Opprett en pull-forespørsel

Lag en pull-forespørsel med en tittel Trinn gjennomgang... Installere feature som "hodegren" og master som "basisgren".

Sørg for at du har installert master i hans gaffel depotet Som en «basegren» vil jeg ikke svare på forespørsler om endringer i kursmaterielldepotet.

I GitHub-språket er "basegrenen" grenen du baserer arbeidet ditt på, og "hovedgrenen" er grenen som inneholder de foreslåtte endringene.

Diskuter endringene, legg til nye forpliktelser etter hvert som diskusjonen fortsetter

Trekkforespørsel (PR)

Trekkforespørsel (PR) er en måte å diskutere og dokumentere kode på, samt gjennomføre kodegjennomgang. Pull-forespørsler er oppkalt etter den generelle måten å integrere individuelle endringer i den generelle koden. Vanligvis kloner en person prosjektets eksterne offisielle depot og jobber med koden lokalt. Etter dette plasserer han koden i sitt personlige fjernlager og ber de ansvarlige for det offisielle depotet hente(trekke) sin kode i deres lokale depoter, hvor de gjennomgår og muligens integrerer(fusjonere) hans. Dette konseptet er også kjent under andre navn, for eksempel forespørsel om sammenslåing.

Du trenger faktisk ikke bruke pull request-funksjonen til GitHub eller lignende plattformer. Utviklingsteam kan bruke andre kommunikasjonsmetoder, inkludert ansikt-til-ansikt kommunikasjon, taleanrop eller e-post, men det er fortsatt en rekke grunner til å bruke forespørsler i forumstil. Her er noen av dem:

• organiserte diskusjoner relatert til spesifikke kodeendringer;
• som et sted å se tilbakemeldinger om pågående arbeid fra både autotestere og jevnaldrende;
• formalisering av kodegjennomganger;
• slik at du senere kan finne ut årsakene og hensynene bak denne eller den koden.

Vanligvis oppretter du en pull-forespørsel når du trenger å diskutere noe eller få tilbakemelding. For eksempel, hvis du jobber med en funksjon som kan implementeres på mer enn én måte, kan du opprette en pull-forespørsel før du skriver den første linjen med kode for å dele ideene dine og diskutere planene dine med samarbeidspartnerne dine. Hvis arbeidet er enklere, åpnes en pull request når noe allerede er gjort, forpliktet og kan diskuteres. I noen scenarier kan det være lurt å åpne en PR bare av kvalitetskontrollårsaker: for å kjøre automatiserte tester eller starte kodegjennomganger. Uansett hva du bestemmer deg for, ikke glem å @nevne personene du vil ha godkjenning for i pull-forespørselen din.

Vanligvis, når du oppretter en PR, gjør du følgende.

• Angi hva du foreslår å endre og hvor.
• Skriv en beskrivelse som forklarer hensikten med endringene. Du vil kanskje:
  • legg til noe viktig som ikke er åpenbart fra koden, eller noe nyttig for å forstå konteksten, for eksempel relevante #bugs og commit-tall;
  • @nevn alle du vil begynne å jobbe med, eller du kan @nevne dem i kommentarfeltet senere;
  • be kolleger om å hjelpe med noe eller sjekke noe spesifikt.

Når du åpner PR, blir testene som er konfigurert til å kjøre i slike tilfeller, utført. I vårt tilfelle vil dette være det samme settet med tester som vi kjørte lokalt, men i et reelt prosjekt kan det være ytterligere tester og kontroller.

Vennligst vent mens testene er fullført. Du kan se status for testene nederst i PR-diskusjonen i GitHub-grensesnittet. Fortsett når testene er fullført.

️ Legg til en merknad om tilfeldigheten i listen over CI-trinn

Listen som brukes i dette kurset er vilkårlig og subjektiv, vi bør legge til en merknad om dette.

️ Oppgave: Lag en pull-forespørsel for denne kommentaren

1. Bytt til filial master.
2. Lag en gren som heter bugfix.
3. Legg til notattekst på slutten av filen 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. Forplikte endringene.
5. Publiser tråden bugfix til et eksternt depot.
6. Opprett en pull-forespørsel med navn Legger til en kommentar med en hodegren bugfix og basisgrenenmaster.

Sørg for at du har installert master i hans gaffel depotet Som en «basegren» vil jeg ikke svare på forespørsler om endringer i kursmaterielldepotet.

Slik skal depotet ditt se ut.

kommandoer

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

Godkjenn pull-forespørsel "Legger til en kommentar"

️ Oppdrag

1. Opprett en pull-forespørsel.
2. Klikk på "Merge pull request".
3. Klikk "Bekreft sammenslåing".
4. Klikk "Slett filial", vi trenger den ikke lenger.

Dette er et diagram over forpliktelser etter en sammenslåing.

️ Fortsett å jobbe og legg til tester

Å samarbeide om en pull-forespørsel resulterer ofte i merarbeid. Dette er vanligvis resultatet av en kodegjennomgang eller diskusjon, men i kurset vårt skal vi modellere dette ved å legge til nye elementer i listen vår over CI-trinn.

Kontinuerlig integrasjon innebærer vanligvis en viss testdekning. Kravene til testdekning varierer og finnes vanligvis i et dokument som kalles noe sånt som "bidragsretningslinjer". Vi holder det enkelt og legger til en test for hver linje i sjekklisten vår.

Når du kjører oppgaver, prøv å utføre testene først. Hvis du har installert riktig pre-commit hekte tidligere, den nylig lagt til testen vil bli kjørt, vil mislykkes, og ingenting vil bli forpliktet. Merk at det er slik vi vet at testene våre faktisk tester noe. Interessant nok, hvis vi startet med koden før testene, kan det å bestå testene enten bety at koden fungerte som forventet, eller at testene faktisk ikke testet noe. Pluss, hvis vi ikke hadde skrevet testene i utgangspunktet, kunne vi ha glemt dem helt, siden ingenting ville minnet oss om det.

Testdrevet utvikling (TDD)

TDD anbefaler å skrive tester før kode. En typisk arbeidsflyt med TDD ser slik ut.

1. Legg til en test.
2. Kjør alle testene og sørg for at den nye testen mislykkes.
3. Skriv koden.
4. Kjør testene, sørg for at alle tester består.
5. Refaktorer koden din.
6. Gjenta.

Fordi resultatene av tester som mislykkes vanligvis vises i rødt, og de som bestått vises vanligvis i grønt, er syklusen også kjent som en rød-grønn-refaktor.

️ Oppdrag

Prøv først å utføre testene og la dem mislykkes, og legg deretter til og bearbeid teksten til selve CI-trinnlisten. Du vil se at prøvene består ("grønn").
Publiser deretter den nye koden til det eksterne depotet og se testene kjøre i GitHub-grensesnittet nederst i pull request-diskusjonen og PR-statusoppdateringen.

1. Bytt til filial feature.

2. Legg disse testene til ci.test.js etter siste samtale 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. Prøv å foreta testene. Hvis pre-commit kroken er installert, vil commit-forsøket mislykkes.
4. Deretter legger du denne teksten til 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. Gjør og foreta endringer lokalt.
6. Legg inn endringer i filialen feature.

Du bør nå ha noe slikt

kommandoer

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

Slå sammen konflikt

Gå til endringsforespørsel Trinn gjennomgang.

Selv om vi ikke gjorde noe galt og testene for koden vår bestod, kan vi fortsatt ikke slå sammen grenen feature и master. Det er fordi den andre tråden bugfix ble slått sammen med master mens vi jobbet med denne PR.
Dette skaper en situasjon der den eksterne grenen master har en nyere versjon enn den vi baserte grenen på feature. På grunn av dette kan vi ikke bare spole HEAD tilbake master til slutten av tråden feature. I denne situasjonen må vi enten slå sammen eller bruke forpliktelser feature rebase master. GitHub kan faktisk utføre automatiske sammenslåinger hvis det ikke er konflikter. Akk, i vår situasjon har begge grenene konkurrerende endringer i filen ci.md. Denne situasjonen er kjent som en sammenslåingskonflikt, og vi må løse den manuelt.

Slå sammen eller rebase

Flett

• Oppretter en ekstra sammenslåing og lagrer arbeidsloggen.
  • Bevarer de originale forpliktelsene til grener med deres originale tidsstempler og forfattere.
  • Lagrer SHA av forpliktelser og lenker til dem i diskusjoner om endringsforespørsel.
• Krever engangs konfliktløsning.
• Gjør historien ikke-lineær.
  • Historien kan være vanskelig å lese på grunn av det store antallet grener (som minner om en IDE-kabel).
  • Gjør automatisk feilsøking vanskeligere, f.eks. git bisect mindre nyttig - det vil bare finne sammenslåingen.

rebase

• Replays commits fra gjeldende gren på toppen av basisgrenen etter hverandre.
  • Nye commits med nye SHA-er genereres, noe som får commits i GitHub til å matche de opprinnelige pull-forespørslene, men ikke de tilsvarende kommentarene.
  • Forpliktelser kan rekombineres og modifiseres i prosessen, eller til og med slås sammen til en.
• Flere konflikter må kanskje løses.
• Lar deg opprettholde en lineær historie.
  • Historien kan være lettere å lese så lenge den ikke er for lang uten rimelig grunn.
  • Automatisk feilsøking og feilsøking er litt enklere: gjør det mulig git bisect, kan gjøre automatiske tilbakeføringer klarere og mer forutsigbare.
• Krever publisering av en filial med migrerte forpliktelser med et flagg --force når den brukes med pull-forespørsler.

Vanligvis er team enige om å alltid bruke samme strategi når de trenger å slå sammen endringer. Dette kan være en "ren" sammenslåing eller en "ren" forpliktelse på toppen, eller noe midt i mellom, for eksempel å gjøre en forpliktelse på toppen interaktivt(git rebase -i) lokalt for filialer som ikke er publisert til det offentlige depotet, men slås sammen for "offentlige" filialer.

Her vil vi bruke merge.

️ Oppdrag

1. Sørg for at koden er i en lokal filial master oppdatert fra et eksternt depot.
2. Bytt til filial feature.
3. Start en sammenslåing med en gren master. En sammenslåingskonflikt på grunn av konkurrerende endringer i ci.md.
4. Løs konflikten slik at både listen vår over CI-trinn og et notat om det forblir i teksten.
5. Publiser en sammenslåingsforpliktelse til en ekstern filial feature.
6. Sjekk statusen til pull-forespørselen i GitHub-grensesnittet og vent til sammenslåingen er løst.

kommandoer

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

Flott jobb!

Du er ferdig med listen og nå må du godkjenne pull-forespørselen master.

️ Oppgave: Godkjenn pull-forespørsel "Trinn gjennomgang"

1. Åpne en pull-forespørsel.
2. Klikk på "Merge pull request".
3. Klikk "Bekreft sammenslåing".
4. Klikk "Slett filial" siden vi ikke lenger trenger den.

Dette er depotet ditt for øyeblikket

Produktfeil

Det sies at "testing kan brukes til å vise tilstedeværelsen av feil, men aldri til å vise deres fravær." Selv om vi hadde tester og de ikke viste oss noen feil, snek en lumsk feil seg inn i produksjonen.

I et scenario som dette må vi ta vare på:

• hva som brukes i produksjonen;
• kode i tråden master med en feil, som utviklere kan starte nytt arbeid fra.

Bør jeg rulle tilbake eller fikse det i neste versjon?

Å rulle tilbake er prosessen med å distribuere en kjent god tidligere versjon til produksjon og tilbakestille commits som inneholder feilen. "Fiksing forward" er tillegget av en fiksering til master og distribuere den nye versjonen så snart som mulig. Fordi APIer og databaseskjemaer endres etter hvert som kode distribueres til produksjon, med kontinuerlig levering og god testdekning, er tilbakerulling vanligvis mye vanskeligere og mer risikabelt enn å fikse det i neste versjon.

Siden tilbakerulling ikke medfører noen risiko i vårt tilfelle, vil vi gå denne veien, fordi det tillater oss

• fikse feilen på produktet så snart som mulig;
• lage kode inn master umiddelbart egnet for å starte i ny jobb.

️ Oppdrag

1. Bytt til filial master lokalt.
2. Oppdater det lokale depotet fra det eksterne depotet.
3. Tilbakestill PR-sammenslåingsforpliktelsen Trinn gjennomgang в master.
4. Publiser endringer i et eksternt depot.

Dette er historien til et depot med en merge commit tilbakestilt

kommandoer

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

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

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

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

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

️ Selvtest

Sørge for at ci.md inneholder ikke lenger teksten "sneaky bug" etter å ha tilbakestilt en merge commit.

Fiks listen over CI-trinn og returner den til master

Vi har fullstendig omgjort fusjonsforpliktelsen til filialen. feature. Den gode nyheten er at vi nå ikke har noen feil master. Den dårlige nyheten er at vår dyrebare liste over kontinuerlige integreringstrinn også er borte. Så ideelt sett må vi bruke rettelsen på forpliktelsene fra feature og returnere dem til master sammen med reparasjonen.

Vi kan nærme oss problemet på forskjellige måter:

• tilbakestille en forpliktelse som angrer en sammenslåing feature с master;
• flytte forplikter seg fra førstnevnte feature.

Ulike utviklingsteam bruker forskjellige tilnærminger i dette tilfellet, men vi vil flytte nyttige forpliktelser til en egen gren og opprette en egen pull-forespørsel for denne nye grenen.

️ Oppdrag

1. Lag en tråd kalt feature-fix og bytt til det.

2. Migrer alle forpliktelser fra den tidligere grenen feature til en ny tråd. Løs flettekonflikter som oppstod under migreringen.

   

3. Legg til en regresjonstest ci.test.js:

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

4. Kjør testene lokalt for å sikre at de ikke mislykkes.
5. Fjern teksten "with a sneaky bug" i ci.md.
6. Legg til testendringer og trinnlisteendringer i indeksen og forplikt dem.
7. Publiser grenen til et eksternt depot.

Du bør ende opp med noe som ligner på dette:

kommandoer

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

Opprett en pull-forespørsel.

Lag en pull-forespørsel med en tittel Fikser funksjonen... Installere feature-fix som "hodegren" og master som "basisgren".
Vennligst vent mens testene fullføres. Status på testene kan du se nederst i PR-diskusjonen.

Sørg for at du har installert master i hans gaffel depotet Som en «basegren» vil jeg ikke svare på forespørsler om endringer i kursmaterielldepotet.

Godkjenn pull-forespørsel "Fikser funksjonen"

Takk for rettelsen! Vennligst godkjenn endringene til master fra pull-forespørsel.

️ Oppdrag

1. Klikk på "Merge pull request".
2. Klikk "Bekreft sammenslåing".
3. Klikk "Slett filial" siden vi ikke lenger trenger den.

Dette bør du ha for øyeblikket.

Gratulerer!

Du har fullført alle trinnene som folk vanligvis tar under kontinuerlig integrasjon.

Hvis du oppdager problemer med kurset eller vet hvordan du kan forbedre det, kan du opprette et problem i depoter med kursmateriell. Dette kurset har også interaktiv versjon ved å bruke GitHub Learning Lab som en plattform.

Kilde: www.habr.com