Heu après les ordres de Git però voleu imaginar com funciona la integració contínua (CI) en realitat? O potser voleu optimitzar les vostres activitats diàries? Aquest curs us donarà habilitats pràctiques en la integració contínua mitjançant un repositori de GitHub. Aquest curs no pretén ser un assistent en el qual simplement puguis fer clic; al contrari, realitzaràs les mateixes accions que les persones realment fan a la feina, de la mateixa manera que ho fan. Explicaré la teoria a mesura que aneu passant pels passos.

Què fem?

A mesura que avancem, anirem creant una llista de passos típics de CI, que és una bona manera de recordar aquesta llista. En altres paraules, crearem una llista d'accions que els desenvolupadors realitzen mentre fan una integració contínua, fent una integració contínua. També utilitzarem un conjunt senzill de proves per apropar el nostre procés CI al real.

Aquest GIF mostra esquemàticament les confirmacions del vostre dipòsit a mesura que avanceu al llarg del curs. Com podeu veure, aquí no hi ha res complicat i només el més necessari.

Passareu pels següents escenaris estàndard de CI:

• Treballar en una característica;
• Aplicació de proves automatitzades per garantir la qualitat;
• Execució de la tasca prioritària;
• Resolució de conflictes en fusionar branques (conflicte de combinació);
• Es produeix un error en un entorn de producció.

Què aprendràs?

Podràs respondre les preguntes següents:

• Què és la integració contínua (CI)?
• Quins tipus de proves automatitzades s'utilitzen a CI i en resposta a quines accions es desencadenen?
• Què són les sol·licituds d'extracció i quan es necessiten?
• Què és el desenvolupament impulsat per proves (TDD) i com es relaciona amb CI?
• He de combinar o canviar de base els canvis?
• Tornar enrere o solucionar-ho a la següent versió?

Al principi vaig traduir coses com "pull requests" a tot arreu, però com a resultat vaig decidir tornar frases en anglès en alguns llocs per reduir el grau de bogeria del text. De vegades faré servir "programador surzhik" com el meravellós verb "comprometre" on la gent realment l'utilitza a la feina.

Què és la integració contínua?

Integració contínua, o CI, és una pràctica tècnica en la qual cada membre de l'equip integra el seu codi en un repositori comú almenys una vegada al dia i, com a mínim, el codi resultant s'ha de construir sense errors.

Hi ha desacords sobre aquest terme

El punt de discussió és la freqüència d'integració. Alguns argumenten que la fusió del codi només una vegada al dia no és suficient per integrar-se de manera contínua. Es posa un exemple d'un equip on tothom agafa codi nou al matí i l'integra una vegada al vespre. Tot i que aquesta és una objecció raonable, en general es creu que la definició d'un cop al dia és raonablement pràctica, específica i adequada per a equips de diferents mides.

Una altra objecció és que C++ ja no és l'únic llenguatge que s'utilitza en el desenvolupament, i simplement requerir un muntatge sense errors com a forma de validació és feble. Alguns conjunts de proves (per exemple, proves unitàries executades localment) també s'han de completar correctament. En aquests moments, la comunitat està avançant cap a fer-ho un requisit, i en el futur probablement "build + unit tests" es convertirà en una pràctica habitual, si encara no ho ha fet.

Integració contínua difereix de lliurament continu (Enviament continu, CD) ja que no requereix un candidat de llançament després de cada cicle d'integració.

Llista de passos que farem al llarg del curs

1. Introdueix l'últim codi. Crea una branca a partir de master. Comença a treballar.
2. Crea commits a la teva nova sucursal. Construir i provar localment. Passar? Aneu al pas següent. Fallar? Corregiu errors o proves i torneu-ho a provar.
3. Feu clic al vostre repositori remot o a la branca remota.
4. Creeu una sol·licitud d'extracció. Discutiu els canvis, afegiu més commits a mesura que la discussió continuï. Feu que les proves passin a la branca de funcions.
5. Fusiona/rebase les confirmacions del mestre. Feu que les proves passin el resultat de la fusió.
6. Desplegueu des de la branca de funcions a la producció.
7. Si tot està bé en producció durant un període de temps, fusioneu els canvis a mestre.

