Apa sampeyan wis sinau perintah Git nanging pengin mbayangno kepiye integrasi terus (CI) bisa ditindakake? Utawa mungkin sampeyan pengin ngoptimalake aktivitas saben dina? Kursus iki bakal menehi katrampilan praktis ing integrasi terus nggunakake repositori GitHub. Kursus iki ora dimaksudake kanggo dadi tuntunan sing mung bisa diklik; Kosok baline, sampeyan bakal nindakake tumindak sing padha karo sing ditindakake wong ing pakaryan, kanthi cara sing padha. Aku bakal nerangake teori nalika sampeyan ngliwati langkah-langkah kasebut.

Apa sing kita lakoni?

Nalika kita maju, kita bakal mboko sithik nggawe dhaptar langkah-langkah CI sing khas, sing minangka cara sing apik kanggo ngelingi dhaptar iki. Kanthi tembung liyane, kita bakal nggawe dhaptar tumindak sing ditindakake para pangembang nalika nindakake integrasi terus-terusan, nindakake integrasi terus-terusan. Kita uga bakal nggunakake set prasaja saka tes kanggo nggawa proses CI nyedhaki nyata.

GIF iki kanthi skematis nuduhake komitmen ing repositori nalika sampeyan maju ing kursus. Nalika sampeyan bisa ndeleng, ora ana sing rumit lan mung sing paling perlu.

Sampeyan bakal ngliwati skenario CI standar ing ngisor iki:

• Nggawe fitur;
• Aplikasi tes otomatis kanggo njamin kualitas;
• Pelaksanaan tugas prioritas;
• Resolusi konflik nalika nggabungake cabang (konflik gabung);
• Ana kesalahan ing lingkungan produksi.

Apa sing bakal sampeyan sinau?

Sampeyan bakal bisa mangsuli pitakonan ing ngisor iki:

• Apa sing diarani Continuous Integration (CI)?
• Apa jinis tes otomatis sing digunakake ing CI, lan kanggo nanggepi tumindak apa sing dipicu?
• Apa panjaluk tarik lan kapan dibutuhake?
• Apa Test Driven Development (TDD) lan kepiye hubungane karo CI?
• Apa aku kudu nggabungake utawa rebase owah-owahan?
• Muter maneh utawa ndandani ing versi sabanjure?

Kaping pisanan, aku nerjemahake kaya "panjaluk tarik" ing endi wae, nanging minangka asil aku mutusake kanggo mbalekake frasa ing basa Inggris ing sawetara panggonan kanggo nyuda tingkat kegilaan ing teks kasebut. Aku kadhangkala bakal nggunakake "programmer surzhik" kaya kriyo apik "komit" ngendi wong bener nggunakake ing karya.

Apa integrasi terus-terusan?

Integrasi terus-terusan, utawa CI, minangka praktik teknis sing saben anggota tim nggabungake kode kasebut menyang repositori umum paling ora sapisan dina, lan kode sing diasilake kudu paling ora dibangun tanpa kesalahan.

Ana sing ora setuju babagan istilah iki

Titik pratelan yaiku frekuensi integrasi. Sawetara argue yen nggabungake kode mung sapisan dina ora cukup kanggo bener-bener nggabungake terus-terusan. Conto diwenehi tim sing saben wong njupuk kode anyar ing wayah esuk lan nggabungake sepisan ing wayah sore. Nalika iki minangka bantahan sing cukup, umume dipercaya manawa definisi sapisan dina cukup praktis, spesifik, lan cocok kanggo tim kanthi ukuran sing beda-beda.

Bantahan liyane yaiku C ++ ora mung siji-sijine basa sing digunakake ing pangembangan, lan mung mbutuhake perakitan tanpa kesalahan minangka cara validasi sing lemah. Sawetara set tes (contone, tes unit sing ditindakake sacara lokal) uga kudu rampung kanthi sukses. Ing wayahe, masyarakat wis obah menyang nggawe syarat iki, lan ing mangsa "mbangun + tes unit" mbokmenawa bakal dadi laku umum, yen durung.

