Har du lärt dig Git-kommandon men vill föreställa dig hur kontinuerlig integration (CI) fungerar i verkligheten? Eller vill du kanske optimera dina dagliga aktiviteter? Den här kursen ger dig praktiska färdigheter i kontinuerlig integration med hjälp av ett GitHub-förråd. Den här kursen är inte avsedd att vara en guide som du helt enkelt kan klicka dig igenom, tvärtom kommer du att utföra samma åtgärder som människor faktiskt gör på jobbet, på samma sätt som de gör det. Jag kommer att förklara teorin när du går igenom stegen.

Vad gör vi?

Allt eftersom vi utvecklas kommer vi gradvis att skapa en lista med typiska CI-steg, vilket är ett bra sätt att komma ihåg den här listan. Med andra ord kommer vi att skapa en lista över åtgärder som utvecklare vidtar medan de gör kontinuerlig integration, gör kontinuerlig integration. Vi kommer också att använda en enkel uppsättning tester för att föra vår CI-process närmare den verkliga.

Denna GIF visar schematiskt commits i ditt arkiv när du går vidare genom kursen. Som du kan se är det inget komplicerat här och bara det mest nödvändiga.

Du kommer att gå igenom följande standard CI-scenarier:

• Arbeta med en funktion;
• Tillämpning av automatiserade tester för att säkerställa kvalitet;
• Genomförande av den prioriterade uppgiften;
• Konfliktlösning vid sammanslagning av grenar (sammanslagningskonflikt);
• Ett fel uppstår i en produktionsmiljö.

Vad kommer du att lära dig?

Du kommer att kunna svara på följande frågor:

• Vad är kontinuerlig integration (CI)?
• Vilka typer av automatiserade tester används i CI, och som svar på vilka åtgärder utlöses de?
• Vad är pull-förfrågningar och när behövs de?
• Vad är Test Driven Development (TDD) och hur relaterar det till CI?
• Ska jag sammanfoga eller bygga om ändringarna?
• Återställ eller fixa i nästa version?

Först översatte jag saker som "pull requests" överallt, men som ett resultat bestämde jag mig för att returnera fraser på engelska på vissa ställen för att minska graden av galenskap i texten. Jag kommer ibland att använda "programmerare surzhik" som det underbara verbet "begå" där folk faktiskt använder det på jobbet.

Vad är kontinuerlig integration?

Fortsatt integration, eller CI, är en teknisk praxis där varje gruppmedlem integrerar sin kod i ett gemensamt arkiv minst en gång om dagen, och den resulterande koden måste åtminstone byggas utan fel.

Det finns oenighet om denna term

Tvistepunkten är integrationsfrekvensen. Vissa hävdar att det inte räcker att slå samman kod en gång om dagen för att faktiskt integrera kontinuerligt. Ett exempel ges på ett team där alla tar färsk kod på morgonen och integrerar den en gång på kvällen. Även om detta är en rimlig invändning, anses det allmänt att definitionen en gång om dagen är rimligt praktisk, specifik och lämplig för lag av olika storlekar.

En annan invändning är att C++ inte längre är det enda språket som används i utvecklingen, och att helt enkelt kräva felfri montering som ett sätt för validering är svagt. Vissa tester (till exempel enhetstester som utförs lokalt) måste också slutföras framgångsrikt. För tillfället går samhället mot att göra detta till ett krav, och i framtiden kommer "bygg + enhetstester" troligen att bli vanlig praxis, om det inte redan har gjort det.

Fortsatt integration annorlunda än kontinuerlig leverans (Kontinuerlig leverans, CD) eftersom det inte kräver en releasekandidat efter varje integrationscykel.

Lista över steg vi kommer att använda under hela kursen

