Avete amparatu i cumandamenti di Git, ma vulete imaginà cumu l'integrazione continua (CI) funziona in realità? O forse vulete ottimisà e vostre attività di ogni ghjornu? Stu cursu vi darà cumpetenze pratiche in integrazione cuntinuu utilizendu un repository GitHub. Stu cursu ùn hè micca pensatu à esse un mago chì pudete semplicemente cliccà; à u cuntrariu, fate e stesse azzioni chì e persone facenu veramente à u travagliu, in u listessu modu ch'elli facenu. Spiegheraghju a teoria cum'è andate attraversu i passi implicati.

Chì facemu ?

Quandu avemu prugressu, avemu da creà gradualmente una lista di i passi tipici CI, chì hè una bella manera di ricurdà sta lista. In altri palori, avemu da creà una lista di l'azzioni chì i sviluppatori piglianu mentre facenu integrazione cuntinua, facenu integrazione cuntinua. Avemu ancu aduprà un inseme simplice di teste per avvicinassi u nostru prucessu CI à u veru.

Stu GIF mostra schematicamente l'impegni in u vostru repository mentre avanza in u corsu. Comu pudete vede, ùn ci hè nunda di complicatu quì è solu u più necessariu.

Passerete per i seguenti scenari standard CI:

• U travagliu nantu à una funzione;
• Applicazione di teste automatizati per assicurà a qualità;
• Implementazione di u travagliu priurità;
• Risoluzione di cunflittu quandu si fusione i rami (cunflittu di fusione);
• Un errore si trova in un ambiente di produzzione.

Chì amparate ?

Puderete risponde à e seguenti dumande:

• Cos'è l'integrazione continua (CI)?
• Chì tipi di teste automatizati sò usati in CI, è in risposta à quale azzione sò attivati?
• Chì sò e richieste di pull è quandu sò necessarii?
• Chì ghjè u Test Driven Development (TDD) è cumu si tratta di CI?
• Deve unisce o ribasà i cambiamenti?
• Ritorna o riparà in a prossima versione?

Prima aghju traduttu cose cum'è "pull requests" in ogni locu, ma in u risultatu, decisu di rinvià e frasi in inglese in certi lochi per riduce u gradu di pazzia in u testu. A volte aduprà "programmer surzhik" cum'è u maravigliosu verbu "commit" induve a ghjente l'utiliza veramente à u travagliu.

Chì ghjè l'integrazione cuntinua?

Integrazione Cuntinuu, o CI, hè una pratica tecnica in quale ogni membru di l'equipa integra u so codice in un repositoriu cumuni almenu una volta à ghjornu, è u codice resultanti deve almenu esse custruitu senza errore.

Ci sò disaccordi annantu à questu termini

U puntu di cuntinzione hè a frequenza di integrazione. Qualchidunu sustene chì u codice di fusione solu una volta à ghjornu ùn hè micca abbastanza per integrà in modu continuu. Un esempiu hè datu di una squadra induve ognunu piglia u codice frescu in a matina è l'integra una volta à a sera. Mentre chì questa hè una obiezione raghjunata, hè generalmente crede chì a definizione di una volta à ghjornu hè ragiunate pratica, specifica è adattata per squadre di diverse dimensioni.

Un'altra obiezione hè chì C ++ ùn hè più l'unicu linguaghju utilizatu in u sviluppu, è solu esse bisognu di assemblea senza errore cum'è modu di validazione hè debule. Qualchese inseme di teste (per esempiu, teste di unità eseguite in u locu) deve ancu esse cumpletu cù successu. À u mumentu, a cumunità s'avvicina versu fà questu un requisitu, è in u futuru "custruisce + teste di unità" diventerà prubabilmente una pratica cumuna, s'ellu ùn hè micca digià.

Integrazione Cuntinuu diffirenti spedizione cuntinuu (Consegna Cuntinuu, CD) in quantu ùn hè micca bisognu di un candidatu di liberazione dopu ogni ciculu d'integrazione.

Lista di i passi chì avemu aduprà in tuttu u corsu

