Pernahkah anda mempelajari arahan Git tetapi ingin membayangkan bagaimana integrasi berterusan (CI) berfungsi dalam realiti? Atau mungkin anda ingin mengoptimumkan aktiviti harian anda? Kursus ini akan memberi anda kemahiran praktikal dalam penyepaduan berterusan menggunakan repositori GitHub. Kursus ini tidak bertujuan untuk menjadi ahli sihir yang anda boleh klik sahaja; sebaliknya, anda akan melakukan tindakan yang sama yang sebenarnya dilakukan oleh orang di tempat kerja, dengan cara yang sama seperti mereka melakukannya. Saya akan menerangkan teori semasa anda melalui langkah-langkah yang terlibat.

Apa yang kita lakukan?

Semasa kami maju, kami akan membuat senarai langkah CI biasa secara beransur-ansur, yang merupakan cara terbaik untuk mengingati senarai ini. Dalam erti kata lain, kami akan membuat senarai tindakan yang diambil oleh pembangun semasa melakukan penyepaduan berterusan, melakukan penyepaduan berterusan. Kami juga akan menggunakan satu set ujian mudah untuk mendekatkan proses CI kami kepada yang sebenar.

GIF ini secara skematik menunjukkan komitmen dalam repositori anda semasa anda meneruskan kursus. Seperti yang anda lihat, tidak ada yang rumit di sini dan hanya yang paling diperlukan.

Anda akan melalui senario CI standard berikut:

• Bekerja pada ciri;
• Penggunaan ujian automatik untuk memastikan kualiti;
• Pelaksanaan tugas keutamaan;
• Penyelesaian konflik apabila menggabungkan cawangan (menggabungkan konflik);
• Ralat berlaku dalam persekitaran pengeluaran.

Apa yang akan anda pelajari?

Anda akan dapat menjawab soalan berikut:

• Apakah penyepaduan berterusan (CI)?
• Apakah jenis ujian automatik yang digunakan dalam CI, dan sebagai tindak balas kepada tindakan apakah yang dicetuskan?
• Apakah permintaan tarik dan bila ia diperlukan?
• Apakah itu Test Driven Development (TDD) dan bagaimana ia berkaitan dengan CI?
• Patutkah saya menggabungkan atau mengasaskan semula perubahan?
• Balik atau betulkan dalam versi seterusnya?

Pada mulanya saya menterjemah perkara seperti "permintaan tarik" di mana-mana, tetapi akibatnya saya memutuskan untuk mengembalikan frasa dalam bahasa Inggeris di beberapa tempat untuk mengurangkan tahap kegilaan dalam teks. Saya kadangkala akan menggunakan "pengaturcara surzhik" seperti kata kerja yang indah "komit" di mana orang sebenarnya menggunakannya di tempat kerja.

Apakah integrasi berterusan?

Integrasi berterusan, atau CI, ialah amalan teknikal di mana setiap ahli pasukan menyepadukan kod mereka ke dalam repositori biasa sekurang-kurangnya sekali sehari, dan kod yang terhasil mestilah sekurang-kurangnya dibina tanpa ralat.

Terdapat perselisihan pendapat mengenai istilah ini

Titik perbalahan ialah kekerapan integrasi. Ada yang berpendapat bahawa menggabungkan kod hanya sekali sehari tidak mencukupi untuk benar-benar berintegrasi secara berterusan. Satu contoh diberikan tentang pasukan yang semua orang mengambil kod baharu pada waktu pagi dan menyepadukannya sekali pada waktu petang. Walaupun ini adalah bantahan yang munasabah, secara amnya percaya bahawa definisi sekali sehari adalah munasabah praktikal, khusus dan sesuai untuk pasukan dengan saiz yang berbeza.

Bantahan lain ialah C++ bukan lagi satu-satunya bahasa yang digunakan dalam pembangunan, dan hanya memerlukan pemasangan bebas ralat sebagai cara pengesahan adalah lemah. Beberapa set ujian (contohnya, ujian unit dilaksanakan secara tempatan) juga mesti berjaya diselesaikan. Pada masa ini, komuniti sedang bergerak ke arah menjadikan ini sebagai keperluan, dan pada masa hadapan "ujian + unit" mungkin akan menjadi amalan biasa, jika ia belum dilakukan.