1. Dra in den senaste koden. Skapa en gren från master. Börja jobba.
2. Skapa commits på din nya filial. Bygg och testa lokalt. Passera? Gå till nästa steg. Misslyckas? Åtgärda fel eller tester och försök igen.
3. Tryck till ditt fjärrlager eller fjärrgren.
4. Skapa en pull-begäran. Diskutera ändringarna, lägg till fler åtaganden när diskussionen fortsätter. Få tester att passera på funktionsgrenen.
5. Merge/rebase commits från master. Få tester att passera på sammanslagningsresultatet.
6. Distribuera från funktionsgrenen till produktion.
7. Om allt är bra i produktionen under en viss tid, slå samman ändringar till master.

️ Förberedelser

Se till att du har rätt programvara

För att gå den här kursen behöver du node.js и Git klient.

Du kan använda vilken Git-klient som helst, men jag kommer bara att tillhandahålla kommandon för kommandoraden.

Se till att du har en Git-klient installerad som stöder kommandoraden

Om du ännu inte har en Git-klient som stöder kommandoraden, kan du hitta installationsinstruktioner här.

Förbered förvaret

Du måste skapa en personlig kopia (gaffel) mallförråd med kod för kursen på GitHub. Låt oss gå med på att kalla denna personliga kopia kursförråd.

Gjort? Om du inte har ändrat standardinställningarna kallas ditt kursförråd troligen continuous-integration-team-scenarios-students, den finns i ditt GitHub-konto och webbadressen ser ut så här

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

Jag ringer helt enkelt den här adressen <URL репозитория>.

Vinkelfästen som <тут> kommer att innebära att du måste ersätta ett sådant uttryck med lämpligt värde.

Se till att GitHub-åtgärder ingår för detta kursförråd. Om de inte är aktiverade, vänligen aktivera dem genom att klicka på den stora knappen i mitten av sidan, som du kan komma till genom att klicka på Actions i GitHub-gränssnittet.

Du kommer inte att kunna slutföra kursen enligt mina instruktioner om GitHub Actions inte är aktiverade.

Du kan alltid använda GitHubs förmåga att rendera Markdown för att se det aktuella läget för listan vi skriver här

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

Om svaren

Även om det bästa sättet att slutföra den här kursen är att göra den själv, kan du ha vissa svårigheter.

Om du känner att du inte förstår vad du ska göra och inte kan fortsätta kan du titta in i tråden solution, som finns i ditt startförråd.
Vänligen slå inte samman solution в master under kursen. Du kan använda den här grenen för att ta reda på vad du ska göra, eller för att jämföra din kod med författarens, genom att använda alla de möjligheter som Git ger oss. Om du är helt vilsen kan du byta ut din filial helt master på en gren solution och återställ sedan din arbetskatalog till det kurssteg du behöver.

Använd bara detta om du verkligen behöver det

Ange din kod

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

Dessa kommandon

• Döp om master в master-backup;
• Döp om solution в master;
• kassan till en ny filial master och skriva om innehållet i arbetskatalogen;
• Skapa en "lösning"-gren från "master" (som brukade vara "lösning") om du skulle behöva en "lösning"-gren i framtiden.

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

Efter dessa steg kan du använda git log master för att ta reda på vilken commit du behöver.
Du kan återställa din arbetskatalog till denna commit så här:

git reset --hard <the SHA you need>

Om du är nöjd med resultatet kommer du någon gång att behöva publicera din version av förvaret till ett fjärrlager. Glöm inte att uttryckligen ange fjärrgrenen när du gör detta.

git push --force origin master

Observera att vi använder git push --force. Det är osannolikt att du kommer att vilja göra det här väldigt ofta, men vi har ett väldigt specifikt scenario här med en förvarsanvändare som dessutom förstår vad han gör.

Börjar jobba

Låt oss börja sammanställa vår lista med CI-steg. Normalt skulle du börja det här steget genom att kolla in den senaste versionen av koden från fjärrförvaret, men vi har inget lokalt förråd än, så vi klonar det från fjärrförvaret istället.