️ Preparació

Assegureu-vos que teniu el programari adequat

Per fer aquest curs necessitareu NODE.JS и Client Git.

Podeu utilitzar qualsevol client de Git, però només proporcionaré ordres per a la línia d'ordres.

Assegureu-vos que teniu instal·lat un client Git que admeti la línia d'ordres

Si encara no teniu cap client Git que admeti la línia d'ordres, podeu trobar instruccions d'instal·lació aquí.

Prepara el repositori

Haureu de crear una còpia personal (fork) dipòsit de plantilles amb codi per al curs a GitHub. Acceptem anomenar aquesta còpia personal repositori del curs.

Fet? Si no heu canviat la configuració predeterminada, és probable que es digui el vostre repositori del curs continuous-integration-team-scenarios-students, es troba al vostre compte de GitHub i l'URL té aquest aspecte

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

Simplement trucaré a aquesta adreça <URL репозитория>.

Parèntesis angulars com <тут> significarà que heu de substituir aquesta expressió pel valor adequat.

Assegureu-vos-ho Accions de GitHub inclòs per a aquest repositori del curs. Si no estan habilitats, activeu-los fent clic al botó gran que hi ha al mig de la pàgina, al qual podeu accedir fent clic a Accions a la interfície de GitHub.

No podreu completar el curs seguint les meves instruccions si les accions de GitHub no estan habilitades.

Sempre podeu utilitzar la capacitat de GitHub per renderitzar Markdown per veure l'estat actual de la llista que estem redactant aquí

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

Sobre les respostes

Tot i que la millor manera de completar aquest curs és fer-ho tu mateix, és possible que tinguis algunes dificultats.

Si creieu que no enteneu què fer i no podeu continuar, podeu mirar el fil solution, que es troba al vostre repositori d'inici.
Si us plau, no fusionis solution в master durant el curs. Podeu utilitzar aquesta branca per esbrinar què heu de fer o per comparar el vostre codi amb el de l'autor, fent servir totes les capacitats que ens ofereix Git. Si estàs completament perdut, pots substituir completament la teva sucursal master en una branca solution i després restabliu el vostre directori de treball al pas del curs que necessiteu.

Utilitzeu-lo només si realment ho necessiteu

Comprometeu el vostre codi

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

Aquestes ordres

• canviar el nom master в master-backup;
• canviar el nom solution в master;
• pagar a una nova sucursal master i reescriure el contingut del directori de treball;
• Creeu una branca de "solució" des de "mestre" (que abans era "solució") per si necessiteu una branca de "solució" en el futur.

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

Després d'aquests passos, podeu utilitzar git log master per esbrinar quin compromís necessites.
Podeu restablir el vostre directori de treball a aquest commit així:

git reset --hard <the SHA you need>

Si esteu satisfet amb el resultat, en algun moment haureu de publicar la vostra versió del dipòsit en un dipòsit remot. No oblideu especificar explícitament la branca remota quan feu això.

git push --force origin master

Tingueu en compte que fem servir git push --force. És poc probable que ho vulgueu fer molt sovint, però aquí tenim un escenari molt específic amb un usuari del repositori que, a més, entén el que fa.

Comença a treballar

Comencem a compilar la nostra llista de passos CI. Normalment, començareu aquest pas comprovant la darrera versió del codi del dipòsit remot, però encara no tenim un dipòsit local, així que el clonem des del dipòsit remot.

️ Tasca: actualitzar el repositori local, crear una branca des de master, comença a treballar

1. Clonar el repositori del curs des de <URL репозитория>.
2. Correr npm install al directori del repositori del curs; El necessitem per instal·lar Jest, que fem servir per fer proves.
3. Crea una branca i posa-hi un nom feature. Canvia a aquest fil.