1. Tira in l'ultimu codice. Crea un ramu da master. Cumincià à travaglià.
2. Crea commits nantu à a vostra nova filiera. Custruite è pruvate in u locu. Passà ? Andà à u passu prossimu. Fiascu ? Fix errori o testi è pruvate di novu.
3. Push à u vostru repositoriu remotu o filiale remota.
4. Crea una dumanda di pull. Discutete i cambiamenti, aghjunghje più impegni mentre a discussione cuntinueghja. Fate passà e teste nantu à u ramu di funziunalità.
5. Merge/rebase commits da u maestru. Fate i testi à passà u risultatu di fusione.
6. Implementa da u ramu di funziunalità à a produzzione.
7. Se tuttu hè bonu in a produzzione per un certu periodu di tempu, unisce i cambiamenti à maestru.

️ Preparazione

Assicuratevi di avè u software ghjustu

Per piglià stu cursu avete bisognu Node.js и Cliente Git.

Pudete utilizà qualsiasi cliente Git, ma solu furnisce cumandamenti per a linea di cummanda.

Assicuratevi di avè un cliente Git installatu chì sustene a linea di cummanda

Se ùn avete micca un cliente Git chì sustene a linea di cummanda, pudete truvà struzzioni di installazione ccà.

Preparate u repository

Avete bisognu di creà una copia persunale (furchetta) repository di mudelli cù codice per u corsu nantu à GitHub. Accettamu di chjamà sta copia persunale repository di corsi.

Fattu ? Se ùn avete micca cambiatu i paràmetri predeterminati, u vostru repository di u cursu hè probabilmente chjamatu continuous-integration-team-scenarios-students, si trova in u vostru contu GitHub è l'URL pare cusì

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

Chjameraghju solu questu indirizzu <URL репозитория>.

Parentesi angulari cum'è <тут> significherà chì duvete rimpiazzà una tale espressione cù u valore adattatu.

Assicuratevi chì Azzione di GitHub inclusu per stu repository di u cursu. Se ùn sò micca attivati, per piacè attivateli clicchendu u grande buttone in u mità di a pagina, chì pudete ghjunghje clicchendu Azioni in l'interfaccia di GitHub.

Ùn puderà micca finisce u corsu seguendu e mo struzzioni se GitHub Actions ùn sò micca attivati.

Pudete sempre aduprà a capacità di GitHub per rende Markdown per vede u statu attuale di a lista chì componemu quì.

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

À propositu di e risposte

Mentre u megliu modu per compie stu cursu hè di fà ellu stessu, pudete avè qualchì difficultà.

Se sente chì ùn capisce micca ciò chì fà è ùn pò micca cuntinuà, pudete guardà in u filu solution, chì hè in u vostru repositoriu iniziale.
Per piacè ùn unisce micca solution в master durante u cursu. Pudete aduprà sta branche per capisce ciò chì deve fà, o per paragunà u vostru codice cù l'autore, utilizendu tutte e capacità chì Git ci dà. Sè vo site completamente persu, pudete rimpiazzà cumplettamente u vostru ramu master nantu à un ramu solution è dopu resettate u vostru cartulare di travagliu à u passu di corsu chì avete bisognu.

Aduprate questu solu sè avete veramente bisognu

Cumpete u vostru codice

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

Questi cumandamenti

• rinomina master в master-backup;
• rinomina solution в master;
• checkout à una nova filiale master è riscrivite u cuntenutu di u cartulare di travagliu;
• Crea una filiera "soluzione" da "maestru" (chì era "soluzione") in casu avete bisognu di una filiera "soluzione" in u futuru.

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

Dopu à sti passi, pudete aduprà git log master per capisce quale impegnu avete bisognu.
Pudete resettate u vostru cartulare di travagliu à questu impegnu cusì:

git reset --hard <the SHA you need>

Sè vo site cuntentu cù u risultatu, in un certu puntu vi tuccherà à pubblicà a vostra versione di u repository à un repository remota. Ùn vi scurdate di specificà esplicitamente a branche remota quandu fate questu.

git push --force origin master

Per piacè nutate chì avemu aduprà git push --force. Hè improbabile chì vulete fà questu assai spessu, ma avemu un scenariu assai specificu quì cun un utilizatore di repository chì, in più, capisce ciò chì face.

Cumincià à travaglià

Cuminciamu à cumpilà a nostra lista di passi CI. Normalmente avete da principià stu passu cuntrollandu l'ultima versione di u codice da u repositoriu remotu, ma ùn avemu micca un repositoriu lucale, cusì u clone da u repositoriu remoto invece.

️ Task: aghjurnà u repositoriu lucale, crea una filiera da master, cumincià à travaglià

