តើអ្នកបានរៀនពាក្យបញ្ជា Git ប៉ុន្តែចង់ស្រមៃមើលថាតើការរួមបញ្ចូលជាបន្តបន្ទាប់ (CI) ដំណើរការនៅក្នុងការពិតដែរឬទេ? ឬប្រហែលជាអ្នកចង់បង្កើនប្រសិទ្ធភាពសកម្មភាពប្រចាំថ្ងៃរបស់អ្នក? វគ្គសិក្សានេះនឹងផ្តល់ឱ្យអ្នកនូវជំនាញជាក់ស្តែងក្នុងការរួមបញ្ចូលជាបន្តបន្ទាប់ដោយប្រើឃ្លាំង GitHub ។ វគ្គសិក្សានេះមិនមានបំណងក្លាយជាអ្នកជំនួយការដែលអ្នកអាចចុចបាននោះទេ ផ្ទុយទៅវិញ អ្នកនឹងអនុវត្តសកម្មភាពដូចគ្នាដែលមនុស្សពិតជាធ្វើនៅកន្លែងធ្វើការ តាមរបៀបដូចគ្នាដែលពួកគេធ្វើវា។ ខ្ញុំ​នឹង​ពន្យល់​ពី​ទ្រឹស្ដី​ដូច​ដែល​អ្នក​ឆ្លង​កាត់​ជំហាន​ដែល​ពាក់ព័ន្ធ។

តើ​យើង​ធ្វើអ្វី?

នៅពេលដែលយើងរីកចម្រើន យើងនឹងបង្កើតជាបណ្តើរៗនូវបញ្ជីនៃជំហាន CI ធម្មតា ដែលជាវិធីដ៏ល្អក្នុងការចងចាំបញ្ជីនេះ។ ម្យ៉ាងវិញទៀត យើងនឹងបង្កើតបញ្ជីសកម្មភាពដែលអ្នកអភិវឌ្ឍន៍ធ្វើ ខណៈពេលដែលធ្វើសមាហរណកម្មបន្ត ធ្វើសមាហរណកម្មបន្ត។ យើងក៏នឹងប្រើសំណុំតេស្តសាមញ្ញ ដើម្បីនាំដំណើរការ CI របស់យើងខិតទៅជិតភាពពិត។

GIF នេះបង្ហាញពីការប្តេជ្ញាចិត្តនៅក្នុងឃ្លាំងរបស់អ្នក នៅពេលអ្នកដំណើរការវគ្គសិក្សា។ ដូចដែលអ្នកអាចមើលឃើញមិនមានអ្វីស្មុគស្មាញនៅទីនេះទេហើយមានតែអ្វីដែលចាំបាច់បំផុត។

អ្នកនឹងឆ្លងកាត់សេណារីយ៉ូ CI ស្តង់ដារខាងក្រោម៖

• ធ្វើការលើមុខងារមួយ;
• ការអនុវត្តការធ្វើតេស្តដោយស្វ័យប្រវត្តិដើម្បីធានាគុណភាព;
• ការអនុវត្តការងារអាទិភាព;
• ការ​ដោះស្រាយ​ជម្លោះ​ពេល​ដែល​ការ​ច្របាច់​បញ្ចូល​គ្នា​នៃ​មែកធាង (បញ្ចូលគ្នា​ជម្លោះ);
• កំហុសកើតឡើងនៅក្នុងបរិយាកាសផលិតកម្ម។

តើអ្នកនឹងរៀនអ្វីខ្លះ?

អ្នកនឹងអាចឆ្លើយសំណួរខាងក្រោម៖

• តើសមាហរណកម្មបន្ត (CI) ជាអ្វី?
• តើការធ្វើតេស្តស្វ័យប្រវត្តិប្រភេទណាខ្លះដែលត្រូវបានប្រើនៅក្នុង CI ហើយដើម្បីឆ្លើយតបទៅនឹងសកម្មភាពអ្វីខ្លះដែលពួកគេត្រូវបានបង្កឡើង?
• តើ​អ្វី​ទៅ​ជា​សំណើ​ទាញ​យក ហើយ​តើ​វា​ត្រូវ​ការ​នៅ​ពេល​ណា?
• អ្វីទៅជា Test Driven Development (TDD) ហើយតើវាទាក់ទងនឹង CI យ៉ាងដូចម្តេច?
• តើ​ខ្ញុំ​គួរ​ដាក់​បញ្ចូល​គ្នា ឬ​បង្កើត​ការ​ផ្លាស់​ប្តូរ​ឡើង​វិញ?
• ត្រឡប់ ឬជួសជុលក្នុងកំណែបន្ទាប់?

ដំបូង​ឡើយ ខ្ញុំ​បាន​បកប្រែ​រឿង​ដូចជា “ទាញ​សំណើ” គ្រប់​ទីកន្លែង ប៉ុន្តែ​ជា​លទ្ធផល ខ្ញុំ​បាន​សម្រេច​ចិត្ត​ត្រឡប់​ឃ្លា​ជា​ភាសា​អង់គ្លេស​នៅ​កន្លែង​ខ្លះ ដើម្បី​កាត់​បន្ថយ​កម្រិត​នៃ​ការ​ឆ្កួត​ក្នុង​អត្ថបទ។ ពេលខ្លះខ្ញុំនឹងប្រើ "programmer surzhik" ដូចជាកិរិយាសព្ទដ៏អស្ចារ្យ "commit" ដែលមនុស្សពិតជាប្រើវានៅកន្លែងធ្វើការ។

តើសមាហរណកម្មបន្តគឺជាអ្វី?

ការរួមបញ្ចូលជាបន្តបន្ទាប់ឬ CI គឺជាការអនុវត្តបច្ចេកទេសដែលសមាជិកក្រុមនីមួយៗបញ្ចូលកូដរបស់ពួកគេទៅក្នុងឃ្លាំងទូទៅយ៉ាងហោចណាស់ម្តងក្នុងមួយថ្ងៃ ហើយកូដលទ្ធផលយ៉ាងហោចណាស់ត្រូវតែត្រូវបានបង្កើតដោយគ្មានកំហុស។

មានការខ្វែងគំនិតគ្នាអំពីពាក្យនេះ។

ចំណុចនៃការឈ្លោះប្រកែកគ្នាគឺភាពញឹកញាប់នៃការរួមបញ្ចូល។ អ្នកខ្លះប្រកែកថាការបញ្ចូលកូដតែមួយដងក្នុងមួយថ្ងៃគឺមិនគ្រប់គ្រាន់ទេក្នុងការរួមបញ្ចូលជាបន្តបន្ទាប់។ ឧទាហរណ៍មួយត្រូវបានផ្តល់ឱ្យក្រុមដែលមនុស្សគ្រប់គ្នាយកកូដថ្មីៗនៅពេលព្រឹក ហើយបញ្ចូលវាម្តងនៅពេលល្ងាច។ ខណៈពេលដែលនេះគឺជាការជំទាស់ដ៏សមហេតុសមផល ជាទូទៅគេជឿថានិយមន័យម្តងក្នុងមួយថ្ងៃគឺសមហេតុផលជាក់ស្តែង ជាក់លាក់ និងសមរម្យសម្រាប់ក្រុមដែលមានទំហំខុសៗគ្នា។

ការជំទាស់មួយទៀតគឺថា C ++ មិនមែនជាភាសាតែមួយគត់ដែលត្រូវបានប្រើប្រាស់ក្នុងការអភិវឌ្ឍន៍នោះទេ ហើយគ្រាន់តែទាមទារការជួបប្រជុំគ្នាដោយគ្មានកំហុសជាមធ្យោបាយនៃសុពលភាពគឺខ្សោយ។ សំណុំនៃការធ្វើតេស្តមួយចំនួន (ឧទាហរណ៍ ការធ្វើតេស្តឯកតាដែលបានប្រតិបត្តិក្នុងមូលដ្ឋាន) ក៏ត្រូវតែបញ្ចប់ដោយជោគជ័យផងដែរ។ នៅពេលនេះ សហគមន៍កំពុងឆ្ពោះទៅរកការធ្វើឱ្យនេះជាតម្រូវការ ហើយនៅពេលអនាគត "ការធ្វើតេស្តសាងសង់ + ឯកតា" ប្រហែលជានឹងក្លាយទៅជាការអនុវត្តធម្មតា ប្រសិនបើមិនទាន់មាន។