4. Afegeix el codi de prova a ci.test.js entre comentaris que em demanen que ho faci.

   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. Afegiu text amb els 4 primers passos al fitxer 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.  

   Equips

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

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

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

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

Creeu compromisos en una branca nova, creeu i proveu localment

Configurarem les proves perquè s'executin abans de comprometre's i, a continuació, confirmarem el codi.

Escenaris típics quan les proves s'executen automàticament

• Localment:
  • Contínuament o en resposta als canvis de codi adequats;
  • En desar (per a llenguatges interpretats o compilats amb JIT);
  • Durant el muntatge (quan cal la compilació);
  • En compromís;
  • Quan es publica en un repositori compartit.

• Al servidor o entorn de compilació:
  • Quan el codi es publica a una branca/repositori personal.
  • El codi d'aquest fil s'està provant.
  • El resultat potencial de la fusió es prova (generalment amb master).
  • Com a etapa d'integració contínua/conduït de lliurament continu

Normalment, com més ràpid s'executa una suite de proves, més sovint us podeu permetre executar-la. Una distribució escènica típica podria semblar així.

• Proves d'unitats ràpides: durant la construcció, en el pipeline CI
• Proves d'unitat lentes, proves de components ràpides i d'integració - en commit, en el pipeline CI
• Proves d'integració i components lents: en el pipeline CI
• Proves de seguretat, proves de càrrega i altres proves costoses o que consumeixen molt de temps: en pipelines CI/CD, però només en determinades maneres/etapes/conductes de la compilació, per exemple, quan es prepara un candidat de llançament o quan s'executa manualment.

️Tasca

Suggereixo executar les proves manualment primer mitjançant l'ordre npm test. Després d'això, afegim un git hook per executar les nostres proves en commit. Hi ha un problema: els ganxos de Git no es consideren part del dipòsit i, per tant, no es poden clonar des de GitHub juntament amb la resta de materials del curs. Per instal·lar el ganxo, cal córrer install_hook.sh o copieu el fitxer repo/hooks/pre-commit al directori local .git/hooks/.
Quan us comprometeu, veureu que s'executen proves i comproven si determinades paraules clau estan presents a la llista.

1. Executeu les proves manualment executant l'ordre npm test a la carpeta del dipòsit del vostre curs. Comproveu que les proves s'han completat.
2. Establiu un ganxo de confirmació (ganxo precommit) executant install_hook.sh.
3. Envieu els vostres canvis al vostre repositori local.
4. Assegureu-vos que les proves s'executen abans de comprometre's.

El vostre repositori hauria de tenir aquest aspecte després de seguir aquests passos.

Equips

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

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

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

Publiceu el codi a un repositori remot o a una branca remota

Un cop han acabat de treballar localment, els desenvolupadors solen fer que el seu codi estigui disponible públicament perquè finalment es pugui integrar amb el públic. Amb GitHub, això s'aconsegueix normalment publicant el treball en una còpia personal del dipòsit (fork personal) o en una branca personal.

• Amb forks, un desenvolupador clona un dipòsit compartit remot, creant-ne una còpia remota personal, també coneguda com a fork. A continuació, clona aquest dipòsit personal per treballar-hi localment. Quan s'ha acabat el treball i es fan els commits, els introdueix a la seva forquilla, on estan a disposició dels altres i es poden integrar al repositori comú. Aquest enfocament s'utilitza habitualment en projectes de codi obert a GitHub. També s'utilitza al meu curs avançat [Treball en equip i CI amb Git] (http://devops.redpill.solutions/).
• Un altre enfocament és utilitzar només un dipòsit remot i comptar només la branca master repositori compartit "protegit". En aquest escenari, els desenvolupadors individuals publiquen el seu codi a les branques d'un dipòsit remot perquè altres puguin mirar aquest codi, si tot està en ordre, fusionar-lo amb master repositori compartit.