1. Clona u repositoriu di u cursu da <URL репозитория>.
2. Curriri npm install in u repertoriu di i corsi; Avemu bisognu di installà Jest, chì avemu usatu per eseguisce e teste.
3. Crea un ramu è u nome feature. Cambia à stu thread.

4. Aghjunghjite u codice di prova à ci.test.js trà i cumenti chì mi dumandanu di fà questu.

   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. Aghjunghjite u testu cù i primi 4 passi à u schedariu 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.  

   Команды

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

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

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

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

Crea commits nantu à una nova filiera, custruite è pruvate in u locu

Avemu da stallà i testi per eseguisce prima di cummettà, è dopu committemu u codice.

Scenari tipici quandu e teste sò in autumàticu

• Localmente:
  • Continuamente o in risposta à i cambiamenti di codice appropritatu;
  • À u salvamentu (per lingue interpretate o compilate in JIT);
  • Durante l'assemblea (quandu a compilazione hè necessaria);
  • Nantu à impegnu;
  • Quandu pubblicà in un repositoriu spartutu.

• Nant'à u servitore di custruzzione o l'ambiente di creazione:
  • Quandu u codice hè publicatu in una filiera / repositoriu persunale.
  • U codice in questu filu hè in prova.
  • U risultatu potenziale di a fusione hè pruvatu (di solitu cù master).
  • Cum'è una tappa di integrazione cuntinua / pipeline di consegna cuntinuu

Di genere, più veloce corre una suite di teste, più spessu vi pudete permette di eseguisce. Una distribuzione di scena tipica puderia vede cusì.

• Test di unità veloci - durante a custruzione, in pipeline CI
• Test di unità lenti, teste di cumpunenti veloci è integrazione - in commit, in u pipeline CI
• Testi di cumpunenti lenti è integrazione - in u pipeline CI
• Test di sicurezza, teste di carica è altre teste di tempu o caru - in pipelines CI/CD, ma solu in certi modi/stadi/pipelines di a custruzzione, per esempiu, quandu preparanu un candidatu di liberazione o quandu eseguite manualmente.

️ Task

Suggeriu di eseguisce e teste manualmente prima utilizendu u cumandamentu npm test. Dopu quì, aghjustemu un git hook per eseguisce i nostri testi in commit. Ci hè una cattura: i ganci Git ùn sò micca cunsiderati parte di u repository è per quessa ùn ponu micca esse clonati da GitHub cù u restu di i materiali di u cursu. Per installà u ganciu, avete bisognu di eseguisce install_hook.sh o cupià u schedariu repo/hooks/pre-commit à u repertoriu lucale .git/hooks/.
Quandu si impegnate, vi vede chì e teste sò eseguite è verificate per vede se certe parole chjave sò prisenti in a lista.

1. Eseguite e teste manualmente eseguendu u cumandamentu npm test in u vostru cartulare di repository di corsu. Verificate chì i testi sò stati cumpletati.
2. Pone un commit hook (pre-commit hook) in esecuzione install_hook.sh.
3. Cumpete i vostri cambiamenti à u vostru repositoriu lucale.
4. Assicuratevi chì e teste sò eseguite prima di impegnà.

U vostru repositoriu deve esse cusì dopu avè seguitu sti passi.

Команды

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

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

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

Publicate u codice à un repositoriu remotu o una filiera remota

Una volta chì anu finitu di travaglià in u locu, i sviluppatori tipicamente facenu u so codice dispunibule publicamente in modu chì pò esse eventualmente integratu cù u publicu. Cù GitHub, questu hè tipicamenti ottenutu da publicà u travagliu sia in una copia persunale di u repositariu (fork persunale) sia in una filiera persunale.

• Cù forks, un sviluppatore clone un repository spartutu remotu, creendu una copia remota persunale di questu, cunnisciuta ancu com'è forchetta. Dopu clona stu repositoriu persunale per travaglià in u locu. Quandu u travagliu hè cumpletu è l'impegni sò fatti, li spinge in a so furchetta, induve sò dispunibuli per l'altri è ponu esse integrati in u repositoriu cumuni. Stu approcciu hè cumunimenti usatu in prughjetti open source in GitHub. Hè ancu usatu in u mo cursu avanzatu [Travagliu in squadra è CI cù Git] (http://devops.redpill.solutions/).
• Un altru approcciu hè di utilizà solu un repositoriu remotu è cuntà solu u ramu master repository spartutu "prutettu". In questu scenariu, i sviluppatori individuali publicanu u so codice à i rami di un repositoriu remotu in modu chì l'altri ponu vede stu codice, se tuttu hè in ordine, fusiona cù master repository spartutu.