️ Uppgift: uppdatera det lokala förvaret, skapa en filial från master, börja jobba

1. Klona kursförvaret från <URL репозитория>.
2. Springa npm install i kursförrådets katalog; Vi behöver det för att installera Jest, som vi använder för att köra tester.
3. Skapa en gren och namnge den feature. Byt till den här tråden.

4. Lägg till testkod till ci.test.js mellan kommentarer som ber mig att göra detta.

   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. Lägg till text med de första 4 stegen till 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.  

   kommandon

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

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

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

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

Skapa commits på en ny filial, bygg och testa lokalt

Vi kommer att ställa in testerna så att de körs innan vi begår, och sedan commit koden.

Typiska scenarier när tester körs automatiskt

• Lokalt:
  • Kontinuerligt eller som svar på lämpliga kodändringar;
  • Om att spara (för tolkade eller JIT-kompilerade språk);
  • Under montering (när kompilering krävs);
  • På commit;
  • När du publicerar till ett delat arkiv.

• På byggservern eller byggmiljön:
  • När kod publiceras till en personlig filial/förråd.
  • Koden i den här tråden testas.
  • Det potentiella resultatet av sammanslagningen testas (vanligtvis med master).
  • Som ett kontinuerligt integrationssteg/kontinuerlig leveranspipeline

Vanligtvis gäller att ju snabbare en testsvit körs, desto oftare har du råd att köra den. En typisk scenfördelning kan se ut så här.

• Snabba enhetstester - under konstruktion, i CI-pipeline
• Långsamma enhetstester, snabba komponent- och integrationstester - vid commit, i CI-pipeline
• Långsamma komponent- och integrationstester - i CI-pipeline
• Säkerhetstestning, belastningstestning och andra tidskrävande eller dyra tester - i CI/CD-pipelines, men endast i vissa lägen/stadier/pipelines i bygget, till exempel när man förbereder en releasekandidat eller när man kör manuellt.

️Uppgift

Jag föreslår att du kör testerna manuellt först med kommandot npm test. Efter det, låt oss lägga till en git-hook för att köra våra tester på commit. Det finns en hake: Git-hooks anses inte vara en del av förvaret och kan därför inte klonas från GitHub tillsammans med resten av kursmaterialet. För att installera krok måste du springa install_hook.sh eller kopiera filen repo/hooks/pre-commit till den lokala katalogen .git/hooks/.
När du binder dig kommer du att se att tester körs och de kontrollerar om vissa sökord finns i listan.

1. Kör testerna manuellt genom att köra kommandot npm test i din kursförvarsmapp. Kontrollera att testerna har slutförts.
2. Sätt en commit hook (pre-commit hook) genom att springa install_hook.sh.
3. Överför dina ändringar till ditt lokala arkiv.
4. Se till att tester körs innan du begår.

Ditt arkiv bör se ut så här efter att ha följt dessa steg.

kommandon

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

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

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

Publicera kod till ett fjärrlager eller en fjärrgren

När de väl är klara med att arbeta lokalt gör utvecklare vanligtvis sin kod offentligt tillgänglig så att den så småningom kan integreras med allmänheten. Med GitHub uppnås detta vanligtvis genom att publicera verket till antingen en personlig kopia av förvaret (personlig gaffel) eller en personlig gren.