Integrasi berterusan berbeza daripada penghantaran berterusan (Penghantaran Berterusan, CD) kerana ia tidak memerlukan calon keluaran selepas setiap kitaran penyepaduan.

Senarai langkah yang akan kami gunakan sepanjang kursus

1. Tarik kod terkini. Buat cawangan daripada master. Mula bekerja.
2. Buat komitmen pada cawangan baharu anda. Bina dan uji secara tempatan. Lulus? Pergi ke langkah seterusnya. gagal? Betulkan ralat atau ujian dan cuba lagi.
3. Tekan ke repositori jauh atau cawangan terpencil anda.
4. Buat permintaan tarik. Bincangkan perubahan, tambahkan lebih banyak komitmen semasa perbincangan diteruskan. Jadikan ujian lulus pada cabang ciri.
5. Gabung/pas semula komit daripada induk. Jadikan ujian lulus pada hasil gabungan.
6. Gunakan daripada cawangan ciri kepada pengeluaran.
7. Jika semuanya baik dalam pengeluaran untuk beberapa tempoh masa, gabungkan perubahan kepada induk.

️ Persediaan

Pastikan anda mempunyai perisian yang betul

Untuk mengambil kursus ini anda perlu Node.js и Pelanggan Git.

Anda boleh menggunakan mana-mana klien Git, tetapi saya hanya akan menyediakan arahan untuk baris arahan.

Pastikan anda memasang klien Git yang menyokong baris arahan

Jika anda belum mempunyai klien Git yang menyokong baris arahan, anda boleh mendapatkan arahan pemasangan di sini.

Sediakan repositori

Anda perlu membuat salinan peribadi (garpu) repositori templat dengan kod untuk kursus pada GitHub. Mari kita bersetuju untuk memanggil salinan peribadi ini repositori kursus.

Selesai? Jika anda belum menukar tetapan lalai, repositori kursus anda kemungkinan besar dipanggil continuous-integration-team-scenarios-students, ia terletak dalam akaun GitHub anda dan URL kelihatan seperti ini

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

Saya hanya akan menghubungi alamat ini <URL репозитория>.

Tanda kurung sudut seperti <тут> bermakna anda mesti menggantikan ungkapan sedemikian dengan nilai yang sesuai.

Pastikan itu Tindakan GitHub disertakan untuk repositori kursus ini. Jika ia tidak didayakan, sila dayakannya dengan mengklik butang besar di tengah halaman, yang boleh anda capai dengan mengklik Tindakan dalam antara muka GitHub.

Anda tidak akan dapat melengkapkan kursus mengikut arahan saya jika Tindakan GitHub tidak didayakan.

Anda sentiasa boleh menggunakan keupayaan GitHub untuk memberikan Markdown untuk melihat keadaan semasa senarai yang kami karang di sini

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

Mengenai jawapan

Walaupun cara terbaik untuk menyelesaikan kursus ini ialah melakukannya sendiri, anda mungkin menghadapi beberapa kesukaran.

Jika anda rasa anda tidak faham apa yang perlu dilakukan dan tidak boleh meneruskan, anda boleh melihat ke dalam urutan solution, yang terdapat dalam repositori permulaan anda.
Tolong jangan gabung solution в master semasa kursus. Anda boleh menggunakan cawangan ini untuk memikirkan perkara yang perlu dilakukan, atau membandingkan kod anda dengan kod pengarang, menggunakan semua keupayaan yang Git berikan kepada kami. Jika anda hilang sepenuhnya, anda boleh menggantikan sepenuhnya cawangan anda master pada dahan solution dan kemudian tetapkan semula direktori kerja anda kepada langkah kursus yang anda perlukan.

Hanya gunakan ini jika anda benar-benar memerlukannya

Serahkan kod anda

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

Perintah-perintah ini