In questu cursu particulari, useremu un flussu di travagliu chì usa rami.

Publicemu u nostru codice.

️ Task

• Publicate cambiamenti à una filiera remota cù u listessu nome cum'è u vostru ramu di travagliu

Команды

git push --set-upstream origin feature

Crea una dumanda di pull

Crea una dumanda di pull cun un titulu Rivista di passi... Installa feature cum'è "ramu capu" è master cum'è "ramu di basa".

Assicuratevi chì avete installatu master in u so fork u repository Cum'è "ramu di basa", ùn risponderaghju micca à e dumande di cambiamenti à u repositoriu di i materiali di u cursu.

In u lingo di GitHub, u "ramu di basa" hè u ramu nantu à quale basa u vostru travagliu, è u "ramu di capu" hè u ramu chì cuntene i cambiamenti pruposti.

Discutete i cambiamenti, aghjunghje novi impegni mentre a discussione cuntinueghja

Pull request (PR)

Pull request (PR) hè un modu per discutiri è documentà u codice, è ancu cunducerà a revisione di u codice. Pull requests sò chjamati dopu à u modu generale di integrà i cambiamenti individuali in u codice generale. Di genere, una persona clona u repositoriu ufficiale remoto di u prugettu è travaglia nantu à u codice in u locu. Dopu questu, mette u codice in u so repositoriu remoto persunale è dumanda à i rispunsevuli di u repositoriu ufficiale di piglià (pull) u so codice in i so repositori lucali, induve esaminanu è possibbilmente integranu (mischjà) u so. Stu cuncettu hè ancu cunnisciutu da altri nomi, per esempiu, dumanda di fusione.

Ùn avete micca veramente aduprà a funzione di pull request di GitHub o piattaforme simili. E squadre di sviluppu ponu aduprà altre metudi di cumunicazione, cumpresa a cumunicazione faccia à faccia, e chjama di voce, o email, ma ci sò sempre una quantità di ragiuni per aduprà richieste di pull in u foru. Eccu alcuni di elli:

• discussioni organizzate in relazione à cambiamenti di codice specifichi;
• cum'è un locu per vede feedback nantu à u travagliu in prugressu da i dui autotesters è parenti;
• formalizazione di rivisioni di codice;
• cusì chì più tardi vi ponu truvà fora i ragiuni e cunzidirazzioni daretu à issu o quellu pezzu di codice.

Di genere crea una dumanda di pull quandu avete bisognu di discutiri qualcosa o riceve feedback. Per esempiu, sè vo avete travagliatu nantu à una funzione chì puderia esse implementata in più di una manera, pudete creà una dumanda di pull prima di scrive a prima linea di codice per sparte e vostre idee è discute i vostri piani cù i vostri cullaburatori. Se u travagliu hè più simplice, una dumanda di pull hè aperta quandu qualcosa hè digià fattu, impegnatu, è pò esse discutitu. In certi scenarii, pudete vulete apre un PR solu per ragioni di cuntrollu di qualità: per eseguisce testi automatizati o inizià recensioni di codice. Qualunque cosa decide, ùn vi scurdate di @mencionà e persone chì l'appruvazioni vulete in a vostra dumanda di pull.

Di genere, quandu crea un PR, fate u seguente.

• Indicate ciò chì prupone di cambià è induve.
• Scrivite una descrizzione chì spiegà u scopu di i cambiamenti. Pudete vulete:
  • aghjunghje qualcosa impurtante chì ùn hè micca evidenti da u codice, o qualcosa d'utile per capiscenu u cuntestu, cum'è #bugs pertinenti è numeri commit;
  • @mintià qualcunu chì vulete principià à travaglià, o pudete @mentioni in i cumenti dopu;
  • dumandate à i culleghi per aiutà cù qualcosa o verificate qualcosa specificu.

Una volta chì avete apertu u PR, i testi cunfigurati per eseguisce in tali casi sò eseguiti. In u nostru casu, questu serà u stessu gruppu di teste chì avemu svoltu in u locu, ma in un veru prughjettu pò esse testi supplementari è cuntrolli.

