Ikasi al dituzu Git komandoak baina irudikatu nahi duzu nola funtzionatzen duen etengabeko integrazioak (CI) errealitatean? Edo agian zure eguneroko jarduerak optimizatu nahi dituzu? Ikastaro honek etengabeko integrazioan trebetasun praktikoak emango dizkizu GitHub biltegi bat erabiliz. Ikastaro hau ez da besterik gabe klik egin dezakezun morroia izan; aitzitik, jendeak lanean egiten dituen ekintza berdinak egingo dituzu, haiek egiten duten modu berean. Inplikatutako urratsak egin ahala teoria azalduko dizuet.

Zer egiten dugu?

Aurrera goazen heinean, pixkanaka-pixkanaka CI pauso tipikoen zerrenda sortuko dugu, eta hori zerrenda hau gogoratzeko modu bikaina da. Hau da, garatzaileek etengabeko integrazioa egiten duten bitartean egiten dituzten ekintzen zerrenda sortuko dugu, etengabeko integrazioa eginez. Proba multzo sinple bat ere erabiliko dugu gure CI prozesua benetakora hurbiltzeko.

GIF honek eskematikoki erakusten ditu zure biltegiko konpromisoak ikastaroan aurrera egin ahala. Ikusten duzunez, hemen ez dago ezer konplikaturik eta beharrezkoena bakarrik.

Honako CI agertoki estandar hauetatik joango zara:

• Ezaugarri bat lantzea;
• Kalitatea bermatzeko proba automatizatuak aplikatzea;
• Lehentasunezko zeregina gauzatzea;
• Gatazkak konpontzea adarrak batzean (batze gatazka);
• Errore bat gertatzen da ekoizpen-ingurune batean.

Zer ikasiko duzu?

Galdera hauei erantzuteko aukera izango duzu:

• Zer da etengabeko integrazioa (CI)?
• Zer proba automatizatu mota erabiltzen dira CIn, eta zer ekintzei erantzuteko abiarazten dira?
• Zer dira tira-eskaerak eta noiz behar dira?
• Zer da Test Driven Development (TDD) eta nola erlazionatzen da CI-rekin?
• Aldaketak batu edo oinarritu behar al ditut?
• Atzera egin edo konpondu nahi duzu hurrengo bertsioan?

Hasieran “pull requests” bezalako gauzak nonahi itzultzen nituen, baina, ondorioz, zenbait tokitan ingelesezko esaldiak itzultzea erabaki nuen, testuaren eromen maila murrizteko. Batzuetan "programatzaile surzhik" erabiliko dut "konprometitu" aditz zoragarria bezala, non jendeak benetan erabiltzen duen lanean.

Zer da etengabeko integrazioa?

Etengabeko Integrazioa, edo CI, taldekide bakoitzak bere kodea biltegi komun batean integratzen duen praktika tekniko bat da, egunean behin gutxienez, eta ondoriozko kodea gutxienez akatsik gabe eraiki behar da.

Termino honen inguruan desadostasunak daude

Eztabaida puntua integrazioaren maiztasuna da. Batzuen ustez, kodea egunean behin bakarrik batzea ez da nahikoa benetan etengabe integratzeko. Adibide bat jartzen da, non denek goizean kode berria hartzen duten eta arratsaldean behin integratzen duten talde batena. Hau arrazoizko eragozpena bada ere, orokorrean uste da eguneroko definizioa arrazoiz praktikoa, zehatza eta tamaina ezberdinetako taldeentzat egokia dela.

Beste eragozpen bat da C++ jada ez dela garapenean erabiltzen den hizkuntza bakarra, eta baliozkotzeko modu gisa errorerik gabeko muntaia eskatzea ahula da. Proba multzo batzuk (adibidez, lokalean exekutatutako unitate-probak) behar bezala burutu behar dira. Momentuz, komunitatea baldintza hori bihurtzeko bidean da, eta etorkizunean "eraiki + unitate-probak" ohiko praktika bihurtuko da ziurrenik, dagoeneko ez bada.