• menamakan semula master в master-backup;
• menamakan semula solution в master;
• daftar keluar ke cawangan baharu master dan tulis semula kandungan direktori kerja;
• Cipta cawangan "penyelesaian" daripada "master" (yang dahulunya "penyelesaian") sekiranya anda memerlukan cawangan "penyelesaian" pada masa hadapan.

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

Selepas langkah ini anda boleh gunakan git log master untuk mengetahui komitmen yang anda perlukan.
Anda boleh menetapkan semula direktori kerja anda kepada komit ini seperti ini:

git reset --hard <the SHA you need>

Jika anda berpuas hati dengan hasilnya, pada satu ketika anda perlu menerbitkan versi repositori anda ke repositori jauh. Jangan lupa untuk menyatakan secara eksplisit cawangan jauh apabila anda melakukan ini.

git push --force origin master

Sila ambil perhatian bahawa kami menggunakan git push --force. Tidak mungkin anda ingin melakukan ini dengan kerap, tetapi kami mempunyai senario yang sangat khusus di sini dengan seorang pengguna repositori yang, di samping itu, memahami apa yang dia lakukan.

Mula bekerja

Mari mulakan menyusun senarai langkah CI kami. Biasanya anda akan memulakan langkah ini dengan menyemak versi terkini kod daripada repositori jauh, tetapi kami belum mempunyai repositori tempatan lagi, jadi kami mengklonkannya daripada repositori jauh.

️ Tugas: kemas kini repositori tempatan, buat cawangan daripada master, mula bekerja

1. Klon repositori kursus daripada <URL репозитория>.
2. Lari npm install dalam direktori repositori kursus; Kami memerlukannya untuk memasang Jest, yang kami gunakan untuk menjalankan ujian.
3. Buat cawangan dan namakannya feature. Beralih ke benang ini.

4. Tambahkan kod ujian ke ci.test.js antara komen yang meminta saya melakukan ini.

   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. Tambahkan teks dengan 4 langkah pertama pada fail 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.  

   Pasukan

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

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

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

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

Buat komitmen pada cawangan baharu, bina dan uji secara setempat

Kami akan menyediakan ujian untuk dijalankan sebelum melakukan, dan kemudian melakukan kod.

Senario biasa apabila ujian dijalankan secara automatik

• Secara tempatan:
  • Secara berterusan atau sebagai tindak balas kepada perubahan kod yang sesuai;
  • Semasa menyimpan (untuk bahasa yang ditafsir atau yang disusun JIT);
  • Semasa pemasangan (apabila penyusunan diperlukan);
  • Atas komitmen;
  • Apabila menerbitkan ke repositori kongsi.

• Pada pelayan binaan atau persekitaran binaan:
  • Apabila kod diterbitkan ke cawangan/repositori peribadi.
  • Kod dalam urutan ini sedang diuji.
  • Hasil potensi penggabungan diuji (biasanya dengan master).
  • Sebagai peringkat integrasi berterusan/saluran paip penghantaran berterusan

Biasanya, lebih cepat suite ujian berjalan, lebih kerap anda mampu menjalankannya. Pengedaran peringkat biasa mungkin kelihatan seperti ini.

• Ujian unit pantas - semasa pembinaan, dalam saluran paip CI
• Ujian unit perlahan, komponen pantas dan ujian integrasi - atas komitmen, dalam saluran paip CI
• Ujian komponen dan penyepaduan perlahan - dalam saluran paip CI
• Ujian keselamatan, ujian beban dan ujian lain yang memakan masa atau mahal - dalam saluran paip CI/CD, tetapi hanya dalam mod/peringkat/saluran paip tertentu bagi binaan, contohnya, semasa menyediakan calon keluaran atau semasa berjalan secara manual.

️Tugas

Saya cadangkan menjalankan ujian secara manual terlebih dahulu menggunakan arahan npm test. Selepas itu, mari tambah cangkuk git untuk menjalankan ujian kami pada komit. Terdapat satu tangkapan: Cangkuk Git tidak dianggap sebagai sebahagian daripada repositori dan oleh itu tidak boleh diklon daripada GitHub bersama-sama dengan bahan kursus yang lain. Untuk memasang cangkuk anda perlu lari install_hook.sh atau salin fail repo/hooks/pre-commit ke direktori tempatan .git/hooks/.
Apabila anda komited, anda akan melihat bahawa ujian dijalankan dan mereka menyemak untuk melihat sama ada kata kunci tertentu terdapat dalam senarai.