ការរួមបញ្ចូលជាបន្តបន្ទាប់ ខុសគ្នាពី ការចែកចាយបន្ត (ការចែកចាយបន្ត, ស៊ីឌី) នៅក្នុងនោះវាមិនតម្រូវឱ្យមានបេក្ខជនចេញផ្សាយបន្ទាប់ពីវដ្តនៃការរួមបញ្ចូលនីមួយៗ។

បញ្ជីនៃជំហានដែលយើងនឹងប្រើពេញមួយវគ្គ

1. ទាញលេខកូដចុងក្រោយ។ បង្កើតសាខាពី master. ចាប់​ផ្តើ​ម​ធ្វើ​ការងារ។
2. បង្កើតការសន្យានៅលើសាខាថ្មីរបស់អ្នក។ សាងសង់និងសាកល្បងក្នុងស្រុក។ ឆ្លងកាត់? ទៅជំហានបន្ទាប់។ បរាជ័យ? ជួសជុលកំហុស ឬការធ្វើតេស្ត ហើយព្យាយាមម្តងទៀត។
3. រុញទៅឃ្លាំងពីចម្ងាយ ឬសាខាពីចម្ងាយរបស់អ្នក។
4. បង្កើតសំណើរទាញ។ ពិភាក្សាអំពីការផ្លាស់ប្តូរ បន្ថែមការប្តេជ្ញាចិត្តបន្ថែមទៀត នៅពេលដែលការពិភាក្សាបន្ត។ ធ្វើ​ឱ្យ​ការ​ធ្វើ​តេ​ស្ត​ឆ្លង​ទៅ​លើ​សាខា​លក្ខណៈ​ពិសេស​។
5. ការរួមបញ្ចូលគ្នា / មូលដ្ឋានឡើងវិញធ្វើឡើងពីមេ។ ធ្វើឱ្យការធ្វើតេស្តឆ្លងកាត់លទ្ធផលបញ្ចូលគ្នា។
6. ដាក់ពង្រាយពីផ្នែកលក្ខណៈពិសេសទៅផលិតកម្ម។
7. ប្រសិនបើអ្វីៗគ្រប់យ៉ាងល្អក្នុងផលិតកម្មក្នុងរយៈពេលណាមួយ សូមបញ្ចូលការផ្លាស់ប្តូរទៅជាមេ។

️ ការរៀបចំ

ត្រូវប្រាកដថាអ្នកមានកម្មវិធីត្រឹមត្រូវ។

ដើម្បីទទួលយកវគ្គសិក្សានេះអ្នកនឹងត្រូវការ Node.js и អតិថិជន Git.

អ្នកអាចប្រើម៉ាស៊ីនភ្ញៀវ Git ណាមួយបាន ប៉ុន្តែខ្ញុំនឹងផ្តល់តែពាក្យបញ្ជាសម្រាប់បន្ទាត់ពាក្យបញ្ជាប៉ុណ្ណោះ។

ត្រូវប្រាកដថាអ្នកបានដំឡើងកម្មវិធី Git ដែលគាំទ្របន្ទាត់ពាក្យបញ្ជា

ប្រសិនបើអ្នកមិនទាន់មានម៉ាស៊ីនភ្ញៀវ Git ដែលគាំទ្របន្ទាត់ពាក្យបញ្ជាទេ អ្នកអាចស្វែងរកការណែនាំអំពីការដំឡើង នៅទីនេះ.

រៀបចំឃ្លាំង

អ្នកនឹងត្រូវបង្កើតច្បាប់ចម្លងផ្ទាល់ខ្លួន (fork) ឃ្លាំងគំរូដែលមានលេខកូដសម្រាប់វគ្គសិក្សា នៅលើ GitHub ។ ចូរយើងយល់ព្រមហៅច្បាប់ចម្លងផ្ទាល់ខ្លួននេះ។ ឃ្លាំងវគ្គសិក្សា.

រួចរាល់? ប្រសិនបើអ្នកមិនបានផ្លាស់ប្តូរការកំណត់លំនាំដើមទេ ឃ្លាំងវគ្គសិក្សារបស់អ្នកទំនងជាត្រូវបានគេហៅថា continuous-integration-team-scenarios-studentsវាមានទីតាំងនៅក្នុងគណនី GitHub របស់អ្នក ហើយ URL មើលទៅដូចនេះ

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

ខ្ញុំនឹងហៅអាសយដ្ឋាននេះដោយសាមញ្ញ <URL репозитория>.

តង្កៀបមុំដូច <тут> នឹងមានន័យថាអ្នកត្រូវតែជំនួសកន្សោមបែបនេះជាមួយនឹងតម្លៃសមស្រប។

ធ្វើ​ឱ្យ​ប្រាកដ​ថា សកម្មភាព GitHub រួមបញ្ចូលសម្រាប់ឃ្លាំងវគ្គសិក្សានេះ។ ប្រសិនបើពួកវាមិនត្រូវបានបើកទេ សូមបើកពួកវាដោយចុចប៊ូតុងធំនៅកណ្តាលទំព័រ ដែលអ្នកអាចចូលទៅបានដោយចុច សកម្មភាពនៅក្នុងចំណុចប្រទាក់ GitHub ។

អ្នកនឹងមិនអាចបញ្ចប់វគ្គសិក្សាតាមការណែនាំរបស់ខ្ញុំបានទេ ប្រសិនបើសកម្មភាព GitHub មិនត្រូវបានបើក។

អ្នកតែងតែអាចប្រើសមត្ថភាពរបស់ GitHub ដើម្បីបង្ហាញ Markdown ដើម្បីមើលស្ថានភាពបច្ចុប្បន្ននៃបញ្ជីដែលយើងកំពុងសរសេរនៅទីនេះ

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

អំពីចម្លើយ

ខណៈពេលដែលវិធីដ៏ល្អបំផុតដើម្បីបញ្ចប់វគ្គសិក្សានេះគឺដើម្បីធ្វើវាដោយខ្លួនឯង អ្នកប្រហែលជាមានការលំបាកមួយចំនួន។

ប្រសិនបើអ្នកមានអារម្មណ៍ថាអ្នកមិនយល់ពីអ្វីដែលត្រូវធ្វើ និងមិនអាចបន្តបាន អ្នកអាចរកមើលនៅក្នុងបណ្តាញនេះ។ solutionដែលស្ថិតនៅក្នុងឃ្លាំងចាប់ផ្តើមរបស់អ្នក។
សូម​កុំ​បញ្ចូល​គ្នា។ solution в master ក្នុងអំឡុងពេលវគ្គសិក្សា។ អ្នក​អាច​ប្រើ​សាខា​នេះ​ដើម្បី​គិត​ពី​អ្វី​ដែល​ត្រូវ​ធ្វើ ឬ​ដើម្បី​ប្រៀបធៀប​កូដ​របស់​អ្នក​ជាមួយ​នឹង​អ្នក​និពន្ធ ដោយ​ប្រើ​គ្រប់​សមត្ថភាព​ដែល Git ផ្ដល់​ឱ្យ​យើង។ ប្រសិនបើអ្នកបាត់បង់ទាំងស្រុង អ្នកអាចជំនួសសាខារបស់អ្នកទាំងស្រុង master នៅលើសាខាមួយ។ solution ហើយបន្ទាប់មកកំណត់ថតការងាររបស់អ្នកឡើងវិញទៅជំហានវគ្គសិក្សាដែលអ្នកត្រូវការ។