En aquest curs en particular, utilitzarem un flux de treball que utilitza branques.

Publicem el nostre codi.

️Tasca

• Publiceu els canvis a una branca remota amb el mateix nom que la vostra branca de treball

Equips

git push --set-upstream origin feature

Creeu una sol·licitud d'extracció

Creeu una sol·licitud d'extracció amb un títol Revisió de passos... Instal·la feature com "branca del cap" i master com "branca base".

Assegureu-vos que heu instal·lat master en el seu bifurca el repositori Com a "branca base", no respondré a les sol·licituds de canvis al dipòsit de materials del curs.

Al llenguatge de GitHub, la "branca base" és la branca en la qual baseu el vostre treball i la "branca principal" és la branca que conté els canvis proposats.

Discutiu els canvis, afegiu nous commits a mesura que continua la discussió

Sol·licitud d'extracció (PR)

Sol·licitud d'extracció (PR) és una manera de discutir i documentar el codi, així com de fer una revisió del codi. Les sol·licituds d'extracció reben el nom de la manera general d'integrar els canvis individuals al codi global. Normalment, una persona clona el dipòsit oficial remot del projecte i treballa amb el codi localment. Després d'això, col·loca el codi al seu repositori remot personal i demana als responsables del dipòsit oficial que el recullin(tirar) el seu codi als seus repositoris locals, on revisen i possiblement integren (unir) seva. Aquest concepte també es coneix amb altres noms, per exemple, sol·licitud de combinació.

En realitat, no cal que utilitzeu la funció de sol·licitud d'extracció de GitHub o plataformes similars. Els equips de desenvolupament poden utilitzar altres mètodes de comunicació, com ara la comunicació cara a cara, les trucades de veu o el correu electrònic, però encara hi ha una sèrie de raons per utilitzar sol·licituds d'extracció d'estil fòrum. Aquests són alguns d'ells:

• debats organitzats relacionats amb canvis de codi específics;
• com a lloc per veure comentaris sobre el treball en curs tant dels autotesters com dels companys;
• formalització de revisions de codi;
• perquè més endavant pugueu esbrinar les raons i les consideracions darrere d'aquest o aquell fragment de codi.

Normalment creeu una sol·licitud d'extracció quan necessiteu parlar d'alguna cosa o rebre comentaris. Per exemple, si esteu treballant en una funció que es podria implementar de més d'una manera, podeu crear una sol·licitud d'extracció abans d'escriure la primera línia de codi per compartir les vostres idees i discutir els vostres plans amb els vostres col·laboradors. Si el treball és més senzill, s'obre una sol·licitud d'extracció quan alguna cosa ja s'ha fet, s'ha compromès i es pot discutir. En alguns escenaris, és possible que vulgueu obrir un PR només per motius de control de qualitat: per executar proves automatitzades o iniciar revisions de codi. Sigui el que decidiu, no us oblideu de @esmentar les persones l'aprovació de les quals voleu a la vostra sol·licitud d'extracció.

Normalment, quan creeu un PR, feu el següent.

• Indica què et proposes canviar i on.
• Escriu una descripció explicant el propòsit dels canvis. És possible que vulgueu:
  • afegiu qualsevol cosa important que no sigui obvi del codi, o alguna cosa útil per entendre el context, com ara #bugs rellevants i números de confirmació;
  • @mencioneu qualsevol persona amb qui vulgueu començar a treballar, o podeu @esmentar-los als comentaris més tard;
  • Demaneu als companys que us ajudin amb alguna cosa o comproveu alguna cosa concreta.

Un cop obriu el PR, s'executen les proves configurades per executar-se en aquests casos. En el nostre cas, aquest serà el mateix conjunt de proves que vam fer localment, però en un projecte real pot haver-hi proves i comprovacions addicionals.

Si us plau, espereu mentre s'acabin les proves. Podeu veure l'estat de les proves a la part inferior de la discussió de relacions públiques a la interfície de GitHub. Continueu quan finalitzin les proves.