Integrasi terus-terusan beda karo pangiriman terus-terusan (Pangiriman Terus-terusan, CD) amarga ora mbutuhake calon rilis sawise saben siklus integrasi.

Dhaptar langkah-langkah sing bakal digunakake sajrone kursus

1. Narik kode paling anyar. Nggawe cabang saka master. Mulai kerja.
2. Nggawe komitmen ing cabang anyar sampeyan. Mbangun lan nyoba sacara lokal. Lulus? Pindhah menyang langkah sabanjure. Gagal? Ndandani kesalahan utawa tes lan coba maneh.
3. Push menyang repositori remot utawa cabang remot.
4. Nggawe panjalukan narik. Rembugan babagan owah-owahan, tambahake komitmen nalika diskusi terus. Priksa tes pass ing cabang fitur.
5. Gabung / rebase tundhuk saka master. Nggawe tes lulus ing asil gabungan.
6. Nyebarake saka cabang fitur menyang produksi.
7. Yen kabeh produksi apik kanggo sawetara wektu, gabungke owah-owahan dadi master.

️ Persiapan

Priksa manawa sampeyan duwe piranti lunak sing bener

Kanggo njupuk kursus iki sampeyan kudu Node.js и Git klien.

Sampeyan bisa nggunakake sembarang klien Git, nanging aku mung bakal nyedhiyani printah kanggo baris printah.

Priksa manawa sampeyan duwe klien Git diinstal sing ndhukung baris printah

Yen sampeyan durung duwe klien Git sing ndhukung baris printah, sampeyan bisa nemokake instruksi instalasi kene.

Siapke gudang

Sampeyan kudu nggawe salinan pribadi (garpu) gudang cithakan karo kode kanggo mesthi ing GitHub. Ayo padha setuju nelpon salinan pribadi iki repositori kursus.

rampung? Yen sampeyan durung ngganti setelan gawan, repositori kursus sampeyan bakal diarani continuous-integration-team-scenarios-students, dumunung ing akun GitHub sampeyan lan URL katon kaya iki

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

Aku mung bakal nelpon alamat iki <URL репозитория>.

Sudut kurung kaya <тут> tegese sampeyan kudu ngganti ekspresi kasebut kanthi nilai sing cocog.

Priksa manawa Tindakan GitHub klebu kanggo gudang kursus iki. Yen ora diaktifake, aktifake kanthi ngeklik tombol gedhe ing tengah kaca, sing bisa ditindakake kanthi ngeklik Tindakan ing antarmuka GitHub.

Sampeyan ora bakal bisa ngrampungake kursus miturut pandhuanku yen Tindakan GitHub ora diaktifake.

Sampeyan bisa tansah nggunakake kemampuan GitHub kanggo nerjemahake Markdown kanggo ndeleng kahanan saiki dhaptar sing kita tulis ing kene

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

Babagan jawaban

Nalika cara paling apik kanggo ngrampungake kursus iki yaiku nindakake dhewe, sampeyan bisa uga ngalami sawetara kesulitan.

Yen sampeyan rumangsa ora ngerti apa sing kudu ditindakake lan ora bisa nerusake, sampeyan bisa ndeleng thread kasebut solution, sing ana ing repositori wiwitan sampeyan.
Mangga aja gabung solution в master sajrone kursus. Sampeyan bisa nggunakake cabang iki kanggo tokoh metu apa apa, utawa kanggo mbandhingaké kode karo penulis, nggunakake kabeh kabisan sing Git menehi kita. Yen sampeyan wis ilang, sampeyan bisa ngganti cabang master ing cabang solution banjur setel maneh direktori kerja menyang langkah kursus sing dibutuhake.

Gunakake iki mung yen sampeyan pancene mbutuhake

Gawe kode sampeyan

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

Prentah iki