1. Jalankan ujian secara manual dengan menjalankan arahan npm test dalam folder repositori kursus anda. Sahkan bahawa ujian telah selesai.
2. Tetapkan cangkuk komit (cangkuk pra-komit) dengan berlari install_hook.sh.
3. Serahkan perubahan anda pada repositori tempatan anda.
4. Pastikan ujian dijalankan sebelum melakukan.

Repositori anda sepatutnya kelihatan seperti ini selepas mengikuti langkah-langkah ini.

Pasukan

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

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

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

Terbitkan kod ke repositori jauh atau cawangan jauh

Sebaik sahaja mereka selesai bekerja secara tempatan, pembangun biasanya menyediakan kod mereka secara terbuka supaya ia akhirnya boleh disepadukan dengan orang ramai. Dengan GitHub, ini biasanya dicapai dengan menerbitkan karya sama ada kepada salinan peribadi repositori (garpu peribadi) atau cawangan peribadi.

• Dengan garpu, pembangun mengklonkan repositori kongsi jauh, mencipta salinan jauh peribadinya, juga dikenali sebagai garpu. Ia kemudian mengklonkan repositori peribadi ini untuk berfungsi secara tempatan. Apabila kerja selesai dan komitmen dibuat, dia menolaknya ke dalam garpunya, di mana ia tersedia untuk orang lain dan boleh disepadukan ke dalam repositori biasa. Pendekatan ini biasanya digunakan dalam projek sumber terbuka pada GitHub. Ia juga digunakan dalam kursus lanjutan saya [Kerja Berpasukan dan CI dengan Git] (http://devops.redpill.solutions/).
• Pendekatan lain ialah menggunakan hanya satu repositori jauh dan hanya mengira cawangan master repositori kongsi "dilindungi". Dalam senario ini, pembangun individu menerbitkan kod mereka ke cawangan repositori jauh supaya orang lain boleh melihat kod ini, jika semuanya teratur, gabungkannya dengan master repositori kongsi.

Dalam kursus khusus ini, kami akan menggunakan aliran kerja yang menggunakan cawangan.

Mari terbitkan kod kami.

️Tugas

• Terbitkan perubahan pada cawangan jauh dengan nama yang sama dengan cawangan kerja anda

Pasukan

git push --set-upstream origin feature

Buat permintaan tarik

Buat permintaan tarik dengan tajuk Semakan langkah. Pasang feature seperti "cabang kepala" dan master seperti "cawangan asas".

Pastikan anda telah memasang master dalam dia garpu repositori Sebagai "cawangan asas", saya tidak akan menjawab permintaan untuk perubahan kepada repositori bahan kursus.

Dalam bahasa GitHub, "cawangan asas" ialah cawangan yang anda asaskan kerja anda dan "cawangan kepala" ialah cawangan yang mengandungi perubahan yang dicadangkan.

Bincangkan perubahan, tambah komitmen baharu semasa perbincangan diteruskan

Permintaan tarik (PR)

Permintaan tarik (PR) ialah satu cara untuk membincangkan dan mendokumentasikan kod, serta menjalankan semakan kod. Permintaan tarik dinamakan sempena cara umum menyepadukan perubahan individu ke dalam kod keseluruhan. Biasanya, seseorang mengklon repositori rasmi jauh projek dan bekerja pada kod secara tempatan. Selepas ini, dia meletakkan kod dalam repositori jauh peribadinya dan meminta mereka yang bertanggungjawab untuk repositori rasmi untuk mengambil(tarik) kodnya ke dalam repositori tempatan mereka, tempat mereka menyemak dan mungkin menyepadukan(bergabung) miliknya. Konsep ini juga dikenali dengan nama lain, contohnya, permintaan gabungan.

Anda sebenarnya tidak perlu menggunakan ciri permintaan tarik GitHub atau platform yang serupa. Pasukan pembangunan mungkin menggunakan kaedah komunikasi lain, termasuk komunikasi bersemuka, panggilan suara atau e-mel, tetapi masih terdapat beberapa sebab untuk menggunakan permintaan tarik gaya forum. Berikut adalah sebahagian daripada mereka:

• perbincangan yang teratur berkaitan dengan perubahan kod tertentu;
• sebagai tempat untuk melihat maklum balas tentang kerja dalam proses daripada penguji automatik dan rakan sebaya;
• pemformalan ulasan kod;
• supaya kemudian anda boleh mengetahui sebab dan pertimbangan di sebalik sekeping kod ini atau itu.

Biasanya anda membuat permintaan tarik apabila anda perlu membincangkan sesuatu atau mendapatkan maklum balas. Contohnya, jika anda sedang mengusahakan ciri yang boleh dilaksanakan dalam lebih daripada satu cara, anda boleh membuat permintaan tarik sebelum menulis baris pertama kod untuk berkongsi idea anda dan membincangkan rancangan anda dengan rakan usaha sama anda. Jika kerja lebih mudah, permintaan tarik dibuka apabila sesuatu telah dilakukan, komited dan boleh dibincangkan. Dalam sesetengah senario, anda mungkin mahu membuka PR hanya atas sebab kawalan kualiti: untuk menjalankan ujian automatik atau memulakan semakan kod. Apa sahaja keputusan anda, jangan lupa untuk @mention orang yang anda inginkan kelulusan dalam permintaan tarik anda.

Biasanya, semasa membuat PR, anda melakukan perkara berikut.

• Nyatakan perkara yang anda cadangkan untuk diubah dan di mana.
• Tulis huraian yang menerangkan tujuan perubahan. Anda mungkin mahu:
  • tambahkan apa-apa perkara penting yang tidak jelas daripada kod, atau sesuatu yang berguna untuk memahami konteks, seperti #bugs yang berkaitan dan nombor komit;
  • @sebutkan sesiapa sahaja yang anda mahu mula bekerja dengannya, atau anda boleh @sebutkan mereka dalam ulasan kemudian;
  • minta rakan sekerja membantu dengan sesuatu atau menyemak sesuatu yang khusus.

Sebaik sahaja anda membuka PR, ujian yang dikonfigurasikan untuk dijalankan dalam kes sedemikian dilaksanakan. Dalam kes kami, ini akan menjadi set ujian yang sama yang kami jalankan secara tempatan, tetapi dalam projek sebenar mungkin terdapat ujian dan semakan tambahan.

Sila tunggu sementara ujian selesai. Anda boleh melihat status ujian di bahagian bawah perbincangan PR dalam antara muka GitHub. Teruskan apabila ujian selesai.

️ Tambah nota tentang rawak senarai langkah CI

Senarai yang digunakan dalam kursus ini adalah sewenang-wenangnya dan subjektif, kita harus menambah nota tentang perkara ini.

️ Tugasan: buat permintaan tarik untuk ulasan ini

1. Tukar kepada cawangan master.
2. Buat cawangan bernama bugfix.
3. Tambahkan teks nota pada penghujung fail 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. Lakukan perubahan.
5. Terbitkan benang bugfix ke repositori jauh.
6. Buat permintaan tarik bernama Menambah teguran dengan dahan kepala bugfix dan cabang asasmaster.

Pastikan anda telah memasang master dalam dia garpu repositori Sebagai "cawangan asas", saya tidak akan menjawab permintaan untuk perubahan kepada repositori bahan kursus.

Beginilah rupa repositori anda.

Pasukan

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

Luluskan permintaan tarik "Menambah kenyataan"

️Tugas

1. Buat permintaan tarik.
2. Klik "Gabungkan permintaan tarik".
3. Klik "Sahkan penggabungan".
4. Klik "Padam cawangan", kami tidak memerlukannya lagi.

Ini ialah gambar rajah komit selepas penggabungan.

️ Teruskan bekerja dan menambah ujian

Bekerjasama dalam permintaan tarik selalunya menghasilkan kerja tambahan. Ini biasanya hasil semakan kod atau perbincangan, tetapi dalam kursus kami, kami akan memodelkan ini dengan menambahkan item baharu pada senarai langkah CI kami.

Penyepaduan berterusan biasanya melibatkan beberapa liputan ujian. Keperluan perlindungan ujian berbeza-beza dan biasanya ditemui dalam dokumen yang dipanggil sesuatu seperti "garis panduan sumbangan". Kami akan memastikannya mudah dan menambah ujian untuk setiap baris dalam senarai semak kami.

Semasa menjalankan tugasan, cuba lakukan ujian dahulu. Jika anda memasang dengan betul pre-commit cangkuk lebih awal, ujian yang baru ditambah akan dijalankan, akan gagal, dan tiada apa yang akan dilakukan. Ambil perhatian bahawa ini adalah cara kami mengetahui ujian kami sebenarnya menguji sesuatu. Menariknya, jika kita mula menggunakan kod sebelum ujian, lulus ujian sama ada bermakna kod itu berfungsi seperti yang diharapkan atau ujian itu sebenarnya tidak menguji apa-apa. Selain itu, jika kita tidak menulis ujian itu pada mulanya, kita mungkin akan melupakannya sama sekali, kerana tiada apa yang akan mengingatkan kita tentangnya.

Pembangunan Dipacu Ujian (TDD)

TDD mengesyorkan menulis ujian sebelum kod. Aliran kerja biasa menggunakan TDD kelihatan seperti ini.

1. Tambah ujian.
2. Jalankan semua ujian dan pastikan ujian baharu gagal.
3. Tulis kod.
4. Jalankan ujian, pastikan semua ujian lulus.
5. Faktorkan semula kod anda.
6. ulang.

Oleh kerana keputusan ujian yang gagal biasanya ditunjukkan dalam warna merah, dan yang lulus biasanya ditunjukkan dalam warna hijau, kitaran juga dikenali sebagai refactor merah-hijau.

️Tugas

Mula-mula, cuba lakukan ujian dan biarkan ujian itu gagal, kemudian tambah dan komit teks senarai langkah CI itu sendiri. Anda akan melihat bahawa ujian lulus ("hijau").
Kemudian terbitkan kod baharu ke repositori jauh dan tonton ujian dijalankan dalam antara muka GitHub di bahagian bawah perbincangan permintaan tarik dan kemas kini status PR.

1. Tukar kepada cawangan feature.

2. Tambahkan ujian ini kepada ci.test.js selepas panggilan terakhir 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. Cuba lakukan ujian. Jika pre-commit cangkuk dipasang, percubaan komit akan gagal.
4. Kemudian tambahkan teks ini ke 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. Buat dan lakukan perubahan secara setempat.
6. Siarkan perubahan pada cawangan feature.

Anda kini sepatutnya mempunyai sesuatu seperti ini

Pasukan

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

Gabungkan konflik

Pergi ke Permintaan Tukar Semakan langkah.

Walaupun kami tidak melakukan apa-apa kesalahan dan ujian untuk kod kami lulus, kami masih tidak boleh menggabungkan cawangan feature и master. Ini kerana benang lain bugfix telah digabungkan dengan master semasa kami mengusahakan PR ini.
Ini mewujudkan keadaan di mana cawangan jauh master mempunyai versi yang lebih baharu daripada yang kami asaskan cawangan itu feature. Kerana ini kita tidak boleh undur KEPALA sahaja master hingga ke hujung benang feature. Dalam keadaan ini, kita perlu sama ada menggabungkan atau menggunakan komitmen feature rebase master. GitHub sebenarnya boleh melakukan cantuman automatik jika tiada konflik. Malangnya, dalam situasi kami, kedua-dua cawangan mempunyai perubahan yang bersaing dalam fail ci.md. Keadaan ini dikenali sebagai konflik gabungan, dan kita perlu menyelesaikannya secara manual.

Gabung atau asas semula

Bergabung

• Mencipta komitmen gabungan tambahan dan menyimpan sejarah kerja.
  • Mengekalkan komitmen asal cawangan dengan cap masa dan pengarang asalnya.
  • Menyimpan SHA komit dan pautan kepada mereka dalam perbincangan permintaan perubahan.
• Memerlukan penyelesaian konflik sekali sahaja.
• Menjadikan cerita tidak linear.
  • Cerita ini boleh menjadi sukar untuk dibaca kerana bilangan cawangan yang banyak (mengingatkan kabel IDE).
  • Menjadikan penyahpepijatan automatik lebih sukar, mis. git bisect kurang berguna - ia hanya akan menemui komit gabungan.

Rebat

• Main semula komit dari cawangan semasa di atas cawangan asas satu demi satu.
  • Komit baharu dengan SHA baharu dijana, menyebabkan komit dalam GitHub sepadan dengan permintaan tarik asal, tetapi bukan ulasan yang sepadan.
  • Komit boleh digabungkan semula dan diubah suai dalam proses, atau bahkan digabungkan menjadi satu.
• Pelbagai konflik mungkin perlu diselesaikan.
• Membolehkan anda mengekalkan cerita linear.
  • Cerita itu mungkin lebih mudah dibaca asalkan tidak terlalu panjang tanpa sebab yang munasabah.
  • Penyahpepijatan automatik dan penyelesaian masalah sedikit lebih mudah: menjadikannya mungkin git bisect, boleh menjadikan pemulangan automatik lebih jelas dan lebih mudah diramal.
• Memerlukan penerbitan cawangan dengan komitmen berhijrah dengan bendera --force apabila digunakan dengan permintaan tarik.

Biasanya, pasukan bersetuju untuk sentiasa menggunakan strategi yang sama apabila mereka perlu menggabungkan perubahan. Ini boleh menjadi gabungan "tulen" atau komit "tulen" di atas, atau sesuatu di antaranya, seperti melakukan komit di atas secara interaktif(git rebase -i) secara tempatan untuk cawangan yang tidak diterbitkan ke repositori awam, tetapi bergabung untuk cawangan "awam".

Di sini kita akan menggunakan gabungan.

️Tugas

1. Pastikan kod berada dalam cawangan tempatan master dikemas kini daripada repositori jauh.
2. Tukar kepada cawangan feature.
3. Mulakan gabungan dengan cawangan master. Konflik gabungan disebabkan oleh perubahan yang bersaing pada ci.md.
4. Selesaikan konflik supaya kedua-dua senarai langkah CI kami dan nota mengenainya kekal dalam teks.
5. Terbitkan komit gabungan ke cawangan jauh feature.
6. Semak status permintaan tarik dalam UI GitHub dan tunggu sehingga penggabungan diselesaikan.

Pasukan

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

Bagus!

Anda telah selesai dengan senarai dan kini anda perlu meluluskan permintaan tarik masuk master.

️ Tugas: Luluskan permintaan tarik "Semakan langkah"

1. Buka permintaan tarik.
2. Klik "Gabungkan permintaan tarik".
3. Klik "Sahkan penggabungan".
4. Klik "Padam cawangan" kerana kami tidak lagi memerlukannya.

Ini adalah repositori anda pada masa ini

Ralat produk

Dikatakan bahawa "ujian boleh digunakan untuk menunjukkan kehadiran ralat, tetapi tidak pernah menunjukkan ketiadaannya." Walaupun kami mempunyai ujian dan mereka tidak menunjukkan ralat kepada kami, pepijat berbahaya menyelinap ke dalam pengeluaran.

Dalam senario seperti ini, kita perlu menjaga:

• apa yang digunakan dalam pengeluaran;
• kod dalam benang master dengan ralat, dari mana pembangun boleh memulakan kerja baharu.

Patutkah saya berpatah balik atau membetulkannya dalam versi seterusnya?

Memundurkan semula ialah proses menggunakan versi terdahulu yang diketahui baik kepada pengeluaran dan mengembalikan komitmen yang mengandungi ralat. "Membetulkan ke hadapan" ialah penambahan pembetulan pada master dan menggunakan versi baharu secepat mungkin. Oleh kerana API dan skema pangkalan data berubah apabila kod digunakan untuk pengeluaran, dengan penghantaran berterusan dan liputan ujian yang baik, pemulangan semula biasanya jauh lebih sukar dan berisiko daripada membetulkannya dalam versi seterusnya.

Memandangkan berpatah balik tidak membawa sebarang risiko dalam kes kami, kami akan pergi ke laluan ini, kerana ia membolehkan kami

• betulkan ralat pada produk secepat mungkin;
• buat kod masuk master segera sesuai untuk memulakan kerja baru.

️Tugas

1. Tukar kepada cawangan master tempatan.
2. Kemas kini repositori tempatan dari repositori jauh.
3. Kembalikan komitmen gabungan PR Semakan langkah в master.
4. Terbitkan perubahan pada repositori jauh.

Ini ialah sejarah repositori dengan komit gabungan dibalikkan

Pasukan

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

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

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

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

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

️ Ujian kendiri

Pastikan bahawa ci.md tidak lagi mengandungi teks "pepijat licik" selepas mengembalikan komit gabungan.

Betulkan senarai langkah CI dan kembalikan kepada induk

Kami telah mengembalikan sepenuhnya komit gabungan cawangan. feature. Berita baiknya ialah kita kini tidak mempunyai kesilapan master. Berita buruknya ialah senarai langkah penyepaduan berterusan kami yang berharga juga telah hilang. Jadi, sebaik-baiknya, kita perlu menggunakan pembetulan pada komit dari feature dan mengembalikannya kepada master bersama dengan pembaikan.

Kita boleh mendekati masalah dengan cara yang berbeza:

• kembalikan komit yang membatalkan gabungan feature с master;
• bergerak melakukan daripada bekas feature.

Pasukan pembangunan yang berbeza menggunakan pendekatan yang berbeza dalam kes ini, tetapi kami akan memindahkan komitmen berguna ke cawangan yang berasingan dan membuat permintaan tarik yang berasingan untuk cawangan baharu ini.

️Tugas

1. Buat benang dipanggil feature-fix dan beralih kepadanya.

2. Pindahkan semua komitmen dari cawangan bekas feature ke benang baru. Selesaikan konflik gabungan yang berlaku semasa penghijrahan.

   

3. Tambah ujian regresi ke ci.test.js:

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

4. Jalankan ujian secara tempatan untuk memastikan ia tidak gagal.
5. Alih keluar teks "dengan pepijat licik" masuk ci.md.
6. Tambahkan perubahan ujian dan perubahan senarai langkah pada indeks dan lakukannya.
7. Terbitkan cawangan ke repositori jauh.

Anda sepatutnya berakhir dengan sesuatu yang serupa dengan ini:

Pasukan

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

Buat permintaan tarik.

Buat permintaan tarik dengan tajuk Memperbaiki ciri. Pasang feature-fix seperti "cabang kepala" dan master seperti "cawangan asas".
Sila tunggu sementara ujian selesai. Anda boleh melihat status ujian di bahagian bawah perbincangan PR.

Pastikan anda telah memasang master dalam dia garpu repositori Sebagai "cawangan asas", saya tidak akan menjawab permintaan untuk perubahan kepada repositori bahan kursus.

Luluskan permintaan tarik "Memperbaiki ciri"

Terima kasih atas pembetulan! Sila luluskan perubahan kepada master daripada permintaan tarik.

️Tugas

1. Klik "Gabungkan permintaan tarik".
2. Klik "Sahkan penggabungan".
3. Klik "Padam cawangan" kerana kami tidak lagi memerlukannya.

Inilah yang sepatutnya anda miliki pada masa ini.

tahniah!

Anda telah menyelesaikan semua langkah yang biasanya diambil oleh orang semasa penyepaduan berterusan.

Jika anda melihat sebarang masalah dengan kursus atau tahu cara untuk memperbaikinya, sila buat isu dalam repositori dengan bahan kursus. Kursus ini juga mempunyai versi interaktif menggunakan GitHub Learning Lab sebagai platform.

Sumber: www.habr.com