️ Afegiu una nota sobre l'aleatorietat de la llista de passos CI

La llista utilitzada en aquest curs és arbitrària i subjectiva, cal afegir-hi una nota al respecte.

️ Tasca: crea una sol·licitud d'extracció per a aquest comentari

1. Canvia a la branca master.
2. Creeu una branca anomenada bugfix.
3. Afegiu el text de la nota al final del fitxer 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. Comprometeu els canvis.
5. Publica el fil bugfix a un repositori remot.
6. Creeu una sol·licitud d'extracció anomenada Afegint una observació amb una branca de cap bugfix i la branca basemaster.

Assegureu-vos que heu instal·lat master en el seu bifurca el repositori Com a "branca base", no respondré a les sol·licituds de canvis al dipòsit de materials del curs.

Així hauria de ser el vostre repositori.

Equips

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

Aprova la sol·licitud d'extracció "Afegir una observació"

️Tasca

1. Creeu una sol·licitud d'extracció.
2. Feu clic a "Combina la sol·licitud d'extracció".
3. Feu clic a "Confirmar la fusió".
4. Feu clic a "Eliminar branca", ja no la necessitem.

Aquest és un diagrama de commits després d'una fusió.

️ Seguiu treballant i afegint proves

Col·laborar en una sol·licitud d'extracció sovint comporta feina addicional. Això sol ser el resultat d'una revisió o discussió del codi, però al nostre curs ho modelarem afegint nous elements a la nostra llista de passos CI.

La integració contínua normalment implica una certa cobertura de prova. Els requisits de cobertura de la prova varien i normalment es troben en un document anomenat com a "directrius de contribució". Ho farem senzill i afegirem una prova per a cada línia de la nostra llista de verificació.

Quan executeu les tasques, proveu de fer les proves primer. Si heu instal·lat correctament pre-commit enganxeu abans, la prova recentment afegida s'executarà, fallarà i no es comprometrà res. Tingueu en compte que així és com sabem que les nostres proves estan provant alguna cosa. Curiosament, si vam començar amb el codi abans de les proves, passar les proves podria significar que el codi funcionava com s'esperava o que les proves no estaven provant res. A més, si no haguéssim escrit les proves en primer lloc, potser ens n'hauríem oblidat del tot, ja que res no ens ho hauria recordat.

Desenvolupament impulsat per proves (TDD)

TDD recomana escriure proves abans del codi. Un flux de treball típic que utilitza TDD té aquest aspecte.

1. Afegeix una prova.
2. Executeu totes les proves i assegureu-vos que la prova nova falla.
3. Escriu el codi.
4. Executeu les proves, assegureu-vos que totes les passen.
5. Refactoritza el teu codi.
6. Repetiu.

Com que els resultats de les proves que fracassen solen mostrar-se en vermell, i els que han superat es mostren normalment en verd, el cicle també es coneix com a red-verd-refactor.

️Tasca

Primer, proveu de confirmar les proves i deixar-les fallar i, a continuació, afegiu i envieu el text de la pròpia llista de passos CI. Veureu que les proves van passant ("verd").
A continuació, publiqueu el codi nou al repositori remot i observeu com s'executen les proves a la interfície GitHub a la part inferior de la discussió de la sol·licitud d'extracció i l'actualització de l'estat de PR.

1. Canvia a la branca feature.

2. Afegiu aquestes proves a ci.test.js després de la darrera trucada 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. Intenta fer les proves. Si pre-commit el ganxo està instal·lat, l'intent de confirmació fallarà.
4. A continuació, afegiu aquest text a 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. Feu i cometeu canvis localment.
6. Publicar els canvis a la sucursal feature.

Ara hauríeu de tenir alguna cosa així

Equips

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

Conflicte de fusió

Aneu a Sol·licitud de canvi Revisió de passos.