• ganti jeneng master в master-backup;
• ganti jeneng solution в master;
• checkout menyang cabang anyar master lan nulis ulang isi direktori kerja;
• Nggawe cabang "solusi" saka "master" (sing biyen "solusi") yen sampeyan butuh cabang "solusi" ing mangsa ngarep.

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

Sawise langkah iki sampeyan bisa nggunakake git log master kanggo nemtokake komitmen sing sampeyan butuhake.
Sampeyan bisa ngreset direktori kerja menyang komit kaya iki:

git reset --hard <the SHA you need>

Yen sampeyan seneng karo asil kasebut, ing sawetara titik sampeyan kudu nerbitake versi repositori menyang repositori remot. Aja lali kanthi tegas nemtokake cabang remot nalika nindakake iki.

git push --force origin master

Elinga yen kita nggunakake git push --force. Ora mungkin sampeyan pengin nindakake iki kanthi asring, nanging kita duwe skenario sing spesifik banget ing kene karo siji pangguna repositori sing, saliyane, ngerti apa sing ditindakake.

Miwiti nyambut gawe

Ayo miwiti ngumpulake dhaptar langkah-langkah CI. Biasane sampeyan bakal miwiti langkah iki kanthi mriksa versi paling anyar saka kode saka repositori remot, nanging kita durung duwe repositori lokal, supaya kita tiron saka remot tinimbang.

️ Tugas: nganyari repositori lokal, nggawe cabang saka master, miwiti kerja

1. Kloning repositori kursus saka <URL репозитория>.
2. Mbukak npm install ing direktori repositori kursus; Kita kudu nginstal Jest, sing digunakake kanggo tes.
3. Nggawe cabang lan jenenge feature. Ngalih menyang thread iki.

4. Tambah kode test kanggo ci.test.js antarane komentar takon kula kanggo nindakake iki.

   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. Tambah teks kanthi 4 langkah pisanan menyang file 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.  

   Tim

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

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

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

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

Nggawe komitmen ing cabang anyar, mbangun lan nyoba sacara lokal

Kita bakal nyiyapake tes kanggo mbukak sadurunge nindakake, lan banjur nindakake kode kasebut.

Skenario khas nalika tes mlaku kanthi otomatis

• Lokal:
  • Terus-terusan utawa nanggepi owah-owahan kode sing cocog;
  • Nalika nyimpen (kanggo basa sing diinterpretasikake utawa dikompilasi JIT);
  • Sajrone perakitan (nalika kompilasi dibutuhake);
  • Ing commit;
  • Nalika nerbitake menyang repositori sing dienggo bareng.

• Ing server mbangun utawa mbangun lingkungan:
  • Nalika kode diterbitake menyang cabang pribadi / repositori.
  • Kode ing thread iki lagi dites.
  • Asil potensial saka gabungan diuji (biasane karo master).
  • Minangka tataran integrasi terus-terusan / pipa pangiriman terus-terusan

Biasane, luwih cepet suite test mlaku, luwih kerep sampeyan bisa mbukak. Distribusi panggung sing khas bisa uga katon kaya iki.

• Tes unit cepet - sajrone mbangun, ing pipa CI
• Tes unit alon, komponen cepet lan tes integrasi - ing commit, ing pipa CI
• Komponen alon lan tes integrasi - ing pipa CI
• Testing keamanan, testing mbukak lan liyane wektu-akeh utawa tes larang - ing CI / CD pipelines, nanging mung ing mode tartamtu / orane tumrap sekolah / pipelines saka mbangun, contone, nalika nyiapake calon release utawa nalika mlaku kanthi manual.

️Tugas