Etengabeko Integrazioa desberdina da etengabeko entrega (Etengabeko Bidalketa, CDa) izan ere, integrazio-ziklo bakoitzaren ondoren ez du kaleratze hautagairik behar.

Ikastaroan zehar erabiliko ditugun urratsen zerrenda

1. Sartu azken kodea. Sortu adar bat master. Hasi lanean.
2. Sortu konpromisoak zure adar berrian. Eraiki eta probatu lokalean. Pasa? Joan hurrengo urratsera. Huts egin? Konpondu erroreak edo probak eta saiatu berriro.
3. Bultza ezazu zure urruneko biltegira edo urruneko adarretara.
4. Sortu tira-eskaera. Eztabaidatu aldaketak, gehitu konpromiso gehiago eztabaidak aurrera egin ahala. Egin probak eginbide-adarrean gainditzea.
5. Bateratu/birbaseratutako konpromisoak maisutik. Egin probak bateratzearen emaitzari gainditzea.
6. Ezaugarrien adartik ekoizpenera zabaldu.
7. Denbora tarte batean dena ona bada ekoizpenean, batu aldaketak maisuan.

️ Prestaketa

Ziurtatu software egokia duzula

Ikastaro hau egiteko beharrezkoa izango duzu Node.js и Git bezeroa.

Edozein Git bezero erabil dezakezu, baina komando lerrorako komandoak soilik emango ditut.

Ziurtatu komando lerroa onartzen duen Git bezero bat instalatuta duzula

Oraindik ez baduzu komando-lerroa onartzen duen Git bezerorik, instalatzeko argibideak aurki ditzakezu Hemen.

Prestatu biltegia

Kopia pertsonal bat sortu beharko duzu (sardexka) txantiloien biltegia ikastaroaren kodearekin GitHub-en. Onar gaitezen kopia pertsonal honi deitzea ikastaroen biltegia.

Eginda? Ez badituzu lehenetsitako ezarpenak aldatu, ziurrenik zure ikastaroaren biltegia deituko da continuous-integration-team-scenarios-students, zure GitHub kontuan dago eta URLak honela dauka

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

Helbide honetara deituko dut, besterik gabe <URL репозитория>.

Angelu parentesiak bezalakoak <тут> esamolde hori dagokion balioarekin ordezkatu behar duzula esan nahi du.

Ziurtatu hori GitHub ekintzak ikastaro-biltegi honetarako sartuta. Gaituta ez badaude, gaitu itzazu orriaren erdiko botoi handian klik eginda, horretara iritsi zaitezke GitHub interfazeko Ekintzak sakatuta.

Ezin izango duzu ikastaroa osatu nire argibideak jarraituz GitHub Actions gaituta ez badago.

Beti erabil dezakezu GitHub-ek Markdown errendatzeko duen gaitasuna hemen osatzen ari garen zerrendaren uneko egoera ikusteko

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

Erantzunei buruz

Ikastaro hau burutzeko modurik onena norberak egitea den arren, zailtasun batzuk izan ditzakezu.

Zer egin ulertzen ez duzula eta jarraitu ezin duzula sentitzen baduzu, hariari begiratu dezakezu solution, zure hasierako biltegian dagoena.
Mesedez, ez batu solution в master ikastaroan zehar. Adar hau erabil dezakezu zer egin jakiteko edo zure kodea egilearenarekin alderatzeko, Git-ek ematen dizkigun gaitasun guztiak erabiliz. Guztiz galduta bazaude, zure adarra guztiz ordezkatu dezakezu master adar baten gainean solution eta gero berrezarri zure lan-direktorioa behar duzun ikastaroaren urratsera.

Erabili hau benetan behar baduzu

Konprometitu zure kodea

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

Agindu hauek

• izena aldatu master в master-backup;
• izena aldatu solution в master;
• ordaintzea sukurtsal berri batera master eta berridatzi laneko direktorioaren edukia;
• Sortu "soluzio" adar bat "master"-etik (lehen "konponbidea zen") etorkizunean "soluzio" adar bat behar baduzu.

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