Tot i que no hem fet res malament i les proves del nostre codi han passat, encara no podem fusionar la branca feature и master. És perquè l'altre fil bugfix es va fusionar amb master mentre estàvem treballant en aquest PR.
Això crea una situació en què la branca remota master té una versió més nova que la que vam basar la branca feature. Per això no podem simplement rebobinar HEAD master fins al final del fil feature. En aquesta situació, hem de combinar o aplicar commits feature rebase master. GitHub pot realitzar fusions automàtiques si no hi ha conflictes. Per desgràcia, en la nostra situació, ambdues branques tenen canvis competitius a l'expedient ci.md. Aquesta situació es coneix com a conflicte de combinació i hem de resoldre'l manualment.

Fusionar o canviar de base

Unir

• Crea una confirmació de combinació addicional i desa l'historial de treball.
  • Conserva les confirmacions originals de les branques amb les seves marques de temps i autors originals.
  • Desa el SHA de les confirmacions i els enllaça a les discussions de sol·licituds de canvi.
• Requereix una sola resolució de conflictes.
• Fa que la història no sigui lineal.
  • La història pot ser difícil de llegir a causa del gran nombre de branques (recorda un cable IDE).
  • Dificulta la depuració automàtica, p. git bisect menys útil: només trobarà la confirmació de fusió.

rebase

• Reprodueix les confirmacions de la branca actual a la part superior de la branca base una darrere l'altra.
  • Es generen nous commits amb nous SHA, de manera que els commits de GitHub coincideixen amb les sol·licituds d'extracció originals, però no amb els comentaris corresponents.
  • Els commits es poden recombinar i modificar en el procés, o fins i tot fusionar-se en un.
• És possible que s'hagin de resoldre diversos conflictes.
• Permet mantenir una història lineal.
  • La història pot ser més fàcil de llegir sempre que no sigui massa llarga sense cap motiu raonable.
  • La depuració automàtica i la resolució de problemes és una mica més fàcil: ho fa possible git bisect, pot fer que els retrocessos automàtics siguin més clars i previsibles.
• Requereix la publicació d'una branca amb commits migrats amb una marca --force quan s'utilitza amb sol·licituds d'extracció.

Normalment, els equips accepten utilitzar sempre la mateixa estratègia quan necessiten combinar canvis. Pot ser una fusió "pura" o una confirmació "pura" a la part superior, o alguna cosa intermèdia, com ara fer una confirmació a la part superior de manera interactiva (git rebase -i) localment per a branques no publicades al repositori públic, però fusionen per a branques "públiques".

Aquí farem servir merge.

️Tasca

1. Assegureu-vos que el codi estigui en una sucursal local master actualitzat des d'un repositori remot.
2. Canvia a la branca feature.
3. Inicieu una fusió amb una branca master. Un conflicte de fusió a causa de canvis en competència al ci.md.
4. Resol el conflicte de manera que tant la nostra llista de passos CI com una nota al respecte quedin al text.
5. Publicar una confirmació de combinació a una branca remota feature.
6. Comproveu l'estat de la sol·licitud d'extracció a la interfície d'usuari de GitHub i espereu fins que es resolgui la fusió.

Equips

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

Bona feina!

Heu acabat amb la llista i ara heu d'aprovar la sol·licitud d'extracció master.

️ Tasca: aprovar la sol·licitud d'extracció "Revisió de passos"

1. Obre una sol·licitud d'extracció.
2. Feu clic a "Combina la sol·licitud d'extracció".
3. Feu clic a "Confirmar la fusió".
4. Feu clic a "Eliminar branca" ja que ja no la necessitem.

Aquest és el vostre repositori en aquest moment

Error del producte

Es diu que "les proves es poden utilitzar per mostrar la presència d'errors, però mai per mostrar la seva absència". Tot i que vam fer proves i no ens van mostrar cap error, es va introduir un error insidios a la producció.

En un escenari com aquest, hem de tenir cura de:

• què es desplega en producció;
• codi al fil master amb un error, des del qual els desenvolupadors poden iniciar un nou treball.

He de tornar enrere o solucionar-ho a la següent versió?

La recuperació és el procés de desplegament d'una versió anterior bona coneguda a la producció i revertir les confirmacions que contenen l'error. "Fixing forward" és l'addició d'una correcció a la master i desplegant la nova versió tan aviat com sigui possible. Com que les API i els esquemes de bases de dades canvien a mesura que el codi es desplega a la producció, amb un lliurament continu i una bona cobertura de proves, la recuperació sol ser molt més difícil i arriscada que arreglar-lo a la següent versió.

Com que fer retrocedir no comporta cap risc en el nostre cas, farem aquesta ruta, perquè ens ho permet

• corregir l'error del producte tan aviat com sigui possible;
• introdueix el codi master immediatament adequat per començar una nova feina.

️Tasca

1. Canvia a la branca master localment.
2. Actualitzeu el dipòsit local des del dipòsit remot.
3. Reverteix la confirmació de fusió de PR Revisió de passos в master.
4. Publicar els canvis en un repositori remot.

Aquest és l'historial d'un dipòsit amb una confirmació de combinació revertida

Equips

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

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

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

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

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

️ Autotest

Assegureu-vos que ci.md ja no conté el text "error furtiu" després de revertir una confirmació de combinació.

Arregleu la llista de passos CI i torneu-la al mestre

Hem revertit completament el compromís de fusió de la branca. feature. La bona notícia és que ara no tenim cap error master. La mala notícia és que la nostra preciosa llista de passos d'integració contínua també ha desaparegut. Per tant, idealment, hem d'aplicar la correcció als commits de feature i retornar-los master juntament amb la correcció.

Podem abordar el problema de diferents maneres:

• revertir una confirmació que desfà una fusió feature с master;
• move commits de l'anterior feature.

Els diferents equips de desenvolupament utilitzen diferents enfocaments en aquest cas, però traslladarem les confirmacions útils a una branca separada i crearem una sol·licitud d'extracció independent per a aquesta nova branca.

️Tasca

1. Crea un fil anomenat feature-fix i canviar-hi.

2. Migreu tots els commits de la branca anterior feature a un fil nou. Resoldre els conflictes de combinació que es van produir durant la migració.

   

3. Afegiu una prova de regressió a ci.test.js:

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

4. Executeu les proves localment per assegurar-vos que no fallin.
5. Elimineu el text "amb un error furtiu" a ci.md.
6. Afegiu canvis de prova i de llista de passos a l'índex i compromeu-los.
7. Publiqueu la branca en un repositori remot.

Hauríeu d'acabar amb alguna cosa semblant a això:

Equips

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

Creeu una sol·licitud d'extracció.

Creeu una sol·licitud d'extracció amb un títol Arreglant la característica... Instal·la feature-fix com "branca del cap" i master com "branca base".
Espereu mentre finalitzin les proves. Podeu veure l'estat de les proves a la part inferior de la discussió de relacions públiques.

Assegureu-vos que heu instal·lat master en el seu bifurca el repositori Com a "branca base", no respondré a les sol·licituds de canvis al dipòsit de materials del curs.

Aprova la sol·licitud d'extracció "Solucionant la funció"

Gràcies per la correcció! Aproveu els canvis a master de la sol·licitud d'extracció.

️Tasca

1. Feu clic a "Combina la sol·licitud d'extracció".
2. Feu clic a "Confirmar la fusió".
3. Feu clic a "Eliminar branca" ja que ja no la necessitem.

Això és el que hauríeu de tenir en aquest moment.

Enhorabona!

Heu completat tots els passos que la gent sol fer durant la integració contínua.

Si observeu algun problema amb el curs o sabeu com millorar-lo, creeu un problema a dipòsits amb material del curs. Aquest curs també té versió interactiva utilitzant GitHub Learning Lab com a plataforma.

Font: www.habr.com