ប្រើវាតែប្រសិនបើអ្នកពិតជាត្រូវការវា។

បញ្ចូលលេខកូដរបស់អ្នក។

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

ពាក្យបញ្ជាទាំងនេះ

• ប្តូរឈ្មោះ master в master-backup;
• ប្តូរឈ្មោះ solution в master;
• ចេញទៅកាន់សាខាថ្មី។ master និងសរសេរឡើងវិញនូវមាតិកានៃថតការងារ;
• បង្កើតសាខា "ដំណោះស្រាយ" ពី "មេ" (ដែលធ្លាប់ជា "ដំណោះស្រាយ") ក្នុងករណីដែលអ្នកត្រូវការសាខា "ដំណោះស្រាយ" នាពេលអនាគត។

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

បន្ទាប់ពីជំហានទាំងនេះអ្នកអាចប្រើ git log master ដើម្បីដឹងថាការប្តេជ្ញាចិត្តមួយណាដែលអ្នកត្រូវការ។
អ្នក​អាច​កំណត់​បញ្ជី​ការងារ​របស់​អ្នក​ឡើង​វិញ​ចំពោះ​ការ​ប្រព្រឹត្ត​ដូច​នេះ៖

git reset --hard <the SHA you need>

ប្រសិនបើអ្នកសប្បាយចិត្តនឹងលទ្ធផល នៅចំណុចខ្លះអ្នកនឹងត្រូវបោះពុម្ពផ្សាយកំណែរបស់អ្នកនៃឃ្លាំងទៅកាន់ឃ្លាំងពីចម្ងាយ។ កុំភ្លេចបញ្ជាក់ឱ្យច្បាស់អំពីសាខាពីចម្ងាយ នៅពេលអ្នកធ្វើដូចនេះ។

git push --force origin master

សូមចំណាំថាយើងប្រើ git push --force. វាមិនទំនងដែលអ្នកចង់ធ្វើវាញឹកញាប់ទេ ប៉ុន្តែយើងមានសេណារីយ៉ូជាក់លាក់មួយនៅទីនេះជាមួយអ្នកប្រើប្រាស់ឃ្លាំងម្នាក់ដែលលើសពីនេះទៀតយល់ពីអ្វីដែលគាត់កំពុងធ្វើ។

ចាប់ផ្តើមធ្វើការ

ចូរចាប់ផ្តើមចងក្រងបញ្ជីជំហាន CI របស់យើង។ ជាធម្មតា អ្នកនឹងចាប់ផ្តើមជំហាននេះដោយពិនិត្យមើលកំណែចុងក្រោយបំផុតនៃកូដពីឃ្លាំងពីចម្ងាយ ប៉ុន្តែយើងមិនទាន់មានឃ្លាំងមូលដ្ឋាននៅឡើយទេ ដូច្នេះយើងក្លូនវាពីឧបករណ៍បញ្ជាពីចម្ងាយជំនួសវិញ។

️ កិច្ចការ៖ ធ្វើបច្ចុប្បន្នភាពឃ្លាំងមូលដ្ឋាន បង្កើតសាខាពី master, ចាប់​ផ្តើ​ម​ធ្វើ​ការងារ

1. ក្លូនឃ្លាំងវគ្គសិក្សាពី <URL репозитория>.
2. រត់ npm install នៅក្នុងបញ្ជីនៃឃ្លាំងវគ្គសិក្សា; យើងត្រូវការវាដើម្បីដំឡើង Jest ដែលយើងប្រើដើម្បីដំណើរការតេស្ត។
3. បង្កើតសាខាមួយហើយដាក់ឈ្មោះវា។ feature. ប្តូរទៅខ្សែនេះ។

4. បន្ថែមលេខកូដសាកល្បងទៅ ci.test.js រវាងមតិដែលស្នើឱ្យខ្ញុំធ្វើនេះ។

   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. បន្ថែមអត្ថបទជាមួយ 4 ជំហានដំបូងទៅឯកសារ 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 как описано выше

បង្កើតការប្តេជ្ញាចិត្តលើសាខាថ្មី បង្កើត និងសាកល្បងក្នុងមូលដ្ឋាន

យើង​នឹង​រៀបចំ​ការ​ធ្វើ​តេស្ត​ដើម្បី​ដំណើរការ​មុន​នឹង​ធ្វើ ហើយ​បន្ទាប់​មក​បញ្ចូល​កូដ។

ស្ថានភាពធម្មតានៅពេលដែលការធ្វើតេស្តដំណើរការដោយស្វ័យប្រវត្តិ

• ក្នុងស្រុក៖
  • បន្តឬឆ្លើយតបទៅនឹងការផ្លាស់ប្តូរកូដសមស្រប;
  • នៅលើការរក្សាទុក (សម្រាប់ភាសាដែលបានបកប្រែឬ JIT-ចងក្រង);
  • កំឡុងពេលជួបប្រជុំគ្នា (នៅពេលដែលការចងក្រងត្រូវបានទាមទារ);
  • នៅលើការប្តេជ្ញាចិត្ត;
  • នៅពេលបោះពុម្ពផ្សាយទៅឃ្លាំងចែករំលែក។

• នៅលើ build server ឬ build environment៖
  • នៅពេលដែលលេខកូដត្រូវបានផ្សព្វផ្សាយទៅកាន់សាខា/ឃ្លាំងផ្ទាល់ខ្លួន។
  • កូដនៅក្នុងខ្សែនេះកំពុងត្រូវបានសាកល្បង។
  • លទ្ធផលសក្តានុពលនៃការរួមបញ្ចូលគ្នាត្រូវបានសាកល្បង (ជាធម្មតាជាមួយ master).
  • ជាដំណាក់កាលសមាហរណកម្មបន្ត / បំពង់ចែកចាយបន្ត

ជាធម្មតា ឈុតសាកល្បងដំណើរការកាន់តែលឿន អ្នកអាចមានលទ្ធភាពក្នុងការដំណើរការវាបានញឹកញាប់។ ការចែកចាយដំណាក់កាលធម្មតាអាចមើលទៅដូចនេះ។

• ការធ្វើតេស្តឯកតាលឿន - កំឡុងពេលសាងសង់ក្នុងបំពង់ CI
• ការធ្វើតេស្តឯកតាយឺត ការធ្វើតេស្តសមាសធាតុរហ័ស និងការធ្វើសមាហរណកម្ម - នៅលើការប្តេជ្ញាចិត្ត នៅក្នុងបំពង់ CI
• ការធ្វើតេស្តសមាសធាតុយឺត និងការរួមបញ្ចូល - នៅក្នុងបំពង់ CI
• ការធ្វើតេស្តសុវត្ថិភាព ការធ្វើតេស្តផ្ទុក និងការធ្វើតេស្តដែលចំណាយពេលវេលា ឬមានតម្លៃថ្លៃផ្សេងទៀត - នៅក្នុងបំពង់ CI/CD ប៉ុន្តែមានតែនៅក្នុងរបៀប/ដំណាក់កាល/បំពង់នៃការសាងសង់ប៉ុណ្ណោះ ឧទាហរណ៍ នៅពេលរៀបចំបេក្ខជនចេញផ្សាយ ឬនៅពេលដំណើរការដោយដៃ។

️ កិច្ចការ

ខ្ញុំស្នើឱ្យដំណើរការការធ្វើតេស្តដោយដៃជាមុនសិនដោយប្រើពាក្យបញ្ជា npm test. បន្ទាប់ពីនោះ សូមបន្ថែម git hook ដើម្បីដំណើរការការធ្វើតេស្តរបស់យើងនៅលើការប្តេជ្ញាចិត្ត។ មានការចាប់មួយ៖ ទំពក់ Git មិនត្រូវបានចាត់ទុកថាជាផ្នែកមួយនៃឃ្លាំងទេ ដូច្នេះហើយមិនអាចក្លូនចេញពី GitHub រួមជាមួយនឹងសម្ភារៈវគ្គសិក្សាដែលនៅសល់បានទេ។ ដើម្បីដំឡើងទំពក់អ្នកត្រូវដំណើរការ install_hook.sh ឬចម្លងឯកសារ repo/hooks/pre-commit ទៅកាន់ថតក្នុងស្រុក .git/hooks/.
នៅពេលអ្នកប្រព្រឹត្ត អ្នកនឹងឃើញថាការធ្វើតេស្តត្រូវបានដំណើរការ ហើយពួកគេពិនិត្យមើលថាតើពាក្យគន្លឹះមួយចំនួនមានវត្តមាននៅក្នុងបញ្ជីដែរឬទេ។