Urrats hauen ondoren erabil dezakezu git log master zein konpromiso behar duzun jakiteko.
Zure laneko direktorioa berrezarri dezakezu konpromiso honetara:

git reset --hard <the SHA you need>

Emaitzarekin pozik bazaude, noizbait zure biltegiaren bertsioa urruneko biltegi batean argitaratu beharko duzu. Ez ahaztu hau egiten duzunean urruneko adarra esplizituki zehaztea.

git push --force origin master

Kontuan izan erabiltzen dugula git push --force. Litekeena da hori maiz egin nahi izatea, baina oso agertoki zehatz bat dugu hemen biltegiko erabiltzaile batekin, eta, gainera, zer egiten ari den ulertzen duena.

Lanean hastea

Has gaitezen gure CI urratsen zerrenda osatzen. Normalean urrats hau urruneko biltegitik kodearen azken bertsioa egiaztatuz hasiko zenuke, baina oraindik ez dugu tokiko biltegirik, beraz, urrunekotik klonatuko dugu.

️ Zeregin: eguneratu tokiko biltegia, sortu adar bat master, hasi lanean

1. Klonatu ikastaroaren biltegia <URL репозитория>.
2. Korrika egin npm install ikastaroaren biltegian; Jest instalatzeko behar dugu, probak egiteko erabiltzen duguna.
3. Sortu adar bat eta jarri izena feature. Aldatu hari honetara.

4. Gehitu proba kodea ci.test.js hau egiteko eskatzen didaten iruzkinen artean.

   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. Gehitu lehen 4 urratsekin testua fitxategiari 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 как описано выше

Sortu konpromisoak adar berri batean, eraiki eta probatu lokalean

Probak konprometitu aurretik exekutatzeko konfiguratuko ditugu, eta gero kodea konprometituko dugu.

Probak automatikoki exekutatzen direneko eszenatoki tipikoak

• Lokalean:
  • Etengabe edo kode aldaketei erantzunez;
  • Gordetzean (interpretatutako edo JIT bidez konpilatutako hizkuntzetarako);
  • Muntaian (konpilazioa behar denean);
  • Konpromisoan;
  • Biltegi partekatu batean argitaratzean.

• Eraikuntza-zerbitzarian edo eraikuntza-ingurunean:
  • Kodea adar/biltegi pertsonal batean argitaratzen denean.
  • Hari honetako kodea probatzen ari dira.
  • Fusioaren emaitza potentziala probatzen da (normalean master).
  • Etengabeko integrazio etapa/etengabeko entrega-bide gisa

Normalean, zenbat eta azkarrago exekutatu proba-multzo bat, orduan eta maizago exekutatu ahal izango duzu. Eszena banaketa tipiko bat honelakoa izan daiteke.

• Unitate-proba azkarrak - eraikuntzan, CI kanalizazioan
• Unitate-proba motelak, osagai azkarrak eta integrazio-probak - konpromisoan, CI kanalizazioan
• Osagai motelak eta integrazio probak - CI kanalizazioan
• Segurtasun-probak, karga-probak eta denbora asko edo garestiak diren beste probak - CI/CD kanalizazioetan, baina eraikuntzaren zenbait modu/etapa/tubidetan soilik, adibidez, bertsio-aurreikuspen bat prestatzean edo eskuz exekutatzen denean.

️ Zeregin

Lehenik eta behin, probak eskuz martxan jartzea gomendatzen dut komandoa erabiliz npm test. Horren ondoren, gehitu dezagun git hook gure probak konprometituz exekutatzeko. Harrapaketa bat dago: Git hookak ez dira biltegiaren parte hartzen eta, beraz, ezin dira GitHub-etik klonatu gainerako ikasmaterialekin batera. Hook instalatzeko exekutatu behar duzu install_hook.sh edo kopiatu fitxategia repo/hooks/pre-commit tokiko direktoriora .git/hooks/.
Konpromisoa egiten duzunean, probak egiten direla ikusiko duzu eta zerrendan gako-hitz batzuk dauden egiaztatzen dutela.