Per piacè aspettate mentre i testi sò finiti. Pudete vede u statutu di e teste à u fondu di a discussione PR in l'interfaccia di GitHub. Cuntinuà quandu i testi sò finiti.

️ Aggiungi una nota nantu à l'aleatoriu di a lista di i passi CI

A lista utilizata in questu cursu hè arbitraria è subjectiva, duvemu aghjunghje una nota nantu à questu.

️ Task: crea una dumanda di pull per stu cumentu

1. Cambia à a filiera master.
2. Crea un ramu chjamatu bugfix.
3. Aghjunghjite u testu di nota à a fine di u schedariu 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. Cumpete i cambiamenti.
5. Publicate u filu bugfix à un repository remoto.
6. Crea un pull request chjamatu Aghjunghjite una rimarca cù un ramu capu bugfix è u ramu di basamaster.

Assicuratevi chì avete installatu master in u so fork u repository Cum'è "ramu di basa", ùn risponderaghju micca à e dumande di cambiamenti à u repositoriu di i materiali di u cursu.

Questu hè ciò chì u vostru repositoriu deve esse cum'è.

Команды

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

Appruvà a dumanda di pull "Aghjunghje una nota"

️ Task

1. Crea una dumanda di pull.
2. Cliccate "Merge pull request".
3. Cliccate "Confirmà l'unione".
4. Cliccate "Delete branch", ùn avemu più bisognu.

Questu hè un diagramma di commits dopu una fusione.

️ Continua à travaglià è aghjunghje testi

A cullaburazione nantu à una dumanda di pull spessu si traduce in un travagliu supplementu. Questu hè di solitu u risultatu di una rivisione di codice o discussione, ma in u nostru corsu andemu à modellà questu aghjunghjendu novi elementi à a nostra lista di passi CI.

L'integrazione cuntinua generalmente implica una certa copertura di prova. I requisiti di copertura di a prova varienu è sò generalmente truvati in un documentu chjamatu qualcosa cum'è "guide di cuntribuzione". Mantenemu simplice è aghjunghje una prova per ogni linea in a nostra lista di cuntrollu.

Quandu eseguite l'assignazioni, pruvate prima di fà e teste. Sè avete installatu bè pre-commit hook prima, a prova appena aghjunta serà eseguita, fallarà, è nunda ùn serà impegnatu. Nota chì questu hè cumu sapemu chì i nostri testi sò in realtà teste qualcosa. Curiosamente, se avemu principiatu cù u codice prima di e teste, passà e teste puderia significà chì u codice hà travagliatu cum'è previstu, o chì i testi ùn anu micca veramente pruvatu nunda. In più, s'ellu ùn aviamu micca scrittu i testi in u primu locu, pudemu esse scurdati di elli in tuttu, postu chì nunda ùn l'averia ricurdatu.

Sviluppu Test Driven (TDD)

TDD consiglia di scrive testi prima di codice. Un flussu di travagliu tipicu cù TDD pare cusì.

1. Aghjunghjite una prova.
2. Eseguite tutte e teste è assicuratevi chì a nova prova falla.
3. Scrivite u codice.
4. Eseguite e teste, assicuratevi chì tutte e teste passanu.
5. Refactor u vostru codice.
6. Repetite.

Perchè i risultati di e teste chì fallenu sò generalmente mostrati in rossu, è quelli chì passanu sò di solitu mostrati in verde, u ciculu hè cunnisciutu ancu com'è refactor rossu-verde.

️ Task

Prima, pruvate à cummincià e teste è lassendu fallenu, dopu aghjunghje è cummettenu u testu di a lista di u passu CI stessu. Vi vede chì i testi passanu ("verde").
Allora pubblicà u novu codice à u repositoriu remotu è fighjate e teste in l'interfaccia GitHub in u fondu di a discussione di pull request è l'aghjurnamentu di u statutu PR.

1. Cambia à a filiera feature.

2. Aghjunghjite sti testi à ci.test.js dopu l'ultima chjama 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. Pruvate à fà e teste. Se pre-commit ganciu hè stallatu, u tentativu di cummit fallerà.
4. Allora aghjunghje stu testu à 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. Fate è fate cambiamenti in u locu.
6. Post cambiamenti à a filiera feature.

Avà duvete avè qualcosa cusì