Aku saranake kanggo mbukak tes kanthi manual dhisik nggunakake printah npm test. Sawisé iku, ayo nambah pancing git kanggo mbukak tes ing commit. Ana siji tangkapan: Git pancingan ora dianggep minangka bagéan saka repositori lan mulane ora bisa kloning saka GitHub bebarengan karo liyane saka materi kursus. Kanggo nginstal pancing sampeyan kudu mbukak install_hook.sh utawa nyalin file repo/hooks/pre-commit menyang direktori lokal .git/hooks/.
Nalika sampeyan nindakake, sampeyan bakal weruh yen tes wis ditindakake lan mriksa manawa ana tembung kunci tartamtu ing dhaptar kasebut.

1. Jalanake tes kanthi manual kanthi mbukak printah npm test ing folder repositori kursus sampeyan. Priksa manawa tes wis rampung.
2. Setel pancing commit (pancing pra-komit) kanthi mlaku install_hook.sh.
3. Nggawe owah-owahan menyang repositori lokal.
4. Priksa manawa tes ditindakake sadurunge nindakake.

Repositori sampeyan kudu katon kaya iki sawise tindakake langkah iki.

Tim

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

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

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

Nerbitake kode menyang repositori remot utawa cabang remot

Sawise rampung nggarap lokal, pangembang biasane nggawe kode kasebut kasedhiya kanggo umum supaya pungkasane bisa diintegrasi karo masarakat. Kanthi GitHub, iki biasane digayuh kanthi nerbitake karya kasebut menyang salinan pribadi repositori (garpu pribadi) utawa cabang pribadi.