• Med gafflar klonar en utvecklare ett delat fjärrlager och skapar en personlig fjärrkopia av det, även känd som en gaffel. Den klonar sedan detta personliga arkiv för att arbeta med lokalt. När arbetet är klart och åtagandena är gjorda, trycker han in dem i sin gaffel, där de är tillgängliga för andra och kan integreras i det gemensamma förvaret. Detta tillvägagångssätt används ofta i projekt med öppen källkod på GitHub. Det används också i min avancerade kurs [Teamwork and CI with Git] (http://devops.redpill.solutions/).
• Ett annat tillvägagångssätt är att endast använda ett fjärrlager och bara räkna grenen master delat arkiv "skyddat". I det här scenariot publicerar enskilda utvecklare sin kod till grenar av ett fjärrlager så att andra kan titta på den här koden, om allt är i sin ordning, slå samman den med master delat förråd.

I just den här kursen kommer vi att använda ett arbetsflöde som använder grenar.

Låt oss publicera vår kod.

️Uppgift

• Publicera ändringar i en fjärrgren med samma namn som din arbetsgren

kommandon

git push --set-upstream origin feature

Skapa en pull-begäran

Skapa en pull-begäran med en titel Genomgång av steg... Installera feature som "huvudgren" och master som "basgren".

Se till att du har installerat master i hans dela förvaret Som en "basgren" kommer jag inte att svara på förfrågningar om ändringar i kursmaterialförrådet.

I GitHub-språket är "basgrenen" den gren som du baserar ditt arbete på, och "huvudgrenen" är grenen som innehåller de föreslagna ändringarna.

Diskutera ändringarna, lägg till nya åtaganden allt eftersom diskussionen fortsätter

Pull request (PR)

Pull request (PR) är ett sätt att diskutera och dokumentera kod, samt genomföra kodgranskning. Pull-förfrågningar är namngivna efter det allmänna sättet att integrera individuella ändringar i den övergripande koden. Vanligtvis klonar en person projektets officiella fjärrarkiv och arbetar med koden lokalt. Efter detta placerar han koden i sitt personliga fjärrlager och ber de ansvariga för det officiella förrådet att hämta(dra) dess kod i sina lokala arkiv, där de granskar och eventuellt integrerar(sammanfoga) hans. Detta koncept är också känt under andra namn, t.ex. sammanslagningsförfrågan.

Du behöver faktiskt inte använda pull request-funktionen på GitHub eller liknande plattformar. Utvecklingsteam kan använda andra kommunikationsmetoder, inklusive kommunikation ansikte mot ansikte, röstsamtal eller e-post, men det finns fortfarande ett antal anledningar till att använda pull-förfrågningar i forumstil. Här är några av dem:

• organiserade diskussioner relaterade till specifika kodändringar;
• som en plats för att se feedback om pågående arbete från både autotestare och kamrater;
• formalisering av kodgranskningar;
• så att du senare kan ta reda på orsakerna och övervägandena bakom den eller den koden.

Vanligtvis skapar du en pull-förfrågan när du behöver diskutera något eller få feedback. Om du till exempel arbetar med en funktion som skulle kunna implementeras på mer än ett sätt, kan du skapa en pull-begäran innan du skriver den första raden med kod för att dela dina idéer och diskutera dina planer med dina medarbetare. Om arbetet är enklare öppnas en pull-begäran när något redan är gjort, engagerat och kan diskuteras. I vissa scenarier kanske du vill öppna en PR endast av kvalitetskontrollskäl: för att köra automatiserade tester eller initiera kodgranskning. Vad du än bestämmer dig för, glöm inte att @nämna de personer vars godkännande du vill ha i din pull-förfrågan.

Vanligtvis gör du följande när du skapar en PR.

• Ange vad du föreslår att ändra och var.
• Skriv en beskrivning som förklarar syftet med ändringarna. Du kanske vill:
  • lägg till något viktigt som inte är uppenbart från koden, eller något användbart för att förstå sammanhanget, såsom relevanta #bugs och commit-nummer;
  • @nämna alla du vill börja arbeta med, eller så kan du @nämna dem i kommentarerna senare;
  • be kollegor hjälpa till med något eller kolla något specifikt.

När du väl öppnar PR, körs de tester som är konfigurerade för att köras i sådana fall. I vårt fall kommer detta att vara samma uppsättning tester som vi körde lokalt, men i ett riktigt projekt kan det bli ytterligare tester och kontroller.

Vänta medan testerna är klara. Du kan se status för testerna längst ner i PR-diskussionen i GitHub-gränssnittet. Fortsätt när testerna är klara.

️ Lägg till en anteckning om slumpmässigheten i listan med CI-steg

Listan som används i denna kurs är godtycklig och subjektiv, vi bör lägga till en anteckning om detta.

️ Uppgift: skapa en pull-begäran för den här kommentaren

1. Byt till filial master.
2. Skapa en gren som heter bugfix.
3. Lägg till anteckningstext i slutet 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. Begå ändringarna.
5. Publicera tråden bugfix till ett fjärrlager.
6. Skapa en pull-begäran med namnet Lägger till en anmärkning med en huvudgren bugfix och basgrenenmaster.

Se till att du har installerat master i hans dela förvaret Som en "basgren" kommer jag inte att svara på förfrågningar om ändringar i kursmaterialförrådet.

Så här ska ditt förråd se ut.

kommandon

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

Godkänn pull-begäran "Lägger till en anmärkning"

️Uppgift

1. Skapa en pull-begäran.
2. Klicka på "Merge pull request".
3. Klicka på "Bekräfta sammanslagning".
4. Klicka på "Ta bort gren", vi behöver det inte längre.

Detta är ett diagram över åtaganden efter en sammanslagning.

️ Fortsätt jobba och lägg till tester

Att samarbeta kring en pull-förfrågan resulterar ofta i merarbete. Detta är vanligtvis resultatet av en kodgranskning eller diskussion, men i vår kurs kommer vi att modellera detta genom att lägga till nya objekt till vår lista med CI-steg.

Kontinuerlig integration innebär vanligtvis en viss testtäckning. Testtäckningskraven varierar och finns vanligtvis i ett dokument som kallas något i stil med "bidragsriktlinjer". Vi håller det enkelt och lägger till ett test för varje rad i vår checklista.

När du kör uppdrag, försök att utföra testerna först. Om du har installerat rätt pre-commit krok tidigare, det nyligen tillagda testet kommer att köras, kommer att misslyckas och ingenting kommer att begås. Observera att det är så här vi vet att våra tester faktiskt testar något. Intressant nog, om vi började med koden innan testerna, skulle godkända tester antingen betyda att koden fungerade som förväntat, eller att testerna faktiskt inte testade någonting. Plus, om vi inte hade skrivit proven i första hand, hade vi kanske glömt bort dem helt, eftersom ingenting skulle ha påmint oss om det.

Testdriven utveckling (TDD)

TDD rekommenderar att du skriver tester före kod. Ett typiskt arbetsflöde med TDD ser ut så här.

1. Lägg till ett test.
2. Kör alla tester och se till att det nya testet misslyckas.
3. Skriv koden.
4. Kör testerna, se till att alla tester klarar.
5. Refaktorera din kod.
6. Upprepa.

Eftersom resultaten av test som misslyckas vanligtvis visas i rött, och de som godkänts vanligtvis visas i grönt, är cykeln också känd som en röd-grön-refaktor.

️Uppgift

Försök först att utföra testerna och låta dem misslyckas, lägg sedan till och skriv in texten i själva CI-steglistan. Du kommer att se att proven är godkända ("gröna").
Publicera sedan den nya koden till fjärrförvaret och se testerna köras i GitHub-gränssnittet längst ner i diskussionen om pull-begäran och PR-statusuppdateringen.

1. Byt till filial feature.

2. Lägg till dessa tester till ci.test.js efter det senaste samtalet 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. Försök att utföra testerna. Om pre-commit hook är installerad, kommer commit-försöket att misslyckas.
4. Lägg sedan till denna text till 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. Gör och genomför ändringar lokalt.
6. Lägg upp ändringar i grenen feature.

Du borde nu ha något sånt här

kommandon

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

Gå till Ändringsförfrågan Genomgång av steg.

Även om vi inte gjorde något fel och testerna för vår kod klarade, kan vi fortfarande inte slå samman grenen feature и master. Det är för att den andra tråden bugfix slogs samman med master medan vi arbetade med denna PR.
Detta skapar en situation där fjärrgrenen master har en nyare version än den vi baserade grenen på feature. På grund av detta kan vi inte bara spola tillbaka HEAD master till slutet av tråden feature. I den här situationen måste vi antingen slå samman eller tillämpa commits feature rebas master. GitHub kan faktiskt utföra automatiska sammanslagningar om det inte finns några konflikter. Tyvärr, i vår situation har båda grenarna konkurrerande ändringar i filen ci.md. Denna situation är känd som en sammanslagningskonflikt, och vi måste lösa den manuellt.

Slå samman eller basera om

Sammanfoga

• Skapar ytterligare ett sammanslagningsbeslut och sparar arbetshistoriken.
  • Bevarar grenarnas ursprungliga commits med deras ursprungliga tidsstämplar och författare.
  • Sparar SHA av åtaganden och länkar till dem i diskussioner om ändringsförfrågningar.
• Kräver engångskonfliktlösning.
• Gör historien icke-linjär.
  • Historien kan vara svår att läsa på grund av det stora antalet grenar (påminner om en IDE-kabel).
  • Försvårar automatisk felsökning, t.ex. git bisect mindre användbar - det kommer bara att hitta sammanslagningsbekräftelsen.

Ombas

• Spelar om commits från den aktuella grenen ovanpå basgrenen efter varandra.
  • Nya commits med nya SHA genereras, vilket gör att commits i GitHub matchar de ursprungliga pull-förfrågningarna, men inte motsvarande kommentarer.
  • Commits kan kombineras och modifieras under processen, eller till och med slås samman till en.
• Flera konflikter kan behöva lösas.
• Låter dig upprätthålla en linjär berättelse.
  • Berättelsen kan vara lättare att läsa så länge den inte är för lång utan rimlig anledning.
  • Automatisk felsökning och felsökning är lite enklare: gör det möjligt git bisect, kan göra automatiska återställningar tydligare och mer förutsägbara.
• Kräver publicering av en filial med migrerade commits med en flagga --force när den används med pull-förfrågningar.

Vanligtvis är team överens om att alltid använda samma strategi när de behöver slå samman ändringar. Detta kan vara en "ren" sammanslagning eller en "ren" commit på toppen, eller något däremellan, som att göra en commit på toppen interaktivt(git rebase -i) lokalt för filialer som inte publiceras till det offentliga arkivet, men slås samman för "offentliga" filialer.

Här kommer vi att använda merge.

️Uppgift

1. Se till att koden finns i en lokal filial master uppdaterad från ett fjärrlager.
2. Byt till filial feature.
3. Initiera en sammanslagning med en gren master. En sammanslagningskonflikt på grund av konkurrerande ändringar av ci.md.
4. Lös konflikten så att både vår lista med CI-steg och en anteckning om det finns kvar i texten.
5. Publicera en sammanslagningsåtagande till en fjärrfilial feature.
6. Kontrollera statusen för pull-begäran i GitHub-gränssnittet och vänta tills sammanslagningen är löst.

kommandon

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

Bra jobbat!

Du är klar med listan och nu måste du godkänna indragningsförfrågan master.

️ Uppgift: Godkänn pull-begäran "Steg granskning"

1. Öppna en pull-begäran.
2. Klicka på "Merge pull request".
3. Klicka på "Bekräfta sammanslagning".
4. Klicka på "Ta bort gren" eftersom vi inte längre behöver den.

Det här är ditt förråd för tillfället

Produktfel

Det sägs att "testning kan användas för att visa förekomsten av fel, men aldrig för att visa deras frånvaro." Även om vi hade tester och de inte visade oss några fel, smög sig en lömsk bugg in i produktionen.

I ett scenario som detta måste vi ta hand om:

• vad som används i produktionen;
• kod i tråden master med ett fel, från vilket utvecklare kan börja nytt arbete.

Ska jag återställa eller fixa det i nästa version?

Återställning är processen att distribuera en känd bra tidigare version till produktion och återställa commits som innehåller felet. "Fixing forward" är tillägget av en fix till master och distribuera den nya versionen så snart som möjligt. Eftersom API:er och databasscheman ändras när koden distribueras till produktion, med kontinuerlig leverans och bra testtäckning, är återställning vanligtvis mycket svårare och mer riskabelt än att fixa det i nästa version.

Eftersom tillbakarullning inte innebär någon risk i vårt fall kommer vi att gå den här vägen, eftersom det tillåter oss

• fixa felet på produkten så snart som möjligt;
• gör kod in master omedelbart lämplig för att börja ett nytt jobb.

️Uppgift

1. Byt till filial master lokalt.
2. Uppdatera det lokala arkivet från fjärrarkivet.
3. Återställ PR-sammanslagningsåtagandet Genomgång av steg в master.
4. Publicera ändringar i ett fjärrlager.

Det här är historiken för ett arkiv med en sammanslagningsbekräftelse som har återställts

kommandon

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

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

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

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

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

️ Självtest

Se till att ci.md innehåller inte längre texten "sneaky bug" efter att ha återställt en merge-commit.

Fixa listan med CI-steg och återställ den till master

Vi har helt återställt filialens sammanslagningsåtagande. feature. Den goda nyheten är att vi nu inte har något fel master. Den dåliga nyheten är att vår värdefulla lista med kontinuerliga integrationssteg också är borta. Så, idealiskt, måste vi tillämpa korrigeringen på commits från feature och lämna tillbaka dem till master tillsammans med fixen.

Vi kan närma oss problemet på olika sätt:

• återställ en commit som ångrar en sammanslagning feature с master;
• flytta begår från det förra feature.

Olika utvecklingsteam använder olika tillvägagångssätt i det här fallet, men vi kommer att flytta användbara commits till en separat gren och skapa en separat pull-begäran för denna nya gren.

️Uppgift

1. Skapa en tråd som heter feature-fix och byt till det.

2. Migrera alla åtaganden från den tidigare grenen feature till en ny tråd. Lös sammanslagningskonflikter som uppstod under migreringen.

   

3. Lägg till ett regressionstest ci.test.js:

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

4. Kör testerna lokalt för att se till att de inte misslyckas.
5. Ta bort texten "with a sneaky bug" in ci.md.
6. Lägg till teständringar och stegliständringar i indexet och commit dem.
7. Publicera grenen till ett fjärrlager.

Du borde sluta med något liknande detta:

kommandon

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

Skapa en pull-begäran.

Skapa en pull-begäran med en titel Fixar funktionen... Installera feature-fix som "huvudgren" och master som "basgren".
Vänta medan testerna slutförs. Status på testerna kan du se längst ner i PR-diskussionen.

Se till att du har installerat master i hans dela förvaret Som en "basgren" kommer jag inte att svara på förfrågningar om ändringar i kursmaterialförrådet.

Godkänn pull-begäran "Att fixa funktionen"

Tack för rättelse! Vänligen godkänn ändringarna till master från pull begäran.

️Uppgift

1. Klicka på "Merge pull request".
2. Klicka på "Bekräfta sammanslagning".
3. Klicka på "Ta bort gren" eftersom vi inte längre behöver den.

Detta är vad du ska ha för tillfället.

Grattis!

Du har slutfört alla steg som människor vanligtvis tar under kontinuerlig integration.

Om du märker några problem med kursen eller vet hur du kan förbättra den, vänligen skapa ett problem i förråd med kursmaterial. Denna kurs har också interaktiv version använder GitHub Learning Lab som en plattform.

Källa: will.com