1. Exekutatu probak eskuz komandoa exekutatuz npm test zure ikastaroaren biltegian. Egiaztatu probak egin direla.
2. Ezarri konpromiso-kako bat (aurre-konpromiso-hook) exekutatuz install_hook.sh.
3. Konprometitu zure aldaketak tokiko biltegira.
4. Ziurtatu probak egiten direla konpromisoa hartu aurretik.

Zure biltegiak honelakoa izan beharko luke urrats hauek jarraitu ondoren.

Команды

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

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

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

Argitaratu kodea urruneko biltegi batean edo urruneko adar batean

Lokalean lanean amaitutakoan, garatzaileek normalean beren kodea publikoki eskuragarri jartzen dute, azkenean publikoarekin integratu ahal izateko. GitHub-ekin, normalean lana biltegiaren kopia pertsonal batean (fork pertsonala) edo adar pertsonal batean argitaratuz lortzen da.

• Sardexkekin, garatzaile batek urruneko biltegi partekatu bat klonatzen du, horren urruneko kopia pertsonal bat sortuz, fork izenez ere ezaguna. Ondoren, biltegi pertsonal hau klonatzen du lokalean lan egiteko. Lana amaitu eta konpromezuak egiten direnean, bere sardexkara bultzatzen ditu, beste batzuen eskura dauden eta biltegi komunean integratzeko. Ikuspegi hau GitHub-en kode irekiko proiektuetan erabiltzen da. Nire ikastaro aurreratuan ere erabiltzen da [Talde-lana eta CI Git-ekin] (http://devops.redpill.solutions/).
• Beste ikuspegi bat urruneko biltegi bakarra erabiltzea eta adarra bakarrik kontatzea da master biltegi partekatua "babestuta". Eszenatoki honetan, garatzaile indibidualek beren kodea urruneko biltegi bateko adarretan argitaratzen dute, besteek kode hau ikus dezaten, dena ondo badago, batu ezazu. master biltegi partekatua.

Ikastaro zehatz honetan, adarrak erabiltzen dituen lan-fluxu bat erabiliko dugu.

Argitara dezagun gure kodea.

️ Zeregin

• Argitaratu aldaketak zure lan-adarraren izen bera duen urruneko adar batean

Команды

git push --set-upstream origin feature

Sortu tira-eskaera

Sortu tira-eskaera izenburu batekin Urratsak berrikustea... Instalatu feature "buruko adarra" bezala eta master "oinarrizko adarra" bezala.

Ziurtatu instalatu duzula master bere baitan biltegia bifurkatu "Oinarrizko adar" gisa, ez diet erantzungo ikastaroko materialen biltegian egindako aldaketen eskaerei.

GitHub-en hizkuntzan, "oinarrizko adarra" zure lana oinarritzen duzun adarra da eta "buruko adarra" proposatutako aldaketak dituen adarra.

Eztabaidatu aldaketak, gehitu konpromiso berriak eztabaidak aurrera egin ahala

Tiratzeko eskaera (PR)

Tiratzeko eskaera (PR) kodea eztabaidatzeko eta dokumentatzeko modu bat da, baita kodea berrikusteko ere. Pull-eskaerak banakako aldaketak kode orokorrean integratzeko modu orokorretik izendatzen dira. Normalean, pertsona batek proiektuaren urruneko biltegi ofiziala klonatzen du eta kodean lan egiten du lokalean. Horren ostean, kodea bere urruneko biltegi pertsonalean sartzen du eta biltegi ofizialeko arduradunei jasotzeko eskatzen die (tira) bere kodea beren tokiko biltegietan, non berrikusi eta, agian, integratzen duten (batzeko) haren. Kontzeptu hau beste izen batzuekin ere ezagutzen da, adibidez, batu eskaera.

Ez duzu GitHub-en edo antzeko plataformen tira-eskaera funtzioa erabili beharrik. Garapen-taldeek beste komunikazio-metodo batzuk erabil ditzakete, besteak beste, aurrez aurreko komunikazioa, ahots-deiak edo posta elektronikoa, baina oraindik ere hainbat arrazoi daude foro estiloko tira-eskaerak erabiltzeko. Hona hemen horietako batzuk:

• kode aldaketa zehatzekin lotutako eztabaidak antolatu;
• garatzen ari diren lanei buruzko iritziak ikusteko leku gisa, bai autotesters eta kideen aldetik;
• kodea berrikuspenen formalizazioa;
• gero kode honen edo besteren atzean dauden arrazoiak eta gogoetak ezagutu ahal izateko.

Normalean, tira-eskaera bat sortzen duzu zerbait eztabaidatu edo iritzia jaso behar duzunean. Esate baterako, modu batean baino gehiagotan inplementa daitekeen eginbide batean lanean ari bazara, lehen lerroa kode-lerroa idatzi aurretik tira-eskaera bat sor dezakezu zure ideiak partekatzeko eta zure planak zure kolaboratzaileekin eztabaidatzeko. Lana sinpleagoa bada, pull eskaera bat irekitzen da dagoeneko zerbait egin, konprometituta eta eztabaidatu daitekeenean. Eszenatoki batzuetan, baliteke PR bat irekitzea kalitate-kontrolaren arrazoiengatik soilik: proba automatikoak egiteko edo kodearen berrikuspenak hasteko. Erabakitzen duzuna edozein dela ere, ez ahaztu zure tira eskaeran onarpena nahi duzun @aipatzea.

Normalean, PR bat sortzean, honako hau egiten duzu.

• Adierazi zer aldatzea proposatzen duzun eta non.
• Idatzi deskribapen bat aldaketen helburua azalduz. Baliteke:
  • gehitu kodean agerikoa ez den ezer garrantzitsua, edo testuingurua ulertzeko baliagarria den zerbait, hala nola # akats garrantzitsuak eta konpromezu zenbakiak;
  • @aipatu lanean hasi nahi duzun edonor, edo iruzkinetan @aipatu dezakezu geroago;
  • eskatu lankideei zerbaitetan laguntzeko edo zerbait zehatza egiaztatzeko.

PR ireki ondoren, kasu horietan exekutatzeko konfiguratutako probak exekutatzen dira. Gure kasuan, lokalean egin genuen proba multzo bera izango da, baina benetako proiektu batean proba eta egiaztapen osagarriak egon daitezke.

Mesedez, itxaron probak amaitzen diren bitartean. Proben egoera PR eztabaidaren behealdean ikus dezakezu GitHub interfazean. Jarraitu probak amaitzen direnean.

️ Gehitu ohar bat CI urratsen zerrendaren ausazkotasunari buruz

Ikastaro honetan erabilitako zerrenda arbitrarioa eta subjektiboa da, honi buruzko ohar bat gehitu beharko genuke.

️ Zeregin: sortu iruzkin honetarako tira eskaera

1. Adarra aldatu master.
2. Sortu izena duen adar bat bugfix.
3. Gehitu oharren testua fitxategiaren amaieran 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. Konprometitu aldaketak.
5. Argitaratu haria bugfix urruneko biltegi batera.
6. Sortu izena duen tira-eskaera Ohar bat gehitzea buruko adar batekin bugfix eta oinarrizko adarramaster.

Ziurtatu instalatu duzula master bere baitan biltegia bifurkatu "Oinarrizko adar" gisa, ez diet erantzungo ikastaroko materialen biltegian egindako aldaketen eskaerei.

Hau da zure biltegia nolakoa izan beharko litzatekeen.

Команды

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

Onartu tiraketa eskaera "Ohar bat gehitzea"

️ Zeregin

1. Sortu tira-eskaera.
2. Egin klik "Bateatu tira eskaera".
3. Egin klik "Berretsi bateratzea".
4. Sakatu "Ezabatu adarra", jada ez dugu behar.

Hau batu baten ondoren egindako konpromezuen diagrama da.

️ Jarraitu lanean eta probak gehitzen

Tira-eskaera batean elkarlanean aritzeak lan gehigarria eragiten du askotan. Hau kode berrikuspen edo eztabaida baten ondorioa izan ohi da, baina gure ikastaroan hau eredutzat hartuko dugu gure CI urratsen zerrendan elementu berriak gehituz.

Etengabeko integrazioak normalean probaren estalduraren bat dakar. Probaren estaldura-eskakizunak aldatu egiten dira eta normalean "ekarpen-gidalerroak" izeneko dokumentuan aurkitzen dira. Erraz mantenduko dugu eta lerro bakoitzeko proba bat gehituko dugu gure kontrol-zerrendan.

Lanak exekutatzen dituzunean, saiatu probak egiten lehenik. Ondo instalatu baduzu pre-commit hook lehenago, gehitu berri den proba exekutatuko da, huts egingo du eta ez da ezer konprometituko. Kontuan izan horrela dakigula gure probak benetan zerbait probatzen ari direla. Interesgarria da, probak baino lehen kodearekin hasten bagara, probak gainditzeak esan lezake kodeak espero bezala funtzionatu zuela edo probek ez zutela ezer probatzen. Gainera, probak lehenik idatzi ez bagenitu, agian guztiz ahaztuko genituzke, ezerk ez baitziguke gogora ekarriko.

Probak bultzatutako garapena (TDD)

TDD-k probak kodearen aurretik idaztea gomendatzen du. TDD erabiliz lan-fluxu tipiko batek itxura hau du.

1. Gehitu proba.
2. Exekutatu proba guztiak eta ziurtatu proba berriak huts egiten duela.
3. Idatzi kodea.
4. Exekutatu probak, ziurtatu proba guztiak gainditzen direla.
5. Errefaktorea zure kodea.
6. Errepikatu.

Huts egiten duten proben emaitzak gorriz agertu ohi direnez, eta gainditzen direnak berdez agertu ohi direnez, zikloa gorri-berde-refactor bezala ere ezagutzen da.

️ Zeregin

Lehenik eta behin, saiatu probak egiten eta huts egiten uzten, gero gehitu eta konprometitu CI urratsen zerrendaren beraren testua. Ikusiko duzu probak gainditzen ari direla ("berdeak").
Ondoren, argitaratu kode berria urruneko biltegian eta ikusi probak GitHub interfazean exekutatzen diren tira-eskaeraren eztabaidaren eta PR egoeraren eguneratzearen behealdean.

1. Adarra aldatu feature.

2. Gehitu proba hauek ci.test.js azken deialdiaren ostean 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. Saiatu probak egiten. Bada pre-commit hook instalatuta dago, konpromiso saiakerak huts egingo du.
4. Ondoren, gehitu testu hau 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. Egin eta konprometitu aldaketak lokalean.
6. Argitaratu aldaketak bulegoan feature.

Orain horrelako zerbait izan beharko zenuke

Команды

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

Bateratu gatazka

Joan Aldaketa eskaerara Urratsak berrikustea.

Nahiz eta ez dugu ezer gaizki egin eta gure kodearen probak gainditu, oraindik ezin dugu adarra batu feature и master. Beste haria delako bugfix batera batu zen master PR hau lantzen ari ginen bitartean.
Horrek urruneko adarra sortzen du master adarra oinarri duguna baino bertsio berriagoa du feature. Horregatik ezin dugu HEAD atzera egin master hariaren amaieraraino feature. Egoera honetan, batu edo konpromezuak aplikatu behar ditugu feature birbideratu master. GitHub-ek konbinazio automatikoak egin ditzake gatazkarik ez badago. Ai, gure egoeran, bi adarrek aldaketa lehiakorrak dituzte fitxategian ci.md. Egoera hau bateratze-gatazka bezala ezagutzen da, eta eskuz konpondu behar dugu.

Batu edo birbaseatu

Batu

• Batzeko konpromiso gehigarri bat sortzen du eta lan-historia gordetzen du.
  • Adarren jatorrizko konpromezuak gordetzen ditu jatorrizko denbora-zigiluekin eta egileekin.
  • Konpromisoen SHA eta haiei estekak gordetzen ditu aldaketa-eskaeraren eztabaidetan.
• Gatazkak behin-behineko konponbidea eskatzen du.
• Istorioa ez-lineal bihurtzen du.
  • Istorioa irakurtzen zaila izan daiteke adar kopuru handia dela eta (IDE kable bat gogorarazten du).
  • Arazte automatikoa zaildu egiten du, adibidez. git bisect gutxiago erabilgarria - bateratze-konpromisoa bakarrik aurkituko du.

Berregin

• Oinarrizko adarraren gainean uneko adarraren konpromezuak errepikatzen ditu bata bestearen atzetik.
  • SHA berriekin konpromiso berriak sortzen dira, GitHub-eko konpromisoak jatorrizko tira-eskaerekin bat etortzea eraginez, baina ez dagozkien iruzkinekin.
  • Konpromisoak prozesuan birkonbinatu eta alda daitezke, edo baita batean bateratu ere.
• Baliteke hainbat gatazka konpondu behar izatea.
• Istorio lineal bat mantentzeko aukera ematen du.
  • Istorioa errazagoa izan daiteke irakurtzeko arrazoirik gabe luzeegia ez bada.
  • Arazte automatikoa eta arazoak konpontzea apur bat errazagoa da: posible egiten du git bisect, atzerapen automatikoak argiagoak eta aurreikusgarriagoak izan ditzake.
• Migratutako konpromisoak dituen adar bat bandera batekin argitaratzea eskatzen du --force pull-eskaerekin erabiltzen denean.

Normalean, taldeek adosten dute beti estrategia bera erabiltzea aldaketak batu behar dituztenean. Hau izan daiteke batuketa "purua" edo "purua" konpromezua gainean, edo tarteko zerbait, esate baterako, goian konpromezu bat interaktiboki egitea (git rebase -i) lokalean biltegi publikoan argitaratu ez diren adarretarako, baina batu adar "publikoetarako".

Hemen bateratzea erabiliko dugu.

️ Zeregin

1. Ziurtatu kodea tokiko sukurtsal batean dagoela master urruneko biltegi batetik eguneratua.
2. Adarra aldatu feature.
3. Hasi adar batekin bateratzea master. Bateratze gatazka bat aldaketa lehiakorren ondorioz ci.md.
4. Ebatzi gatazka, gure CI urratsen zerrenda eta horri buruzko ohar bat testuan gera daitezen.
5. Argitaratu bateratze-konpromiso bat urruneko adar batean feature.
6. Egiaztatu pull-eskaeraren egoera GitHub UI-n eta itxaron bateratzea ebatzi arte.

Команды

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

Lan bikaina!

Zerrenda amaitu duzu eta orain tira eskaera onartu behar duzu master.

️ Zeregin: "Urratsen berrikuspena" eskaera onartzea

1. Ireki tira-eskaera.
2. Egin klik "Bateatu tira eskaera".
3. Egin klik "Berretsi bateratzea".
4. Egin klik "Ezabatu adarra" gehiago behar ez dugulako.

Hau da zure biltegia momentu honetan

Produktuaren errorea

Esaten da "probak akatsen presentzia erakusteko erabil daitekeela, baina inoiz ez haien falta erakusteko". Nahiz eta probak izan eta akatsik ez ziguten erakutsi, akats maltzur bat sartu zen ekoizpenean.

Horrelako eszenatoki batean, hauek zaindu behar ditugu:

• ekoizpenean hedatzen dena;
• kodea harian master akats batekin, eta hortik garatzaileek lan berria has dezakete.

Atzera egin edo konpondu behar al dut hurrengo bertsioan?

Atzera egitea da lehen bertsio ona ezaguna den ekoizpenean hedatzeko eta errorea duten konpromezuak berrezartzeko prozesua. "Aurrera konpontzea" konponketa bat gehitzea da master eta bertsio berria ahalik eta azkarren zabaltzea. APIak eta datu-baseen eskemak aldatzen direnez kodea ekoizpenera zabaltzen den heinean, etengabeko entrega eta proba-estaldura onarekin, atzera egitea hurrengo bertsioan konpontzea baino askoz zailagoa eta arriskutsua da normalean.

Atzera egiteak gure kasuan arriskurik ez duenez, bide honetatik egingo dugu, aukera ematen digulako

• konpondu produktuan akatsa ahalik eta azkarren;
• sartu kodea master berehala lan berri bat hasteko egokia.

️ Zeregin

1. Adarra aldatu master lokalean.
2. Eguneratu tokiko biltegia urruneko biltegitik.
3. Leheneratu PR batzeko konpromisoa Urratsak berrikustea в master.
4. Argitaratu aldaketak urruneko biltegi batean.

Hauxe da bateratze-konpromisoa berreskuratu duen biltegi baten historia

Команды

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

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

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

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

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

️ Auto-proba

Ziurtatu hori ci.md jada ez du "akats maltzurra" testua bateratze-konpromiso bat leheneratu ondoren.

Konpondu CI urratsen zerrenda eta itzuli masterra

Adarraren bateratze-konpromisoa erabat itzuli dugu. feature. Berri ona da orain ez dugula akatsik master. Albiste txarra da gure etengabeko integrazio-urratsen zerrenda preziatua ere desagertu dela. Beraz, hobe da konponketa aplikatu behar dugu feature eta itzuli itzazu master konponketarekin batera.

Modu ezberdinetan planteatu dezakegu arazoa:

• bateratze bat desegiten duen konpromezu bat leheneratu feature с master;
• lehengotik konprometitzen da feature.

Garapen talde ezberdinek ikuspegi desberdinak erabiltzen dituzte kasu honetan, baina konpromezu erabilgarriak beste adar batera eramango ditugu eta adar berri honetarako tira-eskaera bereizia sortuko dugu.

️ Zeregin

1. Sortu izeneko haria feature-fix eta horretara aldatu.

2. Migratu lehengo sukurtsaleko konpromiso guztiak feature hari berri batera. Ebatzi migrazioan gertatutako bateratze-gatazkak.

   

3. Gehitu erregresio proba honi ci.test.js:

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

4. Exekutatu probak lokalean huts egiten ez dutela ziurtatzeko.
5. Kendu "akats maltzur batekin" testua ci.md.
6. Gehitu proba-aldaketak eta urrats-zerrendako aldaketak indizeari eta konprometitu.
7. Argitaratu adarra urruneko biltegi batean.

Honen antzeko zerbait lortu beharko zenuke:

Команды

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

Sortu tira-eskaera.

Sortu tira-eskaera izenburu batekin Ezaugarritasuna konpontzea... Instalatu feature-fix "buruko adarra" bezala eta master "oinarrizko adarra" bezala.
Mesedez, itxaron probak amaitu bitartean. Proben egoera PR eztabaidaren behealdean ikus dezakezu.

Ziurtatu instalatu duzula master bere baitan biltegia bifurkatu "Oinarrizko adar" gisa, ez diet erantzungo ikastaroko materialen biltegian egindako aldaketen eskaerei.

Onartu tira-eskaera "Eginbidea konpontzen"

Eskerrik asko zuzentzeagatik! Mesedez, onartu aldaketak master tira eskaeratik.

️ Zeregin

1. Egin klik "Bateatu tira eskaera".
2. Egin klik "Berretsi bateratzea".
3. Egin klik "Ezabatu adarra" gehiago behar ez dugulako.

Hau da momentu honetan izan behar duzuna.

Zorionak!

Jendeak etengabeko integrazioan egin ohi dituen urrats guztiak bete dituzu.

Ikastaroarekin arazorik ikusten baduzu edo nola hobetu badakizu, mesedez sortu arazo bat ikasmaterialekin biltegiak. Ikastaro honek ere badu bertsio interaktiboa GitHub Learning Lab plataforma gisa erabiliz.

Iturria: www.habr.com