Команды

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

Unisce u cunflittu

Andà à a dumanda di cambià Rivista di passi.

Ancu s'è ùn avemu micca fattu nunda di male è i testi per u nostru codice sò passati, ùn pudemu ancu unisce u ramu feature и master. Hè perchè l'altru filu bugfix hè stata cunfundita cù master mentre avemu travagliatu annantu à questu PR.
Questu crea una situazione induve a filiera remota master hà una versione più nova di quella chì avemu basatu u ramu feature. Per via di questu ùn pudemu micca solu rewind HEAD master à a fine di u filu feature. In questa situazione, avemu bisognu di unisce o applicà commits feature ribasà master. GitHub pò daveru realizà fusioni automatiche se ùn ci sò cunflitti. Alas, in a nostra situazione, i dui rami anu cuncurrenti cambiamenti in u schedariu ci.md. Sta situazione hè cunnisciuta cum'è un cunflittu di fusione, è avemu bisognu di risolve manualmente.

Unisce o rebase

Merge

• Crea una cummissione di fusione addiziale è salva a storia di u travagliu.
  • Preserva i cummit originali di rami cù i so timestamps è l'autori originali.
  • Salva l'SHA di cummissioni è ligami à elli in discussioni di dumanda di cambiamentu.
• Esige una risoluzione di cunflittu una volta.
• Rende a storia non lineare.
  • A storia pò esse difficiuli di leghje per via di u gran numaru di rami (reminiscenze di un cable IDE).
  • Rende u debugging automaticu più difficiule, per esempiu. git bisect menu utile - truverà solu l'impegnu di fusione.

Rebase

• Replays commits da u ramu attuale nantu à u ramu di basa unu dopu l'altru.
  • Nuvelli commits cù novi SHA sò generati, facendu chì l'impegni in GitHub currispondenu à e richieste di pull originali, ma micca i cumenti currispondenti.
  • L'impegni ponu esse ricombinati è mudificati in u prucessu, o ancu fusionati in unu.
• Diversi cunflitti ponu esse risolti.
• Permette di mantene una storia lineale.
  • A storia pò esse più faciule di leghje sempre chì ùn hè micca troppu longa per nisuna ragione raghjone.
  • A debugging automatica è a risoluzione di i prublemi hè un pocu più faciule: rende pussibule git bisect, pò fà i rollback automatichi più chjaru è più prevedibile.
• Richiede a pubblicazione di una filiera cù cummissioni migrati cù una bandiera --force quandu s'utilice cù richieste di pull.

Di genere, i squadre accunsenu à aduprà sempre a stessa strategia quandu anu bisognu di unisce i cambiamenti. Questa puderia esse una fusione "pura" o una cummissione "pura" in cima, o qualcosa in trà, cum'è fà una cummissione in cima in modu interattivu (git rebase -i) in u locu per i rami chì ùn sò micca publicati à u repositoriu publicu, ma unisce per i rami "publici".

Quì avemu aduprà merge.

️ Task

1. Assicuratevi chì u codice hè in una filiera lucale master aghjurnatu da un repositoriu remoto.
2. Cambia à a filiera feature.
3. Inizià una fusione cù un ramu master. Un cunflittu di fusione per via di cambiamenti cuncurrenti à u ci.md.
4. Risolve u cunflittu cusì chì sia a nostra lista di passi CI è una nota nantu à questu fermanu in u testu.
5. Publicate un cummit di fusione à una filiera remota feature.
6. Verificate u statutu di a dumanda di pull in l'UI GitHub è aspettate finu à chì a fusione hè risolta.

Команды

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

Gran travagliu!

Avete finitu cù a lista è avà avete bisognu di appruvà a dumanda di pull in master.

️ Task: Appruvà a dumanda di pull "Steps review"

1. Apertura una dumanda di pull.
2. Cliccate "Merge pull request".
3. Cliccate "Confirmà l'unione".
4. Cliccate "Sguassà ramu" postu chì ùn avemu più bisognu.

Questu hè u vostru repository in u mumentu

Errore di u produttu

Si dice chì "a prova pò esse usata per dimustrà a prisenza di l'errori, ma mai per dimustrà a so assenza". Ancu s'è avemu avutu testi è ùn ci anu mostratu micca errori, un bug insidiosu s'hè intruduciutu in a produzzione.