• Kanthi garpu, pangembang nggawe kloning repositori bareng remot, nggawe salinan remot pribadi, uga dikenal minangka garpu. Banjur kloning repositori pribadi iki kanggo nggarap sacara lokal. Nalika karya wis rampung lan commits digawe, dheweke nyurung menyang garpu, ing ngendi padha kasedhiya kanggo wong liya lan bisa digabungake menyang gudang umum. Pendekatan iki umume digunakake ing proyek open source ing GitHub. Iki uga digunakake ing kursus lanjutan [Team Work lan CI karo Git] (http://devops.redpill.solutions/).
• Pendekatan liyane yaiku nggunakake mung siji repositori remot lan mung ngetung cabang master repositori bareng "dilindungi". Ing skenario iki, pangembang individu nerbitake kode kasebut menyang cabang saka repositori remot supaya wong liya bisa ndeleng kode iki, yen kabeh wis rapi, gabung karo master gudang sing dienggo bareng.

Ing kursus khusus iki, kita bakal nggunakake alur kerja sing nggunakake cabang.

Ayo nerbitake kode kita.

️Tugas

• Nerbitake owah-owahan menyang cabang remot kanthi jeneng sing padha karo cabang kerja sampeyan

Tim

git push --set-upstream origin feature

Nggawe panjalukan narik

Nggawe panjalukan narik kanthi judhul Tinjauan langkah... Instal feature kaya "cabang sirah" lan master kaya "cabang dhasar".

Priksa manawa sampeyan wis nginstal master ing kang garpu gudang Minangka "cabang basa", aku ora bakal nanggapi panjalukan kanggo owah-owahan ing gudang bahan kursus.

Ing lingo GitHub, "cabang dasar" minangka cabang sing sampeyan dhasarake karya, lan "cabang kepala" minangka cabang sing ngemot owah-owahan sing diusulake.

Rembugan owah-owahan, tambahake komitmen anyar nalika diskusi terus

Panjaluk tarik (PR)

Panjaluk tarik (PR) minangka cara kanggo ngrembug lan dokumen kode, uga nindakake review kode. Panjaluk tarik dijenengi miturut cara umum kanggo nggabungake owah-owahan individu menyang kode sakabèhé. Biasane, ana wong kloning repositori resmi remot proyek lan nggarap kode kasebut sacara lokal. Sawise iki, dheweke nempatake kode kasebut ing repositori remot pribadi lan njaluk sing tanggung jawab kanggo repositori resmi kanggo njupuk (narik) kode kasebut menyang repositori lokal, ing ngendi dheweke mriksa lan bisa uga nggabungake (nggabung) kang. Konsep iki uga dikenal kanthi jeneng liya, contone, panjalukan gabung.

Sampeyan ora kudu nggunakake fitur panjaluk tarik GitHub utawa platform sing padha. Tim pangembang bisa nggunakake cara komunikasi liyane, kalebu komunikasi adhep-adhepan, telpon swara, utawa email, nanging isih ana sawetara alasan kanggo nggunakake panjalukan tarik gaya forum. Ing ngisor iki sawetara:

• diskusi sing diatur sing ana gandhengane karo owah-owahan kode tartamtu;
• minangka papan kanggo ndeleng umpan balik babagan karya sing lagi ditindakake saka autotester lan kanca-kanca;
• formalisasi review kode;
• supaya mengko sampeyan bisa mangerteni alesan lan tetimbangan konco iki utawa sing Piece saka kode.

Biasane sampeyan nggawe panjaluk narik nalika sampeyan kudu ngrembug babagan utawa entuk umpan balik. Contone, yen sampeyan lagi nggarap fitur sing bisa dileksanakake ing luwih saka siji cara, sampeyan bisa nggawe panjalukan narik sadurunge nulis baris pisanan kode kanggo nuduhake gagasan lan ngrembug rencana karo kolaborator. Yen karya luwih prasaja, panjalukan narik dibukak nalika ana sing wis rampung, setya, lan bisa dibahas. Ing sawetara skenario, sampeyan bisa uga pengin mbukak PR mung kanggo alasan kontrol kualitas: kanggo mbukak tes otomatis utawa miwiti review kode. Apa wae sing sampeyan pilih, aja lali @sebutake wong-wong sing dikarepake ing panjaluk tarik sampeyan.

Biasane, nalika nggawe PR, sampeyan nindakake ing ngisor iki.

• Tandhani apa sing arep diganti lan ing ngendi.
• Tulis katrangan sing nerangake tujuane owah-owahan. Sampeyan bisa uga pengin:
  • nambah apa-apa penting sing ora ketok saka kode, utawa soko migunani kanggo mangerteni konteks, kayata cocog #bugs lan commit nomer;
  • @sebutake sapa wae sing pengin digarap, utawa sampeyan bisa @sebutake ing komentar mengko;
  • takon kolega kanggo bantuan karo soko utawa mriksa bab tartamtu.

Sawise sampeyan mbukak PR, tes sing dikonfigurasi kanggo mbukak ing kasus kasebut bakal ditindakake. Ing kasus kita, iki bakal dadi set tes sing padha sing ditindakake sacara lokal, nanging ing proyek nyata bisa uga ana tes lan pemeriksaan tambahan.

Mangga ngenteni nalika tes rampung. Sampeyan bisa ndeleng status tes ing ngisor diskusi PR ing antarmuka GitHub. Terusake nalika tes rampung.

️ Tambah cathetan babagan acak dhaptar langkah CI

Dhaptar sing digunakake ing kursus iki sewenang-wenang lan subyektif, kita kudu nambah cathetan babagan iki.

️ Tugas: nggawe panjalukan tarik kanggo komentar iki

1. Ngalih menyang cabang master.
2. Nggawe cabang jenenge bugfix.
3. Tambah teks cathetan menyang mburi file 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. Nggawe owah-owahan.
5. Nerbitake thread bugfix menyang repositori remot.
6. Nggawe panjalukan narik jenenge Nambah komentar karo cabang sirah bugfix lan cabang dhasarmaster.

Priksa manawa sampeyan wis nginstal master ing kang garpu gudang Minangka "cabang basa", aku ora bakal nanggapi panjalukan kanggo owah-owahan ing gudang bahan kursus.

Iki minangka repositori sampeyan.

Tim

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

Setujui panjalukan tarik "Nambah komentar"

️Tugas

1. Nggawe panjalukan narik.
2. Klik "Gabung panjalukan tarik".
3. Klik "Konfirmasi gabung".
4. Klik "Busak cabang", kita ora perlu maneh.

Iki minangka diagram komitmen sawise gabung.

️ Terus kerja lan tambahake tes

Kolaborasi ing panjalukan narik asring nyebabake karya tambahan. Iki biasane minangka asil saka review kode utawa diskusi, nanging ing kursus kita bakal nggawe model iki kanthi nambah item anyar menyang dhaptar langkah-langkah CI.

Integrasi terus-terusan biasane kalebu sawetara jangkoan tes. Persyaratan jangkoan tes beda-beda lan biasane ditemokake ing dokumen sing diarani kaya "pedoman kontribusi". Kita bakal tetep prasaja lan nambah tes kanggo saben baris ing dhaptar priksa.

Nalika nindakake tugas, coba tindakake tes dhisik. Yen sampeyan nginstal kanthi bener pre-commit pancing sadurungé, test mentas ditambahaké bakal mbukak, gagal, lan boten bakal setya. Elinga yen iki carane kita ngerti tes kita bener-bener nyoba. Sing nggumunake, yen kita miwiti nganggo kode sadurunge tes, lulus tes bisa uga ateges kode kasebut bisa digunakake kaya sing dikarepake, utawa tes kasebut ora bener-bener nguji apa-apa. Kajaba iku, yen kita ora nulis tes kasebut ing wiwitan, kita bisa uga lali babagan kabeh, amarga ora ana sing ngelingake kita.

Test Driven Development (TDD)

TDD nyaranake nulis tes sadurunge kode. Alur kerja khas nggunakake TDD katon kaya iki.

1. Tambah tes.
2. Jalanake kabeh tes lan priksa manawa tes anyar gagal.
3. Tulis kode.
4. Jalanake tes, priksa manawa kabeh tes lulus.
5. Refactor kode sampeyan.
6. Baleni.

Amarga asil tes sing gagal biasane ditampilake kanthi warna abang, lan sing lulus biasane ditampilake kanthi warna ijo, siklus kasebut uga dikenal minangka refactor abang-ijo.

️Tugas

Pisanan, coba tindakake tes lan supaya gagal, banjur tambahake lan tundhuk teks dhaptar langkah CI dhewe. Sampeyan bakal weruh yen tes wis lulus ("ijo").
Banjur nerbitake kode anyar menyang repositori remot lan nonton tes sing ditindakake ing antarmuka GitHub ing sisih ngisor diskusi panyuwunan tarik lan nganyari status PR.

1. Ngalih menyang cabang feature.

2. Tambah tes iki kanggo ci.test.js sawise telpon pungkasan 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. Coba nindakake tes. Yen pre-commit pancing wis diinstal, nyoba tundhuk bakal gagal.
4. Banjur nambah teks iki kanggo 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. Nggawe lan nindakake owah-owahan lokal.
6. Kirim owah-owahan menyang cabang feature.

Sampeyan saiki kudu duwe kaya iki

Tim

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

Gabung konflik

Pindhah menyang Ganti Panjaluk Tinjauan langkah.

Sanajan kita ora nindakake apa-apa sing salah lan tes kanggo kode kita lulus, kita isih ora bisa nggabungake cabang kasebut feature и master. Iku amarga thread liyane bugfix digabung karo master nalika kita nggarap PR iki.
Iki nggawe kahanan ing ngendi cabang remot master wis versi anyar saka siji kita adhedhasar cabang ing feature. Amarga iki kita ora bisa mung mundur HEAD master nganti pungkasaning benang feature. Ing kahanan iki, kita kudu nggabungake utawa ngetrapake komitmen feature rebase master. GitHub bisa nindakake gabungan otomatis yen ora ana konflik. Alas, ing kahanan kita, loro cabang duwe saingan owah-owahan ing file ci.md. Kahanan iki dikenal minangka konflik gabungan, lan kita kudu ngrampungake kanthi manual.

Gabung utawa rebase

Gabung

• Nggawe komit gabungan tambahan lan nyimpen riwayat karya.
  • Ngreksa commits asli cabang karo timestamp asli lan penulis.
  • Nyimpen SHA saka commits lan pranala menyang wong-wong mau ing rembugan panjalukan owah-owahan.
• Mbutuhake resolusi konflik siji-wektu.
• Ndadekake crita non-linear.
  • Crita bisa angel diwaca amarga akeh cabang (kaya kabel IDE).
  • Ndadekake debugging otomatis luwih angel, f.eks. git bisect kurang migunani - mung bakal nemokake komit gabungan.

Rebet maneh

• Replays commit saka cabang saiki ing ndhuwur cabang dhasar siji sawise liyane.
  • Komitmen anyar karo SHA anyar digawe, nyebabake komit ing GitHub cocog karo panjaluk tarik asli, nanging dudu komentar sing cocog.
  • Komit bisa digabung maneh lan diowahi ing proses kasebut, utawa malah digabung dadi siji.
• Akeh konflik bisa uga kudu dirampungake.
• Ngidini sampeyan njaga crita linear.
  • Crita kasebut bisa uga luwih gampang diwaca anggere ora dawa banget tanpa alesan sing cukup.
  • Debugging otomatis lan ngatasi masalah luwih gampang: ndadekake iku bisa git bisect, bisa nggawe rollbacks otomatis luwih cetha lan bisa ditebak.
• Mbutuhake nerbitake cabang kanthi migrasi commit karo gendéra --force nalika digunakake karo panjalukan narik.

Biasane, tim setuju kanggo nggunakake strategi sing padha nalika kudu nggabungake owah-owahan. Iki bisa dadi gabungan "murni" utawa komitmen "murni" ing ndhuwur, utawa ana ing antarane, kayata nindakake komitmen ing ndhuwur kanthi interaktif (git rebase -i) sacara lokal kanggo cabang sing ora diterbitake ing gudang umum, nanging gabung kanggo cabang "umum".

Ing kene kita bakal nggunakake gabungan.

️Tugas

1. Priksa manawa kode kasebut ana ing cabang lokal master dianyari saka repositori remot.
2. Ngalih menyang cabang feature.
3. Miwiti gabungan karo cabang master. Konflik gabungan amarga owah-owahan saingan ing ci.md.
4. Rampungake konflik kasebut supaya dhaptar langkah CI lan cathetan babagan iki tetep ana ing teks.
5. Nerbitake komit gabungan menyang cabang remot feature.
6. Priksa status panjalukan narik ing UI GitHub lan ngenteni nganti gabungan wis ditanggulangi.

Tim

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

proyek apik!

Sampeyan wis rampung karo dhaptar lan saiki sampeyan kudu nyetujoni panjalukan narik ing master.

️ Tugas: Setujui panjalukan tarik "Tinjauan langkah"

1. Bukak panjalukan tarik.
2. Klik "Gabung panjalukan tarik".
3. Klik "Konfirmasi gabung".
4. Klik "Busak cabang" amarga kita ora perlu maneh.

Iki minangka gudang sampeyan saiki

kesalahan produk

Dikandhakake yen "uji coba bisa digunakake kanggo nuduhake anane kesalahan, nanging ora bakal nuduhake anané." Sanajan ana tes lan ora nuduhake kesalahan, ana bug insidious mlebu produksi.

Ing skenario kaya iki, kita kudu ngurus:

• apa sing disebarake ing produksi;
• kode ing thread master karo kesalahan, saka kang gawe bisa miwiti karya anyar.

Apa aku kudu muter maneh utawa ndandani ing versi sabanjure?

Muter maneh yaiku proses nyebarake versi sadurunge sing apik kanggo produksi lan mulihake komitmen sing ngemot kesalahan. "Ndandani maju" minangka tambahan saka fix menyang master lan deploying versi anyar sanalika bisa. Amarga API lan skema database ganti nalika kode disebarake menyang produksi, kanthi pangiriman terus-terusan lan jangkoan tes sing apik, muter maneh biasane luwih angel lan beboyo tinimbang ndandani ing versi sabanjure.

Wiwit muter maneh ora nggawa risiko ing kasus kita, kita bakal pindhah rute iki, amarga ngidini kita

• ndandani kesalahan ing produk sanalika bisa;
• nggawe kode ing master langsung cocok kanggo miwiti proyek anyar.

️Tugas

1. Ngalih menyang cabang master lokal.
2. Nganyari repositori lokal saka repositori remot.
3. Mulihake komit gabungan PR Tinjauan langkah в master.
4. Nerbitake owah-owahan menyang repositori remot.

Iki minangka riwayat repositori kanthi komit gabungan sing dibalekake

Tim

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

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

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

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

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

️ Tes dhewe

Priksa manawa ci.md ora ngemot teks "sneaky bug" maneh sawise mbalekake commit gabungan.

Ndandani dhaptar langkah CI lan bali menyang master

Kita wis mbalekake komit gabungan cabang kasebut. feature. Kabar apik yaiku saiki ora ana kesalahan master. Kabar ala yaiku dhaptar larang regane langkah integrasi sing terus-terusan uga ilang. Dadi, saenipun, kita kudu ngetrapake fix menyang komit saka feature lan bali menyang master bebarengan karo ndandani.

Kita bisa nyedhaki masalah kanthi cara sing beda-beda:

• mbalekake komitmen sing mbatalake gabungan feature с master;
• pamindhahan nindakake saka mantan feature.

Tim pangembangan sing beda-beda nggunakake pendekatan sing beda-beda ing kasus iki, nanging kita bakal mindhah komitmen sing migunani menyang cabang sing kapisah lan nggawe panjaluk tarik sing kapisah kanggo cabang anyar iki.

️Tugas

1. Nggawe thread disebut feature-fix lan pindhah menyang.

2. Migrasi kabeh commit saka cabang mantan feature menyang thread anyar. Rampungake konflik gabungan sing kedadeyan sajrone migrasi.

   

3. Tambah test kemunduran kanggo ci.test.js:

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

4. Jalanake tes lokal kanggo mesthekake yen ora gagal.
5. Mbusak teks "karo bug sneaky" ing ci.md.
6. Tambah owah-owahan tes lan owah-owahan dhaptar langkah menyang indeks lan tundhuk.
7. Nerbitake cabang menyang repositori remot.

Sampeyan kudu mungkasi karo sing padha karo iki:

Tim

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

Nggawe panjalukan narik.

Nggawe panjalukan narik kanthi judhul Ndandani fitur kasebut... Instal feature-fix kaya "cabang sirah" lan master kaya "cabang dhasar".
Mangga ngenteni nalika tes rampung. Sampeyan bisa ndeleng status tes ing ngisor diskusi PR.

Priksa manawa sampeyan wis nginstal master ing kang garpu gudang Minangka "cabang basa", aku ora bakal nanggapi panjalukan kanggo owah-owahan ing gudang bahan kursus.

Setujui panjalukan tarik "Ndandani fitur"

Matur nuwun kanggo koreksi! Mangga sarujuk owah-owahan menyang master saka panjalukan narik.

️Tugas

1. Klik "Gabung panjalukan tarik".
2. Klik "Konfirmasi gabung".
3. Klik "Busak cabang" amarga kita ora perlu maneh.

Iki sing kudu sampeyan lakoni saiki.

Sugeng rawuh!

Sampeyan wis ngrampungake kabeh langkah sing biasane ditindakake wong sajrone integrasi terus-terusan.

Yen sampeyan ngelingi ana masalah karo kursus utawa ngerti carane nambah, mangga nggawe masalah ing repositori karo materi kursus. Kursus iki uga duwe versi interaktif nggunakake GitHub Learning Lab minangka platform.

Source: www.habr.com