1. ដំណើរការការធ្វើតេស្តដោយដៃដោយដំណើរការពាក្យបញ្ជា npm test នៅក្នុងថតឃ្លាំងវគ្គសិក្សារបស់អ្នក។ ផ្ទៀងផ្ទាត់ថាការធ្វើតេស្តត្រូវបានបញ្ចប់។
2. កំណត់ commit hook (pre-commit hook) ដោយដំណើរការ install_hook.sh.
3. ធ្វើការផ្លាស់ប្តូររបស់អ្នកទៅកាន់ឃ្លាំងមូលដ្ឋានរបស់អ្នក។
4. ត្រូវប្រាកដថាការធ្វើតេស្តត្រូវបានដំណើរការមុនពេលធ្វើ។

ឃ្លាំងរបស់អ្នកគួរតែមើលទៅដូចនេះ បន្ទាប់ពីធ្វើតាមជំហានទាំងនេះ។

ក្រុម

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

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

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

ផ្សព្វផ្សាយលេខកូដទៅឃ្លាំងពីចម្ងាយ ឬសាខាពីចម្ងាយ

នៅពេលដែលពួកគេធ្វើការក្នុងមូលដ្ឋានរួចរាល់ហើយ អ្នកអភិវឌ្ឍន៍ជាធម្មតាធ្វើឱ្យកូដរបស់ពួកគេមានជាសាធារណៈ ដូច្នេះវាអាចត្រូវបានដាក់បញ្ចូលជាសាធារណៈជាមួយសាធារណៈជន។ ជាមួយនឹង GitHub នេះជាធម្មតាត្រូវបានសម្រេចដោយការបោះពុម្ពផ្សាយការងារទៅទាំងច្បាប់ចម្លងផ្ទាល់ខ្លួននៃឃ្លាំង (សមផ្ទាល់ខ្លួន) ឬសាខាផ្ទាល់ខ្លួន។