In un scenariu cum'è questu, avemu bisognu di piglià cura di:

• ciò chì hè implementatu in a produzzione;
• codice in u filu master cù un errore, da quale i sviluppatori ponu inizià un novu travagliu.

Deve ritruvà o riparà in a prossima versione?

U rolling back hè u prucessu di implementà una bona versione prima cunnisciuta à a pruduzzione è di ritruvà i cummissioni chì cuntenenu l'errore. "Fixing forward" hè l'aghjunzione di una correzione à u master è implementà a nova versione u più prestu pussibule. Perchè l'API è i schemi di basa di dati cambianu cum'è u codice hè implementatu in a produzzione, cù una spedizione cuntinuu è una bona copertura di teste, u rollu hè tipicamente assai più difficiule è risicatu chè riparallu in a prossima versione.

Dapoi u rolling back ùn porta micca risicu in u nostru casu, andemu in sta strada, perchè ci permette

• riparà l'errore nantu à u pruduttu u più prestu pussibule;
• fate u codice master subitu adattatu per inizià un novu travagliu.

️ Task

1. Cambia à a filiera master lucalmente.
2. Aghjurnà u repositoriu lucale da u repositoriu remoto.
3. Ritorna l'impegnu di fusione PR Rivista di passi в master.
4. Publicà cambiamenti à un repositoriu remotu.

Questa hè a storia di un repository cun un cummit di fusione rimbursatu

Команды

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

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

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

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

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

️ Autotest

Assicuratevi chì ci.md ùn cuntene più u testu "sneaky bug" dopu à vultà un cummit di fusione.

Fix u listinu di passi CI è rinvià à maestru

Avemu rimbursatu cumplettamente l'impegnu di fusione di a filiera. feature. A bona nutizia hè chì avà ùn avemu micca errore master. A mala nutizia hè chì a nostra preziosa lista di passi di integrazione cuntinuu hè ancu andata. Allora, idealmente, avemu bisognu di applicà a correzione à l'impegni da feature è li rinviate master cù a correzione.

Pudemu avvicinà u prublema in diverse manere:

• ripiglià un commit chì annulla una fusione feature с master;
• mossa cummette da u primu feature.

Diversi squadre di sviluppu utilizanu approcci diffirenti in questu casu, ma moveremu impegni utili à una filiera separata è creanu una dumanda di pull separata per questa nova filiera.

️ Task

1. Crea un filu chjamatu feature-fix è passà à ellu.

2. Migrate tutti i commits da l'antica filiera feature à un novu filu. Risolve i cunflitti di fusione chì sò accaduti durante a migrazione.

   

3. Aghjunghjite una prova di regressione à ci.test.js:

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

4. Eseguite e teste in u locu per assicurà chì ùn fallenu micca.
5. Eliminate u testu "cù un bug sneaky" in ci.md.
6. Aghjunghjite i cambiamenti di teste è i cambiamenti di a lista di passi à l'indici è cummettenu.
7. Publicate a ramu à un repositoriu remotu.

Duvete finisce cù qualcosa simili à questu:

Команды

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

Crea una dumanda di pull.

Crea una dumanda di pull cun un titulu Fixing a funzione... Installa feature-fix cum'è "ramu capu" è master cum'è "ramu di basa".
Per piacè aspettate mentre i testi sò finiti. Pudete vede u statutu di e teste à u fondu di a discussione PR.

Assicuratevi chì avete installatu master in u so fork u repository Cum'è "ramu di basa", ùn risponderaghju micca à e dumande di cambiamenti à u repositoriu di i materiali di u cursu.

Appruvà a dumanda di pull "Fixing the feature"

Grazie per a correzione! Per piacè appruvà i cambiamenti à master da pull request.

️ Task

1. Cliccate "Merge pull request".
2. Cliccate "Confirmà l'unione".
3. Cliccate "Sguassà ramu" postu chì ùn avemu più bisognu.

Questu hè ciò chì duvete avè in u mumentu.

Congratulazioni!

Avete cumpletu tutti i passi chì a ghjente generalmente piglia durante l'integrazione cuntinua.

Sè vo avete qualchì prublema cù u corsu o sapete cumu migliurà, per piacè crea un prublema in repository cù materiali di corsu. Stu cursu hà ancu versione interattiva utilizendu GitHub Learning Lab cum'è piattaforma.

Source: www.habr.com