• ជាមួយនឹងសម អ្នកអភិវឌ្ឍន៍បានក្លូនឃ្លាំងចែករំលែកពីចម្ងាយ ដោយបង្កើតច្បាប់ចម្លងពីចម្ងាយផ្ទាល់ខ្លួនរបស់វា ដែលត្រូវបានគេស្គាល់ផងដែរថាជាសម។ បន្ទាប់មកវាក្លូនឃ្លាំងផ្ទាល់ខ្លួននេះ ដើម្បីធ្វើការជាមួយមូលដ្ឋាន។ នៅពេលដែលការងារត្រូវបានបញ្ចប់ ហើយការប្តេជ្ញាចិត្តត្រូវបានបង្កើតឡើង គាត់រុញវាចូលទៅក្នុងសមរបស់គាត់ ដែលជាកន្លែងដែលពួកគេអាចរកបានសម្រាប់អ្នកដទៃ ហើយអាចបញ្ចូលទៅក្នុងឃ្លាំងរួម។ វិធីសាស្រ្តនេះត្រូវបានគេប្រើជាទូទៅនៅក្នុងគម្រោងប្រភពបើកចំហនៅលើ GitHub ។ វាត្រូវបានគេប្រើផងដែរនៅក្នុងវគ្គសិក្សាកម្រិតខ្ពស់របស់ខ្ញុំ [ការងារជាក្រុម និង CI ជាមួយ Git] (http://devops.redpill.solutions/).
• វិធីសាស្រ្តមួយទៀតគឺប្រើតែឃ្លាំងពីចម្ងាយមួយប៉ុណ្ណោះ ហើយរាប់តែសាខាប៉ុណ្ណោះ។ master ឃ្លាំងចែករំលែក "ការពារ" ។ នៅក្នុងសេណារីយ៉ូនេះ អ្នកអភិវឌ្ឍន៍ម្នាក់ៗបោះផ្សាយកូដរបស់ពួកគេទៅកាន់សាខានៃឃ្លាំងពីចម្ងាយ ដូច្នេះអ្នកផ្សេងទៀតអាចមើលកូដនេះ ប្រសិនបើអ្វីៗគ្រប់យ៉ាងស្ថិតក្នុងលំដាប់ សូមបញ្ចូលវាជាមួយ master ឃ្លាំងចែករំលែក។

នៅក្នុងវគ្គសិក្សាពិសេសនេះ យើងនឹងប្រើប្រាស់លំហូរការងារដែលប្រើប្រាស់សាខា។

សូម​ផ្សាយ​កូដ​របស់​យើង។

️ កិច្ចការ

• បោះផ្សាយការផ្លាស់ប្តូរទៅសាខាដាច់ស្រយាលដែលមានឈ្មោះដូចគ្នានឹងសាខាធ្វើការរបស់អ្នក។

ក្រុម

git push --set-upstream origin feature

បង្កើតសំណើរទាញ

បង្កើតសំណើទាញជាមួយចំណងជើង ជំហានពិនិត្យឡើងវិញ... ដំឡើង feature ដូចជា "សាខាក្បាល" និង master ដូចជា "សាខាមូលដ្ឋាន" ។

ត្រូវប្រាកដថាអ្នកបានដំឡើង master នៅក្នុងរបស់គាត់ បំបែកឃ្លាំង ក្នុងនាមជា "សាខាមូលដ្ឋាន" ខ្ញុំនឹងមិនឆ្លើយតបទៅនឹងសំណើសម្រាប់ការផ្លាស់ប្តូរទៅឃ្លាំងសម្ភារៈវគ្គសិក្សានោះទេ។

នៅក្នុងភាសា GitHub "សាខាមូលដ្ឋាន" គឺជាសាខាដែលអ្នកផ្អែកលើការងាររបស់អ្នក ហើយ "សាខាក្បាល" គឺជាសាខាដែលមានការផ្លាស់ប្តូរដែលបានស្នើឡើង។

ពិភាក្សាអំពីការផ្លាស់ប្តូរ បន្ថែមការប្តេជ្ញាចិត្តថ្មី នៅពេលដែលការពិភាក្សាបន្ត

សំណើទាញ (PR)

សំណើទាញ (PR) គឺជាវិធីមួយដើម្បីពិភាក្សា និងសរសេរកូដ ក៏ដូចជាធ្វើការពិនិត្យកូដ។ សំណើទាញត្រូវបានដាក់ឈ្មោះតាមវិធីទូទៅនៃការរួមបញ្ចូលការផ្លាស់ប្តូរបុគ្គលទៅក្នុងកូដរួម។ ជាធម្មតា មនុស្សម្នាក់ក្លូនឃ្លាំងផ្លូវការពីចម្ងាយរបស់គម្រោង ហើយធ្វើការលើកូដក្នុងស្រុក។ បន្ទាប់ពីនោះ គាត់ដាក់លេខកូដទៅក្នុងឃ្លាំងពីចម្ងាយផ្ទាល់ខ្លួនរបស់គាត់ ហើយសុំឱ្យអ្នកទទួលខុសត្រូវចំពោះឃ្លាំងផ្លូវការមកយក(ទាញ) កូដរបស់វាទៅក្នុងឃ្លាំងមូលដ្ឋានរបស់ពួកគេ ដែលពួកគេពិនិត្យមើល និងអាចរួមបញ្ចូល (បញ្ចូល) របស់គាត់។ គំនិតនេះត្រូវបានគេស្គាល់ផងដែរដោយឈ្មោះផ្សេងទៀតឧទាហរណ៍។ ពាក្យសុំបញ្ចូលគ្នា.

អ្នកមិនចាំបាច់ប្រើមុខងារសំណើរទាញរបស់ GitHub ឬវេទិកាស្រដៀងគ្នានោះទេ។ ក្រុមអភិវឌ្ឍន៍អាចប្រើវិធីសាស្រ្តទំនាក់ទំនងផ្សេងទៀត រួមទាំងការទំនាក់ទំនងទល់មុខ ការហៅជាសំឡេង ឬអ៊ីមែល ប៉ុន្តែនៅតែមានហេតុផលមួយចំនួនដែលត្រូវប្រើសំណើទាញទម្រង់វេទិកា។ នេះគឺជាពួកគេមួយចំនួន៖

• ការពិភាក្សាដែលបានរៀបចំទាក់ទងនឹងការផ្លាស់ប្តូរកូដជាក់លាក់;
• ជាកន្លែងសម្រាប់មើលមតិកែលម្អលើការងារដែលកំពុងដំណើរការពី autotesters និងសហការី;
• ផ្លូវការនៃការពិនិត្យកូដ;
• ដូច្នេះនៅពេលក្រោយ អ្នកអាចរកឃើញហេតុផល និងការពិចារណានៅពីក្រោយនេះ ឬបំណែកនៃកូដនោះ។

ជាធម្មតា អ្នកបង្កើតសំណើរទាញ នៅពេលដែលអ្នកត្រូវការពិភាក្សាអ្វីមួយ ឬទទួលបានមតិកែលម្អ។ ឧទាហរណ៍ ប្រសិនបើអ្នកកំពុងធ្វើការលើមុខងារដែលអាចត្រូវបានអនុវត្តច្រើនជាងមួយ អ្នកអាចបង្កើតសំណើទាញ មុនពេលសរសេរកូដដំបូងដើម្បីចែករំលែកគំនិតរបស់អ្នក និងពិភាក្សាអំពីផែនការរបស់អ្នកជាមួយអ្នកសហការរបស់អ្នក។ ប្រសិនបើការងារមានភាពសាមញ្ញជាងនេះ សំណើរទាញត្រូវបានបើកនៅពេលដែលអ្វីមួយត្រូវបានធ្វើរួច ប្តេជ្ញាចិត្ត និងអាចពិភាក្សាបាន។ នៅក្នុងសេណារីយ៉ូមួយចំនួន អ្នកប្រហែលជាចង់បើក PR សម្រាប់តែហេតុផលត្រួតពិនិត្យគុណភាពប៉ុណ្ណោះ៖ ដើម្បីដំណើរការការធ្វើតេស្តដោយស្វ័យប្រវត្តិ ឬចាប់ផ្តើមការពិនិត្យកូដ។ អ្វីក៏ដោយដែលអ្នកសម្រេចចិត្ត កុំភ្លេច @mention មនុស្សដែលមានការយល់ព្រមដែលអ្នកចង់បាននៅក្នុងសំណើទាញរបស់អ្នក។

ជាធម្មតានៅពេលបង្កើត PR អ្នកធ្វើដូចខាងក្រោម។

• ចង្អុលបង្ហាញអ្វីដែលអ្នកស្នើឱ្យផ្លាស់ប្តូរ និងកន្លែងណា។
• សរសេរការពិពណ៌នាពន្យល់ពីគោលបំណងនៃការផ្លាស់ប្តូរ។ អ្នកអាចចង់បាន៖
  • បន្ថែម​អ្វី​ដែល​សំខាន់​ដែល​មិន​ច្បាស់​ពី​កូដ ឬ​អ្វី​ដែល​មាន​ប្រយោជន៍​សម្រាប់​ការ​យល់​ពី​បរិបទ​ដូចជា #bugs ដែល​ពាក់ព័ន្ធ និង​លេខ​ប្រព្រឹត្ត។
  • @mention នរណាម្នាក់ដែលអ្នកចង់ចាប់ផ្តើមធ្វើការជាមួយ ឬអ្នកអាច @mention ពួកគេនៅក្នុងមតិយោបល់នៅពេលក្រោយ។
  • សុំឱ្យសហសេវិកជួយអ្វីមួយ ឬពិនិត្យមើលអ្វីមួយជាក់លាក់។

នៅពេលដែលអ្នកបើក PR ការធ្វើតេស្តដែលបានកំណត់រចនាសម្ព័ន្ធដើម្បីដំណើរការនៅក្នុងករណីបែបនេះត្រូវបានប្រតិបត្តិ។ ក្នុងករណីរបស់យើង នេះនឹងជាសំណុំនៃការធ្វើតេស្តដូចគ្នាដែលយើងបានដំណើរការក្នុងមូលដ្ឋាន ប៉ុន្តែនៅក្នុងគម្រោងពិត វាអាចមានការធ្វើតេស្ត និងការត្រួតពិនិត្យបន្ថែម។

សូមរង់ចាំខណៈពេលដែលការធ្វើតេស្តត្រូវបានបញ្ចប់។ អ្នកអាចឃើញស្ថានភាពនៃការធ្វើតេស្តនៅខាងក្រោមនៃការពិភាក្សា PR នៅក្នុងចំណុចប្រទាក់ GitHub ។ បន្តនៅពេលការធ្វើតេស្តត្រូវបានបញ្ចប់។

️ បន្ថែមកំណត់ចំណាំអំពីភាពចៃដន្យនៃបញ្ជីជំហាន CI

បញ្ជីដែលប្រើក្នុងវគ្គសិក្សានេះគឺបំពាន និងប្រធានបទ យើងគួរបន្ថែមចំណាំអំពីរឿងនេះ។

️ កិច្ចការ៖ បង្កើតសំណើទាញសម្រាប់មតិយោបល់នេះ។

1. ប្តូរទៅសាខា master.
2. បង្កើតសាខាដែលមានឈ្មោះ bugfix.
3. បន្ថែមអត្ថបទចំណាំទៅចុងបញ្ចប់នៃឯកសារ 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. ធ្វើការផ្លាស់ប្តូរ។
5. បោះផ្សាយខ្សែស្រឡាយ bugfix ទៅឃ្លាំងពីចម្ងាយ។
6. បង្កើតពាក្យសុំទាញដែលមានឈ្មោះ ការបន្ថែមការកត់សម្គាល់ ជាមួយនឹងសាខាក្បាល bugfix និងសាខាមូលដ្ឋានmaster.

ត្រូវប្រាកដថាអ្នកបានដំឡើង master នៅក្នុងរបស់គាត់ បំបែកឃ្លាំង ក្នុងនាមជា "សាខាមូលដ្ឋាន" ខ្ញុំនឹងមិនឆ្លើយតបទៅនឹងសំណើសម្រាប់ការផ្លាស់ប្តូរទៅឃ្លាំងសម្ភារៈវគ្គសិក្សានោះទេ។

នេះជាអ្វីដែលឃ្លាំងរបស់អ្នកគួរតែមើលទៅ។

ក្រុម

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

អនុម័តសំណើទាញ "បន្ថែមការកត់សម្គាល់"

️ កិច្ចការ

1. បង្កើតសំណើរទាញ។
2. ចុច "បញ្ចូលសំណើទាញ" ។
3. ចុច "បញ្ជាក់ការបញ្ចូលគ្នា" ។
4. ចុច "លុបសាខា" យើងលែងត្រូវការវាទៀតហើយ។

នេះគឺជាដ្យាក្រាមនៃការប្តេជ្ញាចិត្តបន្ទាប់ពីការបញ្ចូលគ្នា។

️បន្តធ្វើការ និងបន្ថែមការធ្វើតេស្ត

ការសហការគ្នាលើសំណើរទាញជាញឹកញាប់នាំទៅរកការងារបន្ថែម។ ជាធម្មតា នេះ​ជា​លទ្ធផល​នៃ​ការ​ពិនិត្យ​កូដ ឬ​ការ​ពិភាក្សា ប៉ុន្តែ​ក្នុង​វគ្គ​សិក្សា​របស់​យើង យើង​នឹង​ធ្វើ​ជា​គំរូ​ដោយ​បន្ថែម​ធាតុ​ថ្មី​ទៅ​ក្នុង​បញ្ជី​ជំហាន CI របស់​យើង។

ការរួមបញ្ចូលជាបន្តបន្ទាប់ជាធម្មតាពាក់ព័ន្ធនឹងការគ្របដណ្តប់ការធ្វើតេស្តមួយចំនួន។ តម្រូវការគ្របដណ្តប់លើការធ្វើតេស្តមានភាពខុសប្លែកគ្នា ហើយជាធម្មតាត្រូវបានរកឃើញនៅក្នុងឯកសារដែលហៅថាអ្វីមួយដូចជា "គោលការណ៍ណែនាំអំពីការរួមចំណែក"។ យើងនឹងរក្សាវាឱ្យសាមញ្ញ ហើយបន្ថែមការធ្វើតេស្តសម្រាប់បន្ទាត់នីមួយៗនៅក្នុងបញ្ជីត្រួតពិនិត្យរបស់យើង។

នៅពេលដំណើរការកិច្ចការ សូមសាកល្បងធ្វើតេស្តជាមុនសិន។ ប្រសិនបើអ្នកដំឡើងត្រឹមត្រូវ។ pre-commit ទំពក់មុននេះ ការធ្វើតេស្តដែលបានបន្ថែមថ្មីនឹងត្រូវដំណើរការ នឹងបរាជ័យ ហើយគ្មានអ្វីនឹងត្រូវបានប្តេជ្ញាចិត្តឡើយ។ ចំណាំថានេះជារបៀបដែលយើងដឹងថាការធ្វើតេស្តរបស់យើងពិតជាកំពុងសាកល្បងអ្វីមួយ។ គួរឱ្យចាប់អារម្មណ៍ ប្រសិនបើយើងចាប់ផ្តើមជាមួយកូដមុនពេលធ្វើតេស្ត ការឆ្លងកាត់ការធ្វើតេស្តអាចមានន័យថាលេខកូដដំណើរការដូចការរំពឹងទុក ឬថាការធ្វើតេស្តពិតជាមិនបានសាកល្បងអ្វីទាំងអស់។ លើសពីនេះ ប្រសិនបើយើងមិនបានសរសេរការប្រលងតាំងពីដំបូងទេ យើងប្រហែលជាភ្លេចអំពីវាទាំងស្រុង ព្រោះគ្មានអ្វីអាចរំលឹកយើងពីវាបានទេ។

សាកល្បងការអភិវឌ្ឍន៍ជំរុញ (TDD)

TDD ណែនាំឱ្យសរសេរការធ្វើតេស្តមុនពេលសរសេរកូដ។ លំហូរការងារធម្មតាដោយប្រើ TDD មើលទៅដូចនេះ។

1. បន្ថែមការធ្វើតេស្ត។
2. ដំណើរការការធ្វើតេស្តទាំងអស់ ហើយធានាថាការធ្វើតេស្តថ្មីបរាជ័យ។
3. សរសេរកូដ។
4. ដំណើរការការធ្វើតេស្ត ត្រូវប្រាកដថាការធ្វើតេស្តទាំងអស់ឆ្លងកាត់។
5. កែកូដរបស់អ្នក។
6. ធ្វើម្តងទៀត។

ដោយសារតែលទ្ធផលនៃការធ្វើតេស្តដែលបរាជ័យជាធម្មតាត្រូវបានបង្ហាញជាពណ៌ក្រហម ហើយអ្នកដែលឆ្លងកាត់ជាធម្មតាត្រូវបានបង្ហាញជាពណ៌បៃតង វដ្តនេះត្រូវបានគេស្គាល់ថាជា red-green-refactor។

️ កិច្ចការ

ដំបូង សាកល្បងធ្វើតេស្ត ហើយអនុញ្ញាតឱ្យពួកគេបរាជ័យ បន្ទាប់មកបន្ថែម និងបញ្ចូលអត្ថបទនៃបញ្ជីជំហាន CI ដោយខ្លួនឯង។ អ្នកនឹងឃើញថាការធ្វើតេស្តកំពុងឆ្លងកាត់ ("បៃតង") ។
បន្ទាប់មកបោះផ្សាយលេខកូដថ្មីទៅកាន់ឃ្លាំងពីចម្ងាយ ហើយមើលការសាកល្បងដំណើរការនៅក្នុងចំណុចប្រទាក់ GitHub នៅផ្នែកខាងក្រោមនៃការពិភាក្សាសំណើទាញ និងការធ្វើបច្ចុប្បន្នភាពស្ថានភាព PR ។

1. ប្តូរទៅសាខា feature.

2. បន្ថែមការធ្វើតេស្តទាំងនេះទៅ ci.test.js បន្ទាប់ពីការហៅចុងក្រោយ 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. សាកល្បងធ្វើតេស្ត។ ប្រសិនបើ pre-commit ទំពក់ត្រូវបានដំឡើង ការប៉ុនប៉ងនឹងបរាជ័យ។
4. បន្ទាប់មកបន្ថែមអត្ថបទនេះទៅ 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. ធ្វើ​និង​ធ្វើ​ការ​ផ្លាស់​ប្តូ​រ​នៅ​ក្នុង​មូលដ្ឋាន​។
6. ប្រកាសការផ្លាស់ប្តូរទៅសាខា feature.

ឥឡូវនេះអ្នកគួរតែមានអ្វីដូចនេះ

ក្រុម

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

បញ្ចូលគ្នានូវជម្លោះ

ចូលទៅកាន់ការស្នើសុំផ្លាស់ប្តូរ ជំហានពិនិត្យឡើងវិញ.

ទោះបីជាយើងមិនបានធ្វើអ្វីខុស ហើយការធ្វើតេស្តសម្រាប់លេខកូដរបស់យើងបានកន្លងផុតទៅហើយក៏ដោយ យើងនៅតែមិនអាចបញ្ចូលសាខាបានទេ។ feature и master. វាគឺដោយសារតែខ្សែផ្សេងទៀត។ bugfix ត្រូវបានរួមបញ្ចូលគ្នាជាមួយ master ខណៈពេលដែលយើងកំពុងធ្វើការលើ PR នេះ។
នេះបង្កើតស្ថានភាពដែលសាខាដាច់ស្រយាល។ master មានកំណែថ្មីជាងកំណែដែលយើងផ្អែកលើសាខា feature. ដោយ​សារ​តែ​វា​យើង​មិន​អាច​គ្រាន់​តែ​ត្រឡប់ HEAD វិញ។ master ទៅចុងបញ្ចប់នៃខ្សែស្រឡាយ feature. ក្នុងស្ថានភាពនេះ យើងត្រូវបញ្ចូលគ្នា ឬអនុវត្តការប្តេជ្ញាចិត្ត feature មូលដ្ឋានឡើងវិញ master. GitHub ពិតជាអាចអនុវត្តការបញ្ចូលគ្នាដោយស្វ័យប្រវត្តិ ប្រសិនបើមិនមានការប៉ះទង្គិច។ Alas នៅក្នុងស្ថានភាពរបស់យើង សាខាទាំងពីរមានការផ្លាស់ប្តូរប្រកួតប្រជែងនៅក្នុងឯកសារ ci.md. ស្ថានភាពនេះត្រូវបានគេស្គាល់ថាជាជម្លោះបញ្ចូលគ្នា ហើយយើងត្រូវដោះស្រាយវាដោយដៃ។

បញ្ចូលគ្នា ឬបង្កើតឡើងវិញ

បញ្ចូលចូលគ្នា

• បង្កើតការរួមបញ្ចូលបន្ថែម និងរក្សាទុកប្រវត្តិការងារ។
  • រក្សាការប្តេជ្ញាចិត្តដើមនៃសាខាជាមួយនឹងត្រាពេលវេលាដើម និងអ្នកនិពន្ធរបស់ពួកគេ។
  • រក្សាទុក SHA នៃការប្តេជ្ញាចិត្ត និងតំណភ្ជាប់ទៅពួកគេនៅក្នុងការពិភាក្សាសំណើការផ្លាស់ប្តូរ។
• ទាមទារដំណោះស្រាយជម្លោះតែម្តង។
• ធ្វើឱ្យសាច់រឿងមិនត្រង់។
  • រឿង​អាច​ពិបាក​អាន​ដោយសារ​ចំនួន​សាខា​ច្រើន (នឹក​ឃើញ​ដល់​ខ្សែ IDE)។
  • ធ្វើឱ្យការកែកំហុសដោយស្វ័យប្រវត្តិកាន់តែពិបាក ឧ. git bisect មិនសូវមានប្រយោជន៍ - វានឹងរកឃើញតែការបញ្ចូលគ្នាប៉ុណ្ណោះ។

ការដាក់ប្រាក់ឡើងវិញ

• ការ​ចាក់​ឡើងវិញ​ប្រព្រឹត្ត​ពី​សាខា​បច្ចុប្បន្ន​នៅ​លើ​កំពូល​នៃ​សាខា​មូលដ្ឋាន​មួយ​បន្ទាប់​ពី​មួយទៀត។
  • ការប្តេជ្ញាចិត្តថ្មីជាមួយ SHAs ថ្មីត្រូវបានបង្កើត ដែលបណ្តាលឱ្យការប្តេជ្ញាចិត្តនៅក្នុង GitHub ត្រូវគ្នានឹងសំណើទាញដើម ប៉ុន្តែមិនមែនជាមតិយោបល់ដែលត្រូវគ្នានោះទេ។
  • ការប្តេជ្ញាចិត្តអាចត្រូវបានផ្សំឡើងវិញ និងកែប្រែនៅក្នុងដំណើរការ ឬសូម្បីតែរួមបញ្ចូលគ្នាទៅជាមួយ។
• ជម្លោះជាច្រើនអាចនឹងត្រូវដោះស្រាយ។
• អនុញ្ញាតឱ្យអ្នករក្សាសាច់រឿងលីនេអ៊ែរ។
  • សាច់រឿងប្រហែលជាងាយស្រួលអាន ដរាបណាវាមិនទាន់វែងពេក ដោយគ្មានហេតុផលសមហេតុផល។
  • ការកែកំហុសដោយស្វ័យប្រវត្តិ និងការដោះស្រាយបញ្ហាគឺងាយស្រួលជាងបន្តិច៖ ធ្វើឱ្យវាអាចធ្វើទៅបាន git bisectអាចធ្វើឱ្យ rollbacks ដោយស្វ័យប្រវត្តិកាន់តែច្បាស់ និងអាចព្យាករណ៍បាន។
• តម្រូវ​ឱ្យ​មាន​ការ​បោះ​ពុម្ព​ផ្សាយ​សាខា​ដែល​មាន​ការ​ធ្វើ​ចំណាក​ស្រុក​ដោយ​មាន​ទង់ --force នៅពេលប្រើជាមួយសំណើទាញ។

ជាធម្មតា ក្រុមទាំងអស់យល់ព្រមក្នុងការប្រើយុទ្ធសាស្រ្តដូចគ្នាជានិច្ច នៅពេលដែលពួកគេត្រូវការបញ្ចូលការផ្លាស់ប្តូរ។ នេះអាចជាការរួមបញ្ចូលគ្នា "បរិសុទ្ធ" ឬការប្តេជ្ញាចិត្ត "បរិសុទ្ធ" នៅលើកំពូល ឬអ្វីមួយនៅចន្លោះ ដូចជាការធ្វើអន្តរកម្មនៅលើកំពូល (git rebase -i) ក្នុងមូលដ្ឋានសម្រាប់សាខាដែលមិនត្រូវបានបោះផ្សាយទៅឃ្លាំងសាធារណៈ ប៉ុន្តែបញ្ចូលគ្នាសម្រាប់សាខា "សាធារណៈ" ។

នៅទីនេះយើងនឹងប្រើការបញ្ចូលគ្នា។

️ កិច្ចការ

1. ត្រូវប្រាកដថាលេខកូដស្ថិតនៅក្នុងសាខាក្នុងស្រុក master បានធ្វើបច្ចុប្បន្នភាពពីឃ្លាំងពីចម្ងាយ។
2. ប្តូរទៅសាខា feature.
3. ផ្តួចផ្តើមការបញ្ចូលគ្នាជាមួយសាខា master. ជម្លោះ​ដែល​រួម​បញ្ចូល​គ្នា​ដោយ​សារ​តែ​ការ​ផ្លាស់​ប្តូ​រ​គូ​ប្រជែង​ទៅ​នឹង ci.md.
4. ដោះស្រាយជម្លោះដើម្បីឱ្យបញ្ជីជំហាន CI របស់យើងទាំងពីរ និងកំណត់ចំណាំអំពីវានៅតែមាននៅក្នុងអត្ថបទ។
5. បោះផ្សាយការប្តេជ្ញាចិត្តបញ្ចូលគ្នាទៅសាខាពីចម្ងាយ feature.
6. ពិនិត្យមើលស្ថានភាពនៃសំណើរទាញនៅក្នុង GitHub UI ហើយរង់ចាំរហូតដល់ការបញ្ចូលគ្នាត្រូវបានដោះស្រាយ។

ក្រុម

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

ធ្វើ​បាន​ល្អ!

អ្នក​បាន​ធ្វើ​បញ្ជី​រួចរាល់​ហើយ ហើយ​ឥឡូវ​នេះ​អ្នក​ត្រូវ​អនុម័ត​សំណើ​ទាញ​ចូល master.

️ កិច្ចការ៖ អនុម័តសំណើរទាញ "ការពិនិត្យជំហាន"

1. បើកសំណើទាញ។
2. ចុច "បញ្ចូលសំណើទាញ" ។
3. ចុច "បញ្ជាក់ការបញ្ចូលគ្នា" ។
4. ចុច "លុបសាខា" ព្រោះយើងលែងត្រូវការវាទៀតហើយ។

នេះគឺជាឃ្លាំងរបស់អ្នកនៅពេលនេះ

កំហុសផលិតផល

វាត្រូវបានគេនិយាយថា "ការធ្វើតេស្តអាចត្រូវបានប្រើដើម្បីបង្ហាញពីវត្តមាននៃកំហុសប៉ុន្តែកុំបង្ហាញអវត្តមានរបស់ពួកគេ" ។ ទោះបីជាយើងមានការសាកល្បង ហើយពួកគេមិនបានបង្ហាញយើងនូវកំហុសក៏ដោយ ក៏កំហុសដ៏អាក្រក់មួយបានចូលទៅក្នុងផលិតកម្ម។

ក្នុង​សេណារីយ៉ូ​បែប​នេះ យើង​ត្រូវ​ថែរក្សា៖

• អ្វីដែលត្រូវបានដាក់ពង្រាយនៅក្នុងផលិតកម្ម;
• កូដនៅក្នុងខ្សែស្រឡាយ master ជាមួយនឹងកំហុសដែលអ្នកអភិវឌ្ឍន៍អាចចាប់ផ្តើមការងារថ្មី។

តើ​ខ្ញុំ​គួរ​ត្រឡប់​ឬ​ជួសជុល​វា​នៅ​ក្នុង​កំណែ​បន្ទាប់​?

ការត្រលប់មកវិញគឺជាដំណើរការនៃការដាក់ពង្រាយកំណែមុនដែលគេស្គាល់ថាល្អទៅផលិតកម្ម និងត្រឡប់ការប្រព្រឹត្តដែលមានកំហុស។ "ជួសជុលទៅមុខ" គឺជាការបន្ថែមនៃការជួសជុលទៅ master និងដាក់ពង្រាយកំណែថ្មីឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។ ដោយសារតែ APIs និងគ្រោងការណ៍មូលដ្ឋានទិន្នន័យផ្លាស់ប្តូរនៅពេលដែលកូដត្រូវបានដាក់ឱ្យដំណើរការជាមួយនឹងការចែកចាយបន្ត និងការគ្របដណ្តប់ការសាកល្បងល្អ ការវិលត្រឡប់មកវិញជាធម្មតាមានការលំបាក និងប្រថុយប្រថានជាងការជួសជុលវានៅក្នុងកំណែបន្ទាប់។

ដោយសារការវិលត្រឡប់មកវិញមិនមានគ្រោះថ្នាក់អ្វីទេក្នុងករណីរបស់យើង យើងនឹងទៅផ្លូវនេះ ព្រោះវាអនុញ្ញាតឱ្យយើង

• ជួសជុលកំហុសលើផលិតផលឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន;
• បង្កើតលេខកូដ master ភ្លាមៗសមរម្យសម្រាប់ការចាប់ផ្តើមការងារថ្មី។

️ កិច្ចការ

1. ប្តូរទៅសាខា master ក្នុងស្រុក។
2. ធ្វើបច្ចុប្បន្នភាពឃ្លាំងមូលដ្ឋានពីឃ្លាំងពីចម្ងាយ។
3. ត្រឡប់ការប្តេជ្ញាចិត្ត PR បញ្ចូលគ្នា ជំហានពិនិត្យឡើងវិញ в master.
4. បោះផ្សាយការផ្លាស់ប្តូរទៅឃ្លាំងពីចម្ងាយ។

នេះ​ជា​ប្រវត្តិ​នៃ​ឃ្លាំង​ដែល​មាន​ការ​ដាក់​បញ្ចូល​គ្នា​ត្រឡប់​មក​វិញ។

ក្រុម

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

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

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

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

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

️ តេស្តខ្លួនឯង

ធ្វើ​ឱ្យ​ប្រាកដ​ថា ci.md លែងមានអត្ថបទ "sneaky bug" ទៀតហើយ បន្ទាប់ពីធ្វើការបញ្ចូលបញ្ចូលគ្នាឡើងវិញ។

ជួសជុលបញ្ជីជំហាន CI ហើយត្រឡប់វាទៅជាមេ

យើង​បាន​លុប​ចោល​ទាំងស្រុង​នូវ​ការ​រួម​បញ្ចូល​គ្នា​របស់​សាខា។ feature. ដំណឹង​ល្អ​គឺ​ថា​ឥឡូវ​នេះ​យើង​មិន​មាន​កំហុស​នៅ​ក្នុង​ master. ដំណឹង​អាក្រក់​គឺ​ថា​បញ្ជី​ដ៏​មាន​តម្លៃ​នៃ​ជំហាន​សមាហរណកម្ម​បន្ត​របស់​យើង​ក៏​បាត់​ទៅ​ដែរ។ ដូច្នេះតាមឧត្ដមគតិ យើងត្រូវអនុវត្តការកែតម្រូវចំពោះ commits ពី feature ហើយបញ្ជូនពួកគេទៅ master រួមជាមួយនឹងការជួសជុល។

យើងអាចដោះស្រាយបញ្ហាតាមវិធីផ្សេងៗគ្នា៖

• ត្រឡប់​ការ​ប្រព្រឹត្ត​ដែល​មិន​ធ្វើ​ការ​បញ្ចូល​គ្នា។ feature с master;
• ផ្លាស់ទី​ប្រព្រឹត្ត​ពី​អតីត feature.

ក្រុមអភិវឌ្ឍន៍ផ្សេងគ្នាប្រើវិធីសាស្រ្តផ្សេងគ្នាក្នុងករណីនេះ ប៉ុន្តែយើងនឹងផ្លាស់ទីការសន្យាដែលមានប្រយោជន៍ទៅកាន់សាខាដាច់ដោយឡែកមួយ ហើយបង្កើតសំណើទាញដាច់ដោយឡែកសម្រាប់សាខាថ្មីនេះ។

️ កិច្ចការ

1. បង្កើត​ខ្សែ​ដែល​ហៅ​ថា​ feature-fix ហើយប្តូរទៅវា។

2. ផ្ទេរការប្តេជ្ញាចិត្តទាំងអស់ពីអតីតសាខា feature ទៅកាន់ខ្សែថ្មី។ ដោះស្រាយជម្លោះបញ្ចូលគ្នាដែលបានកើតឡើងអំឡុងពេលធ្វើចំណាកស្រុក។

   

3. បន្ថែមការធ្វើតេស្តតំរែតំរង់ទៅ ci.test.js:

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

4. ដំណើរការការធ្វើតេស្តក្នុងមូលដ្ឋាន ដើម្បីប្រាកដថាពួកគេមិនបរាជ័យ។
5. លុបអត្ថបទ "ជាមួយកំហុសឆ្គង" នៅក្នុង ci.md.
6. បន្ថែមការផ្លាស់ប្តូរការធ្វើតេស្ត និងការផ្លាស់ប្តូរបញ្ជីជំហានទៅកាន់លិបិក្រម ហើយប្តេជ្ញាចិត្តពួកគេ។
7. បោះផ្សាយសាខាទៅឃ្លាំងពីចម្ងាយ។

អ្នកគួរតែបញ្ចប់ដោយអ្វីមួយស្រដៀងនឹងនេះ៖

ក្រុម

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

បង្កើតសំណើរទាញ។

បង្កើតសំណើទាញជាមួយចំណងជើង ជួសជុលមុខងារ... ដំឡើង feature-fix ដូចជា "សាខាក្បាល" និង master ដូចជា "សាខាមូលដ្ឋាន" ។
សូមរង់ចាំខណៈពេលដែលការធ្វើតេស្តបានបញ្ចប់។ អ្នកអាចឃើញស្ថានភាពនៃការធ្វើតេស្តនៅខាងក្រោមនៃការពិភាក្សា PR ។

ត្រូវប្រាកដថាអ្នកបានដំឡើង master នៅក្នុងរបស់គាត់ បំបែកឃ្លាំង ក្នុងនាមជា "សាខាមូលដ្ឋាន" ខ្ញុំនឹងមិនឆ្លើយតបទៅនឹងសំណើសម្រាប់ការផ្លាស់ប្តូរទៅឃ្លាំងសម្ភារៈវគ្គសិក្សានោះទេ។

អនុម័តសំណើទាញ "ជួសជុលមុខងារ"

អរគុណសម្រាប់ការកែតម្រូវ! សូមយល់ព្រមលើការផ្លាស់ប្ដូរ master ពីការស្នើសុំទាញ។

️ កិច្ចការ

1. ចុច "បញ្ចូលសំណើទាញ" ។
2. ចុច "បញ្ជាក់ការបញ្ចូលគ្នា" ។
3. ចុច "លុបសាខា" ព្រោះយើងលែងត្រូវការវាទៀតហើយ។

នេះជាអ្វីដែលអ្នកគួរតែមាននៅពេលនេះ។

អបអរសាទរ!

អ្នកបានបញ្ចប់ជំហានទាំងអស់ដែលមនុស្សទូទៅធ្វើក្នុងអំឡុងពេលរួមបញ្ចូលជាបន្តបន្ទាប់។

ប្រសិនបើអ្នកកត់សម្គាល់បញ្ហាណាមួយជាមួយវគ្គសិក្សា ឬដឹងពីរបៀបកែលម្អវា សូមបង្កើតបញ្ហានៅក្នុង ឃ្លាំងជាមួយសម្ភារៈសិក្សា. វគ្គសិក្សានេះក៏មាន កំណែអន្តរកម្ម ដោយប្រើ GitHub Learning Lab ជាវេទិកាមួយ។

ប្រភព: www.habr.com