ທ່ານໄດ້ຮຽນຮູ້ຄໍາສັ່ງ Git ແຕ່ຕ້ອງການຈິນຕະນາການວິທີການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ (CI) ເຮັດວຽກຢູ່ໃນຄວາມເປັນຈິງບໍ? ຫຼືບາງທີທ່ານຕ້ອງການເພີ່ມປະສິດທິພາບກິດຈະກໍາປະຈໍາວັນຂອງທ່ານບໍ? ຫຼັກສູດນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດໄດ້ໃນການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງໂດຍໃຊ້ GitHub repository. ຫຼັກສູດນີ້ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອເປັນຕົວຊ່ວຍສ້າງທີ່ທ່ານພຽງແຕ່ສາມາດກົດໂດຍຜ່ານ; ໃນທາງກົງກັນຂ້າມ, ທ່ານຈະປະຕິບັດການກະທໍາດຽວກັນກັບຄົນທີ່ເຮັດວຽກຕົວຈິງ, ໃນທາງດຽວກັນກັບພວກເຂົາ. ຂ້ອຍຈະອະທິບາຍທິດສະດີໃນຂະນະທີ່ເຈົ້າຜ່ານຂັ້ນຕອນທີ່ກ່ຽວຂ້ອງ.

ພວກເຮົາເຮັດແນວໃດ?

ໃນຂະນະທີ່ພວກເຮົາກ້າວຫນ້າ, ພວກເຮົາຈະຄ່ອຍໆສ້າງບັນຊີລາຍຊື່ຂອງຂັ້ນຕອນ CI ປົກກະຕິ, ເຊິ່ງເປັນວິທີທີ່ດີທີ່ຈະຈື່ຈໍາບັນຊີລາຍຊື່ນີ້. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາຈະສ້າງບັນຊີລາຍຊື່ຂອງການປະຕິບັດທີ່ນັກພັດທະນາປະຕິບັດໃນຂະນະທີ່ເຮັດການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ, ດໍາເນີນການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ. ພວກເຮົາຍັງຈະໃຊ້ຊຸດການທົດສອບທີ່ງ່າຍດາຍເພື່ອເຮັດໃຫ້ຂະບວນການ CI ຂອງພວກເຮົາໃກ້ຊິດກັບຕົວຈິງ.

GIF ນີ້ schematically ສະ ​​ແດງ ໃຫ້ ເຫັນ ຄໍາ ຫມັ້ນ ສັນ ຍາ ໃນ repository ຂອງ ທ່ານ ໃນ ຂະ ນະ ທີ່ ທ່ານ ກ້າວ ໄປ ໂດຍ ຜ່ານ ວິ ຊາ ການ. ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ບໍ່ມີຫຍັງສັບສົນຢູ່ທີ່ນີ້ແລະພຽງແຕ່ມີຄວາມຈໍາເປັນທີ່ສຸດ.

ທ່ານຈະຜ່ານສະຖານະການ CI ມາດຕະຖານຕໍ່ໄປນີ້:

• ເຮັດວຽກກ່ຽວກັບຄຸນນະສົມບັດ;
• ຄໍາຮ້ອງສະຫມັກຂອງການທົດສອບອັດຕະໂນມັດເພື່ອຮັບປະກັນຄຸນນະພາບ;
• ການຈັດຕັ້ງປະຕິບັດວຽກງານບູລິມະສິດ;
• ການ​ແກ້​ໄຂ​ຄວາມ​ຂັດ​ແຍ່ງ​ໃນ​ເວ​ລາ​ທີ່​ການ​ລວມ​ກິ່ງ​ງ່າ (merge ຂໍ້​ຂັດ​ແຍ່ງ​)​;
• ຄວາມຜິດພາດເກີດຂຶ້ນໃນສະພາບແວດລ້ອມການຜະລິດ.

ເຈົ້າຈະຮຽນຫຍັງ?

ທ່ານຈະສາມາດຕອບຄໍາຖາມຕໍ່ໄປນີ້:

• ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (CI) ແມ່ນຫຍັງ?
• ການທົດສອບອັດຕະໂນມັດປະເພດໃດແດ່ທີ່ຖືກນໍາໃຊ້ໃນ CI, ແລະເພື່ອຕອບສະຫນອງກັບການກະທໍາໃດທີ່ພວກມັນຖືກກະຕຸ້ນ?
• ການຮ້ອງຂໍດຶງແມ່ນຫຍັງແລະພວກເຂົາຕ້ອງການເວລາໃດ?
• Test Driven Development (TDD) ແມ່ນຫຍັງ ແລະມັນກ່ຽວຂ້ອງກັບ CI ແນວໃດ?
• ຂ້ອຍຄວນລວມຫຼືຟື້ນຟູການປ່ຽນແປງບໍ?
• ກັບຄືນຫຼືແກ້ໄຂໃນສະບັບຕໍ່ໄປ?

ໃນຕອນທໍາອິດຂ້າພະເຈົ້າໄດ້ແປສິ່ງຕ່າງໆເຊັ່ນ "ການຮ້ອງຂໍດຶງ" ຢູ່ທົ່ວທຸກແຫ່ງ, ແຕ່ຜົນໄດ້ຮັບຂ້າພະເຈົ້າຕັດສິນໃຈກັບຄືນປະໂຫຍກໃນພາສາອັງກິດໃນບາງບ່ອນເພື່ອຫຼຸດຜ່ອນລະດັບຄວາມບ້າໃນຂໍ້ຄວາມ. ບາງຄັ້ງຂ້ອຍຈະໃຊ້ "ນັກຂຽນໂປລແກລມ surzhik" ຄືກັບຄໍາທີ່ປະເສີດ "commit" ບ່ອນທີ່ປະຊາຊົນໃຊ້ມັນຢູ່ໃນບ່ອນເຮັດວຽກ.

ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແມ່ນຫຍັງ?

ການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ, ຫຼື CI, ແມ່ນການປະຕິບັດດ້ານວິຊາການທີ່ສະມາຊິກທີມງານແຕ່ລະຄົນປະສົມປະສານລະຫັດຂອງເຂົາເຈົ້າເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນທົ່ວໄປຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງຕໍ່ມື້, ແລະລະຫັດຜົນໄດ້ຮັບຢ່າງຫນ້ອຍຕ້ອງຖືກສ້າງຂຶ້ນໂດຍບໍ່ມີຂໍ້ຜິດພາດ.

ມີຄວາມຂັດແຍ້ງກ່ຽວກັບຄໍາສັບນີ້

ຈຸດຂອງການຂັດແຍ້ງແມ່ນຄວາມຖີ່ຂອງການເຊື່ອມໂຍງ. ບາງຄົນໂຕ້ຖຽງວ່າການລວມລະຫັດພຽງແຕ່ຫນຶ່ງຄັ້ງຕໍ່ມື້ບໍ່ພຽງພໍທີ່ຈະປະສົມປະສານຕົວຈິງຢ່າງຕໍ່ເນື່ອງ. ຕົວຢ່າງແມ່ນໃຫ້ທີມງານທີ່ທຸກຄົນເອົາລະຫັດສົດໃນຕອນເຊົ້າແລະປະສົມປະສານມັນຫນຶ່ງຄັ້ງໃນຕອນແລງ. ໃນຂະນະທີ່ນີ້ແມ່ນການຄັດຄ້ານທີ່ສົມເຫດສົມຜົນ, ໂດຍທົ່ວໄປແລ້ວມັນເຊື່ອວ່າຄໍານິຍາມມື້ຫນຶ່ງແມ່ນສົມເຫດສົມຜົນ, ສະເພາະ, ແລະເຫມາະສົມສໍາລັບທີມງານທີ່ມີຂະຫນາດທີ່ແຕກຕ່າງກັນ.

ການຄັດຄ້ານອີກຢ່າງຫນຶ່ງແມ່ນວ່າ C ++ ບໍ່ແມ່ນພາສາດຽວທີ່ໃຊ້ໃນການພັດທະນາ, ແລະພຽງແຕ່ຮຽກຮ້ອງໃຫ້ມີການປະກອບທີ່ບໍ່ມີຂໍ້ຜິດພາດເປັນວິທີການກວດສອບແມ່ນອ່ອນແອ. ບາງຊຸດຂອງການທົດສອບ (ຕົວຢ່າງ, ການທົດສອບຫນ່ວຍງານທີ່ປະຕິບັດຢູ່ໃນທ້ອງຖິ່ນ) ກໍ່ຕ້ອງສໍາເລັດຢ່າງສໍາເລັດຜົນ. ໃນປັດຈຸບັນ, ຊຸມຊົນກໍາລັງກ້າວໄປສູ່ການເຮັດໃຫ້ຄວາມຕ້ອງການນີ້, ແລະໃນອະນາຄົດ "ການກໍ່ສ້າງ + ການທົດສອບຫນ່ວຍ" ອາດຈະກາຍເປັນການປະຕິບັດທົ່ວໄປ, ຖ້າມັນຍັງບໍ່ທັນໄດ້.

ການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ ແຕກຕ່າງຈາກ ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ (ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ, CD) ໃນນັ້ນມັນບໍ່ຈໍາເປັນຕ້ອງມີຜູ້ສະຫມັກການປ່ອຍຕົວຫຼັງຈາກແຕ່ລະວົງຈອນການເຊື່ອມໂຍງ.

ບັນຊີລາຍຊື່ຂອງຂັ້ນຕອນທີ່ພວກເຮົາຈະນໍາໃຊ້ຕະຫຼອດຫຼັກສູດ

1. ດຶງລະຫັດຫຼ້າສຸດ. ສ້າງສາຂາຈາກ master. ເລີ່ມເຮັດວຽກ.
2. ສ້າງຄໍາຫມັ້ນສັນຍາໃນສາຂາໃຫມ່ຂອງທ່ານ. ສ້າງ​ແລະ​ທົດ​ສອບ​ໃນ​ທ້ອງ​ຖິ່ນ​. ຜ່ານ? ໄປຂັ້ນຕອນຕໍ່ໄປ. ລົ້ມເຫລວ? ແກ້ໄຂຂໍ້ຜິດພາດ ຫຼືການທົດສອບ ແລະລອງໃໝ່ອີກ.
3. ຍູ້ໄປທີ່ repository ຫຼືສາຂາຫ່າງໄກສອກຫຼີກຂອງທ່ານ.
4. ສ້າງການຮ້ອງຂໍດຶງ. ປຶກສາຫາລືການປ່ຽນແປງ, ເພີ່ມຄໍາຫມັ້ນສັນຍາເພີ່ມເຕີມໃນຂະນະທີ່ການສົນທະນາຍັງສືບຕໍ່. ເຮັດໃຫ້ການທົດສອບຜ່ານສາຂາຄຸນສົມບັດ.
5. Merge / rebase ຄໍາຫມັ້ນສັນຍາຈາກຕົ້ນສະບັບ. ເຮັດ​ໃຫ້​ການ​ທົດ​ສອບ​ຜ່ານ​ຜົນ​ໄດ້​ຮັບ​ການ​ລວມ​.
6. ນຳໃຊ້ຈາກສາຂາຄຸນສົມບັດໄປສູ່ການຜະລິດ.
7. ຖ້າຫາກວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີໃນການຜະລິດສໍາລັບໄລຍະເວລາຂອງບາງເວລາ, merge ການປ່ຽນແປງຕົ້ນສະບັບ.

️ ການກະກຽມ

ໃຫ້ແນ່ໃຈວ່າທ່ານມີຊອບແວທີ່ເຫມາະສົມ

ເພື່ອຮຽນວິຊານີ້, ທ່ານຈະຕ້ອງການ Nodejs и Git ລູກຄ້າ.

ທ່ານສາມາດນໍາໃຊ້ລູກຄ້າ Git ໃດກໍ່ຕາມ, ແຕ່ຂ້ອຍຈະໃຫ້ຄໍາສັ່ງສໍາລັບເສັ້ນຄໍາສັ່ງເທົ່ານັ້ນ.

ໃຫ້ແນ່ໃຈວ່າທ່ານມີລູກຄ້າ Git ຕິດຕັ້ງທີ່ສະຫນັບສະຫນູນເສັ້ນຄໍາສັ່ງ

ຖ້າທ່ານຍັງບໍ່ທັນມີລູກຄ້າ Git ທີ່ສະຫນັບສະຫນູນເສັ້ນຄໍາສັ່ງ, ທ່ານສາມາດຊອກຫາຄໍາແນະນໍາການຕິດຕັ້ງ ທີ່ນີ້.

ກະກຽມບ່ອນເກັບມ້ຽນ

ທ່ານຈະຕ້ອງສ້າງສໍາເນົາສ່ວນຕົວ (ສ້ອມ) template repository ທີ່ມີລະຫັດສໍາລັບຫຼັກສູດ ໃນ GitHub. ໃຫ້ຕົກລົງທີ່ຈະໂທຫາສໍາເນົາສ່ວນບຸກຄົນນີ້ ບ່ອນເກັບມ້ຽນຫຼັກສູດ.

ສຳເລັດແລ້ວ? ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ​ເລີ່ມ​ຕົ້ນ​, repository ຂອງ​ທ່ານ​ຈະ​ຖືກ​ເອີ້ນ​ຫຼາຍ​ທີ່​ສຸດ​ continuous-integration-team-scenarios-students, ມັນຕັ້ງຢູ່ໃນບັນຊີ GitHub ຂອງທ່ານແລະ URL ເບິ່ງຄືວ່ານີ້

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

ຂ້ອຍຈະໂທຫາທີ່ຢູ່ນີ້ງ່າຍໆ <URL репозитория>.

ວົງເລັບມຸມຄ້າຍຄື <тут> ຈະຫມາຍຄວາມວ່າທ່ານຕ້ອງທົດແທນການສະແດງອອກດັ່ງກ່າວດ້ວຍຄ່າທີ່ເຫມາະສົມ.

ໃຫ້ແນ່ໃຈວ່າ ການປະຕິບັດ GitHub ລວມໄປເຖິງບ່ອນເກັບມ້ຽນຫຼັກສູດນີ້. ຖ້າພວກເຂົາບໍ່ໄດ້ເປີດໃຊ້, ກະລຸນາເປີດໃຊ້ພວກມັນໂດຍການຄລິກໃສ່ປຸ່ມຂະຫນາດໃຫຍ່ຢູ່ເຄິ່ງກາງຂອງຫນ້າ, ທີ່ທ່ານສາມາດໄປຫາໄດ້ໂດຍການຄລິກໃສ່ການປະຕິບັດໃນການໂຕ້ຕອບ GitHub.

ທ່ານຈະບໍ່ສາມາດສໍາເລັດຫຼັກສູດປະຕິບັດຕາມຄໍາແນະນໍາຂອງຂ້ອຍຖ້າ GitHub Actions ບໍ່ໄດ້ຖືກເປີດໃຊ້.

ທ່ານສາມາດນໍາໃຊ້ຄວາມສາມາດຂອງ GitHub ເພື່ອສະແດງ Markdown ເພື່ອເບິ່ງສະຖານະປະຈຸບັນຂອງບັນຊີລາຍຊື່ທີ່ພວກເຮົາກໍາລັງຂຽນຢູ່ທີ່ນີ້

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

ກ່ຽວກັບຄໍາຕອບ

ໃນຂະນະທີ່ວິທີທີ່ດີທີ່ສຸດທີ່ຈະເຮັດສໍາເລັດຫຼັກສູດນີ້ແມ່ນເຮັດຕົວທ່ານເອງ, ທ່ານອາດຈະມີຄວາມຫຍຸ້ງຍາກບາງຢ່າງ.

ຖ້າທ່ານຮູ້ສຶກວ່າທ່ານບໍ່ເຂົ້າໃຈສິ່ງທີ່ຕ້ອງເຮັດແລະບໍ່ສາມາດສືບຕໍ່ໄດ້, ທ່ານສາມາດເບິ່ງໃນຫົວຂໍ້ solution, ເຊິ່ງຢູ່ໃນ repository ເລີ່ມຕົ້ນຂອງທ່ານ.
ກະລຸນາຢ່າຮວມ solution в master ໃນລະຫວ່າງຫຼັກສູດ. ທ່ານສາມາດນໍາໃຊ້ສາຂານີ້ເພື່ອຄິດສິ່ງທີ່ຕ້ອງເຮັດ, ຫຼືເພື່ອປຽບທຽບລະຫັດຂອງທ່ານກັບຜູ້ຂຽນ, ໂດຍໃຊ້ຄວາມສາມາດທັງຫມົດທີ່ Git ໃຫ້ພວກເຮົາ. ຖ້າທ່ານສູນເສຍໄປຫມົດແລ້ວ, ທ່ານສາມາດປ່ຽນສາຂາຂອງທ່ານໄດ້ຢ່າງສົມບູນ master ຢູ່ໃນສາຂາ solution ແລະຫຼັງຈາກນັ້ນ reset directory ເຮັດວຽກຂອງທ່ານກັບຂັ້ນຕອນຫຼັກສູດທີ່ທ່ານຕ້ອງການ.

ໃຊ້ພຽງແຕ່ນີ້ຖ້າທ່ານຕ້ອງການແທ້ໆ

ມອບລະຫັດຂອງທ່ານ

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 ເພື່ອຄິດອອກຄໍາຫມັ້ນສັນຍາທີ່ທ່ານຕ້ອງການ.
ທ່ານສາມາດຣີເຊັດໄດເລກະທໍລີທີ່ເຮັດວຽກຂອງທ່ານເປັນ commit ນີ້:

git reset --hard <the SHA you need>

ຖ້າທ່ານພໍໃຈກັບຜົນໄດ້ຮັບ, ໃນບາງຈຸດທ່ານຈະຕ້ອງເຜີຍແຜ່ສະບັບຂອງ repository ຂອງທ່ານກັບ repository ຫ່າງໄກສອກຫຼີກ. ຢ່າລືມລະບຸສາຂາຫ່າງໄກສອກຫຼີກຢ່າງຈະແຈ້ງເມື່ອທ່ານເຮັດສິ່ງນີ້.

git push --force origin master

ກະລຸນາສັງເກດວ່າພວກເຮົາໃຊ້ git push --force. ມັນຄົງຈະບໍ່ເປັນທີ່ເຈົ້າຢາກຈະເຮັດແບບນີ້ເລື້ອຍໆ, ແຕ່ພວກເຮົາມີສະຖານະການສະເພາະຢູ່ບ່ອນນີ້ກັບຜູ້ໃຊ້ບ່ອນເກັບມ້ຽນຜູ້ໜຶ່ງທີ່ເຂົ້າໃຈໃນສິ່ງທີ່ລາວເຮັດ.

ກຳລັງເລີ່ມເຮັດວຽກ

ໃຫ້ເລີ່ມຕົ້ນລວບລວມບັນຊີລາຍຊື່ຂອງຂັ້ນຕອນ CI ຂອງພວກເຮົາ. ໂດຍປົກກະຕິເຈົ້າຈະເລີ່ມຂັ້ນຕອນນີ້ໂດຍການກວດສອບເວີຊັນຫຼ້າສຸດຂອງລະຫັດຈາກບ່ອນເກັບຂໍ້ມູນທາງໄກ, ແຕ່ພວກເຮົາຍັງບໍ່ມີບ່ອນເກັບຂໍ້ມູນທ້ອງຖິ່ນເທື່ອ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງໂຄນມັນຈາກທາງໄກແທນ.

️ ວຽກງານ: ປັບປຸງບ່ອນເກັບມ້ຽນທ້ອງຖິ່ນ, ສ້າງສາຂາຈາກ master, ເລີ່ມເຮັດວຽກ

1. Clone the course repository from <URL репозитория>.
2. ແລ່ນ npm install ໃນ​ບັນ​ຊີ​ລາຍ​ການ repository​; ພວກເຮົາຕ້ອງການມັນເພື່ອຕິດຕັ້ງ 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
• ການທົດສອບຫນ່ວຍງານຊ້າ, ການທົດສອບອົງປະກອບໄວແລະການເຊື່ອມໂຍງ - on commit, in the CI pipeline
• ອົງປະກອບຊ້າແລະການທົດສອບການເຊື່ອມໂຍງ - ໃນທໍ່ CI
• ການທົດສອບຄວາມປອດໄພ, ການທົດສອບການໂຫຼດແລະການທົດສອບທີ່ໃຊ້ເວລາອື່ນໆຫຼືລາຄາແພງ - ໃນທໍ່ CI / CD, ແຕ່ວ່າພຽງແຕ່ໃນບາງໂຫມດ / ຂັ້ນຕອນ / ທໍ່ຂອງການກໍ່ສ້າງ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນເວລາທີ່ກະກຽມຜູ້ສະຫມັກປ່ອຍຫຼືໃນເວລາທີ່ດໍາເນີນການດ້ວຍຕົນເອງ.

️ໜ້າວຽກ

ຂ້ອຍຂໍແນະ ນຳ ໃຫ້ແລ່ນການທົດສອບດ້ວຍຕົນເອງໂດຍໃຊ້ ຄຳ ສັ່ງ npm test. ຫຼັງຈາກນັ້ນ, ໃຫ້ເພີ່ມ git hook ເພື່ອດໍາເນີນການທົດສອບຂອງພວກເຮົາກ່ຽວກັບຄໍາຫມັ້ນສັນຍາ. ມີການຈັບຫນຶ່ງ: Git hooks ບໍ່ໄດ້ຖືກພິຈາລະນາເປັນສ່ວນຫນຶ່ງຂອງ repository ແລະດັ່ງນັ້ນຈຶ່ງບໍ່ສາມາດ cloned ຈາກ GitHub ຄຽງຄູ່ກັບອຸປະກອນການສ່ວນທີ່ເຫຼືອຂອງຫຼັກສູດ. ເພື່ອຕິດຕັ້ງ hook, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການ install_hook.sh ຫຼືສຳເນົາໄຟລ໌ repo/hooks/pre-commit ໄປຫາໄດເລກະທໍລີທ້ອງຖິ່ນ .git/hooks/.
ເມື່ອທ່ານຫມັ້ນສັນຍາ, ທ່ານຈະເຫັນວ່າການທົດສອບຖືກດໍາເນີນການແລະພວກເຂົາກວດເບິ່ງວ່າມີຄໍາທີ່ແນ່ນອນຢູ່ໃນບັນຊີລາຍຊື່.

1. ດໍາເນີນການທົດສອບດ້ວຍຕົນເອງໂດຍການແລ່ນຄໍາສັ່ງ npm test ໃນໂຟເດີ repository ຂອງຫຼັກສູດຂອງທ່ານ. ກວດ​ສອບ​ວ່າ​ການ​ທົດ​ສອບ​ໄດ້​ສໍາ​ເລັດ​.
2. ຕັ້ງ hook commit (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, ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນບັນລຸໄດ້ໂດຍການເຜີຍແຜ່ວຽກງານໃຫ້ກັບສໍາເນົາສ່ວນບຸກຄົນຂອງ repository (ສ້ອມສ່ວນບຸກຄົນ) ຫຼືສາຂາສ່ວນບຸກຄົນ.

• ດ້ວຍສ້ອມ, ນັກພັດທະນາໄດ້ໂຄນບ່ອນເກັບມ້ຽນທີ່ແບ່ງປັນຈາກໄລຍະໄກ, ສ້າງສຳເນົາທາງໄກສ່ວນຕົວຂອງມັນ, ເຊິ່ງເອີ້ນກັນວ່າສ້ອມ. ຈາກນັ້ນມັນ clones repository ສ່ວນຕົວນີ້ເພື່ອເຮັດວຽກກັບທ້ອງຖິ່ນ. ໃນເວລາທີ່ວຽກງານແມ່ນສໍາເລັດແລະຄໍາຫມັ້ນສັນຍາ, ເຂົາ pushes ໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນສ້ອມຂອງຕົນ, ບ່ອນທີ່ເຂົາເຈົ້າມີໃຫ້ຄົນອື່ນແລະສາມາດໄດ້ຮັບການປະສົມປະສານເຂົ້າໄປໃນ repository ທົ່ວໄປ. ວິທີການນີ້ແມ່ນຖືກນໍາໃຊ້ທົ່ວໄປໃນໂຄງການແຫຼ່ງເປີດໃນ GitHub. ມັນຍັງຖືກນໍາໃຊ້ໃນຫຼັກສູດຂັ້ນສູງຂອງຂ້ອຍ [Team Work ແລະ CI ກັບ Git] (http://devops.redpill.solutions/).
• ວິທີການອື່ນແມ່ນໃຊ້ພຽງແຕ່ຫນຶ່ງ repository ຫ່າງໄກສອກຫຼີກແລະພຽງແຕ່ນັບສາຂາ master ບ່ອນເກັບມ້ຽນທີ່ແບ່ງປັນ "ຖືກປົກປ້ອງ". ໃນສະຖານະການນີ້, ນັກພັດທະນາສ່ວນບຸກຄົນເຜີຍແຜ່ລະຫັດຂອງພວກເຂົາໄປຫາສາຂາຂອງ repository ຫ່າງໄກສອກຫຼີກເພື່ອໃຫ້ຜູ້ອື່ນສາມາດເບິ່ງລະຫັດນີ້, ຖ້າທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຄໍາສັ່ງ, ປະສົມປະສານກັບມັນ. master ບ່ອນເກັບມ້ຽນທີ່ແບ່ງປັນ.

ໃນຫຼັກສູດສະເພາະນີ້, ພວກເຮົາຈະນໍາໃຊ້ຂະບວນການເຮັດວຽກທີ່ໃຊ້ສາຂາ.

ໃຫ້ເຜີຍແຜ່ລະຫັດຂອງພວກເຮົາ.

️ໜ້າວຽກ

• ເຜີຍແຜ່ການປ່ຽນແປງສາຂາຫ່າງໄກສອກຫຼີກທີ່ມີຊື່ດຽວກັນກັບສາຂາທີ່ເຮັດວຽກຂອງທ່ານ

ຄໍາສັ່ງ

git push --set-upstream origin feature

ສ້າງການຮ້ອງຂໍດຶງ

ສ້າງຄໍາຮ້ອງຂໍດຶງດ້ວຍຫົວຂໍ້ ຂັ້ນຕອນການທົບທວນຄືນ... ຕິດຕັ້ງ feature ເຊັ່ນ "ສາຂາຫົວ" ແລະ master ເຊັ່ນ "ສາຂາພື້ນຖານ".

ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຕິດຕັ້ງ master ໃນລາວ fork the repository ໃນຖານະເປັນ "ສາຂາພື້ນຖານ", ຂ້າພະເຈົ້າຈະບໍ່ຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍການປ່ຽນແປງຂອງອຸປະກອນການ repository.

ໃນ GitHub lingo, "ສາຂາພື້ນຖານ" ແມ່ນສາຂາທີ່ທ່ານອີງໃສ່ການເຮັດວຽກຂອງເຈົ້າ, ແລະ "ສາຂາຫົວ" ແມ່ນສາຂາທີ່ປະກອບດ້ວຍການປ່ຽນແປງທີ່ສະເຫນີ.

ປຶກສາຫາລືການປ່ຽນແປງ, ເພີ່ມຄໍາຫມັ້ນສັນຍາໃຫມ່ໃນຂະນະທີ່ການສົນທະນາຍັງສືບຕໍ່

ການຮ້ອງຂໍດຶງ (PR)

ການຮ້ອງຂໍດຶງ (PR) ແມ່ນວິທີການປຶກສາຫາລືແລະລະຫັດເອກະສານ, ເຊັ່ນດຽວກັນກັບການດໍາເນີນການທົບທວນລະຫັດ. ການຮ້ອງຂໍດຶງມີຊື່ຕາມວິທີການທົ່ວໄປຂອງການລວມເອົາການປ່ຽນແປງຂອງບຸກຄົນເຂົ້າໄປໃນລະຫັດລວມ. ໂດຍປົກກະຕິ, ບຸກຄົນທີ່ clones ສະຖານທີ່ເກັບມ້ຽນຢ່າງເປັນທາງການທາງໄກຂອງໂຄງການແລະເຮັດວຽກຢູ່ໃນລະຫັດທ້ອງຖິ່ນ. ຫຼັງຈາກນີ້, ລາວວາງລະຫັດໄວ້ໃນຄັງເກັບມ້ຽນຫ່າງໄກສອກຫຼີກສ່ວນຕົວຂອງລາວແລະຂໍໃຫ້ຜູ້ຮັບຜິດຊອບຂອງບ່ອນເກັບມ້ຽນຢ່າງເປັນທາງການມາເອົາ (ດຶງ) ລະ​ຫັດ​ຂອງ​ຕົນ​ເຂົ້າ​ໄປ​ໃນ repositories ທ້ອງ​ຖິ່ນ​ຂອງ​ເຂົາ​ເຈົ້າ​, ບ່ອນ​ທີ່​ເຂົາ​ເຈົ້າ​ທົບ​ທວນ​ຄືນ​ແລະ​ອາດ​ຈະ​ເຊື່ອມ​ໂຍງ (ລວມ) ລາວ. ແນວຄວາມຄິດນີ້ຍັງເປັນທີ່ຮູ້ຈັກໂດຍຊື່ອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, ການ​ຮ້ອງ​ຂໍ​ລວມ​.

ທ່ານບໍ່ຈໍາເປັນຕ້ອງໃຊ້ຄຸນສົມບັດການຮ້ອງຂໍດຶງຂອງ GitHub ຫຼືເວທີທີ່ຄ້າຍຄືກັນ. ທີມງານພັດທະນາອາດຈະໃຊ້ວິທີການສື່ສານອື່ນໆ, ລວມທັງການສື່ສານແບບໃບຫນ້າຕໍ່ຫນ້າ, ການໂທສຽງ, ຫຼືອີເມລ໌, ແຕ່ຍັງມີເຫດຜົນຈໍານວນຫນຶ່ງທີ່ຈະໃຊ້ການຮ້ອງຂໍດຶງຮູບແບບເວທີສົນທະນາ. ນີ້ແມ່ນບາງສ່ວນຂອງພວກເຂົາ:

• ການສົນທະນາທີ່ມີການຈັດຕັ້ງທີ່ກ່ຽວຂ້ອງກັບການປ່ຽນແປງລະຫັດສະເພາະ;
• ເປັນສະຖານທີ່ເພື່ອເບິ່ງຄໍາຄຶດຄໍາເຫັນກ່ຽວກັບການເຮັດວຽກໃນຄວາມຄືບຫນ້າຈາກທັງ autotesters ແລະເພື່ອນຮ່ວມງານ;
• ຢ່າງເປັນທາງການຂອງການກວດສອບລະຫັດ;
• ດັ່ງນັ້ນຕໍ່ມາເຈົ້າສາມາດຊອກຫາເຫດຜົນແລະການພິຈາລະນາທີ່ຢູ່ເບື້ອງຫລັງລະຫັດນີ້ຫຼືຊິ້ນນັ້ນ.

ໂດຍປົກກະຕິທ່ານສ້າງຄໍາຮ້ອງຂໍດຶງໃນເວລາທີ່ທ່ານຈໍາເປັນຕ້ອງສົນທະນາບາງສິ່ງບາງຢ່າງຫຼືໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນ. ຕົວຢ່າງ, ຖ້າທ່ານກໍາລັງເຮັດວຽກກ່ຽວກັບລັກສະນະທີ່ສາມາດປະຕິບັດໄດ້ຫຼາຍກວ່າຫນຶ່ງວິທີ, ທ່ານສາມາດສ້າງຄໍາຮ້ອງຂໍດຶງກ່ອນທີ່ຈະຂຽນລະຫັດທໍາອິດເພື່ອແບ່ງປັນແນວຄວາມຄິດຂອງທ່ານແລະປຶກສາຫາລືກ່ຽວກັບແຜນການຂອງທ່ານກັບຜູ້ຮ່ວມມືຂອງທ່ານ. ຖ້າການເຮັດວຽກແມ່ນງ່າຍດາຍ, ການຮ້ອງຂໍດຶງແມ່ນເປີດເມື່ອບາງສິ່ງບາງຢ່າງໄດ້ເຮັດແລ້ວ, ມຸ່ງຫມັ້ນ, ແລະສາມາດສົນທະນາໄດ້. ໃນບາງສະຖານະການ, ທ່ານອາດຈະຕ້ອງການເປີດ PR ພຽງແຕ່ສໍາລັບເຫດຜົນການຄວບຄຸມຄຸນນະພາບ: ເພື່ອດໍາເນີນການທົດສອບອັດຕະໂນມັດຫຼືເລີ່ມຕົ້ນການກວດສອບລະຫັດ. ບໍ່ວ່າເຈົ້າຕັດສິນໃຈຫຍັງ, ຢ່າລືມ @mention ຄົນທີ່ເຈົ້າຕ້ອງການການອະນຸມັດໃນຄໍາຮ້ອງຂໍດຶງຂອງເຈົ້າ.

ໂດຍປົກກະຕິ, ເມື່ອສ້າງ PR, ທ່ານເຮັດດັ່ງຕໍ່ໄປນີ້.

• ຊີ້ບອກສິ່ງທີ່ທ່ານສະເໜີໃຫ້ປ່ຽນແປງ ແລະຢູ່ໃສ.
• ຂຽນລາຍລະອຽດອະທິບາຍຈຸດປະສົງຂອງການປ່ຽນແປງ. ທ່ານອາດຈະຕ້ອງການ:
  • ເພີ່ມສິ່ງທີ່ສໍາຄັນທີ່ບໍ່ຊັດເຈນຈາກລະຫັດ, ຫຼືບາງສິ່ງບາງຢ່າງທີ່ເປັນປະໂຫຍດສໍາລັບການເຂົ້າໃຈສະພາບການ, ເຊັ່ນ: #bugs ທີ່ກ່ຽວຂ້ອງແລະຕົວເລກຄໍາຫມັ້ນສັນຍາ;
  • @mention ໃຜ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​ທີ່​ຈະ​ເລີ່ມ​ຕົ້ນ​ການ​ເຮັດ​ວຽກ​ກັບ, ຫຼື​ທ່ານ​ສາ​ມາດ @mention ໃຫ້​ເຂົາ​ເຈົ້າ​ໃນ​ຄໍາ​ຄິດ​ເຫັນ​ພາຍ​ຫຼັງ;
  • ຂໍໃຫ້ເພື່ອນຮ່ວມງານຊ່ວຍໃນບາງສິ່ງບາງຢ່າງຫຼືກວດເບິ່ງບາງຢ່າງສະເພາະ.

ເມື່ອທ່ານເປີດ PR, ການທົດສອບທີ່ຖືກຕັ້ງຄ່າໃຫ້ດໍາເນີນການໃນກໍລະນີນີ້ຈະຖືກປະຕິບັດ. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ຈະເປັນຊຸດການທົດສອບດຽວກັນທີ່ພວກເຮົາດໍາເນີນການຢູ່ໃນທ້ອງຖິ່ນ, ແຕ່ໃນໂຄງການທີ່ແທ້ຈິງອາດຈະມີການທົດສອບແລະການກວດສອບເພີ່ມເຕີມ.

ກະລຸນາລໍຖ້າໃນຂະນະທີ່ການທົດສອບສໍາເລັດ. ທ່ານສາມາດເບິ່ງສະຖານະພາບຂອງການທົດສອບຢູ່ດ້ານລຸ່ມຂອງການສົນທະນາ PR ໃນການໂຕ້ຕອບ GitHub. ສືບຕໍ່ເມື່ອການທົດສອບສໍາເລັດ.

️ ເພີ່ມບັນທຶກກ່ຽວກັບການສຸ່ມຂອງບັນຊີລາຍຊື່ຂອງຂັ້ນຕອນ CI

ບັນຊີລາຍຊື່ທີ່ໃຊ້ໃນຫຼັກສູດນີ້ແມ່ນ arbitrary ແລະ subjective, ພວກເຮົາຄວນຈະເພີ່ມບັນທຶກກ່ຽວກັບເລື່ອງນີ້.

️ ວຽກງານ: ສ້າງການຮ້ອງຂໍດຶງສໍາລັບຄໍາເຫັນນີ້

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 ກັບ repository ຫ່າງໄກສອກຫຼີກ.
6. ສ້າງຄໍາຮ້ອງຂໍດຶງທີ່ມີຊື່ ເພີ່ມຂໍ້ສັງເກດ ມີສາຂາຫົວ bugfix ແລະສາຂາພື້ນຖານmaster.

ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຕິດຕັ້ງ master ໃນລາວ fork the repository ໃນຖານະເປັນ "ສາຂາພື້ນຖານ", ຂ້າພະເຈົ້າຈະບໍ່ຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍການປ່ຽນແປງຂອງອຸປະກອນການ repository.

ນີ້ແມ່ນສິ່ງທີ່ repository ຂອງທ່ານຄວນເບິ່ງຄື.

ຄໍາສັ່ງ

# Переключитесь на ветку 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 hook ກ່ອນຫນ້ານີ້, ການທົດສອບທີ່ເພີ່ມໃຫມ່ຈະຖືກດໍາເນີນ, ຈະລົ້ມເຫລວ, ແລະບໍ່ມີຫຍັງຈະຫມັ້ນສັນຍາ. ໃຫ້ສັງເກດວ່ານີ້ແມ່ນວິທີທີ່ພວກເຮົາຮູ້ວ່າການທົດສອບຂອງພວກເຮົາແມ່ນການທົດສອບບາງສິ່ງບາງຢ່າງ. ຫນ້າສົນໃຈ, ຖ້າພວກເຮົາເລີ່ມຕົ້ນດ້ວຍລະຫັດກ່ອນການທົດສອບ, ການສອບເສັງຜ່ານອາດຈະຫມາຍຄວາມວ່າລະຫັດເຮັດວຽກຕາມທີ່ຄາດໄວ້, ຫຼືວ່າການທົດສອບບໍ່ໄດ້ທົດສອບຫຍັງເລີຍ. ນອກຈາກນັ້ນ, ຖ້າພວກເຮົາບໍ່ໄດ້ຂຽນການທົດສອບໃນຕອນທໍາອິດ, ພວກເຮົາອາດຈະລືມກ່ຽວກັບພວກມັນທັງຫມົດ, ເພາະວ່າບໍ່ມີຫຍັງຈະເຕືອນພວກເຮົາກ່ຽວກັບມັນ.

ການທົດສອບການພັດທະນາແບບຂັບເຄື່ອນ (TDD)

TDD ແນະນໍາໃຫ້ຂຽນການທົດສອບກ່ອນລະຫັດ. ຂະບວນການເຮັດວຽກແບບປົກກະຕິໂດຍໃຊ້ TDD ເບິ່ງຄືວ່ານີ້.

1. ເພີ່ມການທົດສອບ.
2. ດໍາເນີນການທົດສອບທັງຫມົດແລະໃຫ້ແນ່ໃຈວ່າການທົດສອບໃຫມ່ລົ້ມເຫລວ.
3. ຂຽນລະຫັດ.
4. ດໍາເນີນການທົດສອບ, ໃຫ້ແນ່ໃຈວ່າການທົດສອບທັງຫມົດຜ່ານ.
5. ປັບປ່ຽນລະຫັດຂອງເຈົ້າ.
6. ເຮັດຊ້ຳ.

ເນື່ອງຈາກວ່າຜົນຂອງການທົດສອບທີ່ລົ້ມເຫລວມັກຈະສະແດງໃຫ້ເຫັນເປັນສີແດງ, ແລະສິ່ງທີ່ຜ່ານມັກຈະສະແດງໃຫ້ເຫັນເປັນສີຂຽວ, ວົງຈອນຍັງເປັນທີ່ຮູ້ຈັກເປັນສີແດງ - ສີຂຽວ - refactor.

️ໜ້າວຽກ

ທໍາອິດ, ພະຍາຍາມເຮັດການທົດສອບແລະປ່ອຍໃຫ້ພວກເຂົາລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນຕື່ມແລະປະຕິບັດຂໍ້ຄວາມຂອງບັນຊີລາຍຊື່ຂັ້ນຕອນ CI ຕົວຂອງມັນເອງ. ທ່ານຈະເຫັນວ່າການທົດສອບແມ່ນຜ່ານ ("ສີຂຽວ").
ຫຼັງຈາກນັ້ນ, ເຜີຍແຜ່ລະຫັດໃຫມ່ກັບ repository ຫ່າງໄກສອກຫຼີກແລະສັງເກດເບິ່ງການທົດສອບດໍາເນີນການໃນການໂຕ້ຕອບ 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 hook ໄດ້ຖືກຕິດຕັ້ງ, ຄວາມພະຍາຍາມຂອງຄໍາຫມັ້ນສັນຍາຈະລົ້ມເຫລວ.
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. ດ້ວຍເຫດຜົນນີ້, ພວກເຮົາບໍ່ສາມາດພຽງແຕ່ rewind HEAD master ໃນຕອນທ້າຍຂອງກະທູ້ feature. ໃນສະຖານະການນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ລວມຫຼືນໍາໃຊ້ຄໍາຫມັ້ນສັນຍາ feature ຟື້ນຟູ master. GitHub ຕົວຈິງສາມາດປະຕິບັດການຜະສົມຜະສານອັດຕະໂນມັດຖ້າບໍ່ມີຂໍ້ຂັດແຍ່ງ. ອະນິຈາ, ໃນສະຖານະການຂອງພວກເຮົາ, ທັງສອງສາຂາມີການປ່ຽນແປງທີ່ແຂ່ງຂັນໃນເອກະສານ ci.md. ສະຖານະການນີ້ເອີ້ນວ່າການຂັດກັນ, ແລະພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂມັນດ້ວຍຕົນເອງ.

ລວມຫຼື rebase

ປ້ອນຂໍ້ມູນ

• ສ້າງຄໍາຫມັ້ນສັນຍາລວມເພີ່ມເຕີມແລະບັນທຶກປະຫວັດການເຮັດວຽກ.
  • ຮັກສາຄໍາຫມັ້ນສັນຍາຕົ້ນສະບັບຂອງສາຂາທີ່ມີເວລາເດີມແລະຜູ້ຂຽນຂອງພວກເຂົາ.
  • ບັນທຶກ SHA ຂອງຄໍາຫມັ້ນສັນຍາແລະການເຊື່ອມຕໍ່ກັບພວກເຂົາໃນການສົນທະນາການຮ້ອງຂໍການປ່ຽນແປງ.
• ຕ້ອງການການແກ້ໄຂຂໍ້ຂັດແຍ່ງຄັ້ງດຽວ.
• ເຮັດໃຫ້ເລື່ອງບໍ່ເປັນເສັ້ນ.
  • ເລື່ອງສາມາດອ່ານໄດ້ຍາກເນື່ອງຈາກສາຂາຈໍານວນຫລາຍ (reminiscent ຂອງສາຍ IDE).
  • ເຮັດໃຫ້ການດີບັກອັດຕະໂນມັດຍາກຂຶ້ນ, e.g. git bisect ຫນ້ອຍທີ່ເປັນປະໂຫຍດ - ມັນພຽງແຕ່ຈະຊອກຫາຄໍາຫມັ້ນສັນຍາ merge.

ຄ່າຕອບແທນ

• Replays commits ຈາກສາຂາປະຈຸບັນຢູ່ເທິງສຸດຂອງສາຂາພື້ນຖານຫນຶ່ງຫຼັງຈາກອື່ນ.
  • ຄໍາຫມັ້ນສັນຍາໃຫມ່ກັບ 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. ກົດ "ລຶບສາຂາ" ເພາະວ່າພວກເຮົາບໍ່ຕ້ອງການມັນອີກຕໍ່ໄປ.

ນີ້ແມ່ນບ່ອນເກັບມ້ຽນຂອງເຈົ້າໃນຂະນະນີ້

ຜະລິດຕະພັນຜິດພາດ

ມັນໄດ້ຖືກກ່າວວ່າ "ການທົດສອບສາມາດຖືກນໍາໃຊ້ເພື່ອສະແດງໃຫ້ເຫັນເຖິງຄວາມຜິດພາດ, ແຕ່ບໍ່ເຄີຍສະແດງໃຫ້ເຫັນເຖິງການຂາດຂອງເຂົາເຈົ້າ." ເຖິງແມ່ນວ່າພວກເຮົາມີການທົດສອບແລະພວກເຂົາສະແດງໃຫ້ເຫັນວ່າພວກເຮົາບໍ່ມີຄວາມຜິດພາດ, ແມງໄມ້ insidious ໄດ້ເຂົ້າໄປໃນການຜະລິດ.

ໃນສະຖານະການເຊັ່ນນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ດູແລ:

• ສິ່ງທີ່ຖືກນໍາໃຊ້ໃນການຜະລິດ;
• ລະຫັດໃນກະທູ້ master ມີຄວາມຜິດພາດ, ຈາກທີ່ນັກພັດທະນາສາມາດເລີ່ມຕົ້ນການເຮັດວຽກໃຫມ່.

ຂ້ອຍຄວນມ້ວນຄືນຫຼືແກ້ໄຂມັນໃນສະບັບຕໍ່ໄປບໍ?

ການມ້ວນຄືນແມ່ນຂະບວນການຂອງການນໍາໃຊ້ສະບັບກ່ອນຫນ້າທີ່ດີທີ່ຮູ້ຈັກກັບການຜະລິດແລະການກັບຄືນຄໍາຫມັ້ນສັນຍາທີ່ມີຄວາມຜິດພາດ. "ການແກ້ໄຂໄປຂ້າງຫນ້າ" ແມ່ນການເພີ່ມເຕີມຂອງການແກ້ໄຂ master ແລະ​ການ​ນໍາ​ໃຊ້​ສະ​ບັບ​ໃຫມ່​ໃນ​ທັນ​ທີ​ທີ່​ເປັນ​ໄປ​ໄດ້​. ເນື່ອງຈາກວ່າ APIs ແລະ schemas ຖານຂໍ້ມູນມີການປ່ຽນແປງຍ້ອນວ່າລະຫັດຖືກນໍາໄປໃຊ້ໃນການຜະລິດ, ດ້ວຍການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງແລະການຄຸ້ມຄອງການທົດສອບທີ່ດີ, ໂດຍທົ່ວໄປແລ້ວການມ້ວນຄືນແມ່ນມີຄວາມຫຍຸ້ງຍາກແລະມີຄວາມສ່ຽງຫຼາຍກ່ວາການແກ້ໄຂໃນສະບັບຕໍ່ໄປ.

ເນື່ອງຈາກວ່າ rolling back ບໍ່ມີຄວາມສ່ຽງໃດໆໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຈະໄປເສັ້ນທາງນີ້, ເນື່ອງຈາກວ່າມັນອະນຸຍາດໃຫ້ພວກເຮົາ

• ແກ້ໄຂຂໍ້ຜິດພາດກ່ຽວກັບຜະລິດຕະພັນໄວເທົ່າທີ່ເປັນໄປໄດ້;
• ເຮັດໃຫ້ລະຫັດໃນ master ທັນທີທີ່ເຫມາະສົມສໍາລັບການເລີ່ມຕົ້ນວຽກເຮັດງານທໍາໃຫມ່.

️ໜ້າວຽກ

1. ປ່ຽນເປັນສາຂາ master ໃນທ້ອງຖິ່ນ.
2. ປັບປຸງບ່ອນເກັບມ້ຽນທ້ອງຖິ່ນຈາກບ່ອນເກັບຂໍ້ມູນທາງໄກ.
3. ກັບຄືນຄໍາຫມັ້ນສັນຍາການລວມ PR ຂັ້ນຕອນການທົບທວນຄືນ в master.
4. ເຜີຍແຜ່ການປ່ຽນແປງໄປຍັງບ່ອນເກັບຂໍ້ມູນທາງໄກ.

ນີ້​ແມ່ນ​ປະ​ຫວັດ​ສາດ​ຂອງ repository ທີ່​ມີ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ການ​ລວມ​ເຂົ້າ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​

ຄໍາສັ່ງ

# Переключитесь на ветку 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" ຕໍ່ໄປອີກແລ້ວຫຼັງຈາກ reverting commit.

ແກ້ໄຂບັນຊີລາຍຊື່ຂອງຂັ້ນຕອນ CI ແລະສົ່ງຄືນເປັນຕົ້ນສະບັບ

ພວກ​ເຮົາ​ໄດ້​ຍົກ​ເລີກ​ຄຳ​ໝັ້ນ​ສັນ​ຍາ​ລວມ​ຂອງ​ສາ​ຂາ​ຢ່າງ​ສິ້ນ​ເຊີງ. feature. ຂ່າວດີແມ່ນວ່າພວກເຮົາບໍ່ມີຂໍ້ຜິດພາດໃນຕອນນີ້ master. ຂ່າວບໍ່ດີແມ່ນວ່າບັນຊີລາຍຊື່ອັນລ້ໍາຄ່າຂອງພວກເຮົາຂອງຂັ້ນຕອນການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແມ່ນຫມົດໄປ. ດັ່ງນັ້ນ, ໂດຍຫລັກການແລ້ວ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ນໍາໃຊ້ການແກ້ໄຂກັບຄໍາຫມັ້ນສັນຍາຈາກ 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. ເອົາຂໍ້ຄວາມ "ກັບແມງໄມ້ sneaky" ໃນ 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 ໃນລາວ fork the repository ໃນຖານະເປັນ "ສາຂາພື້ນຖານ", ຂ້າພະເຈົ້າຈະບໍ່ຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍການປ່ຽນແປງຂອງອຸປະກອນການ repository.

ອະນຸມັດການຮ້ອງຂໍດຶງ "ການແກ້ໄຂຄຸນນະສົມບັດ"

ຂອບໃຈສໍາລັບການແກ້ໄຂ! ກະລຸນາອະນຸມັດການປ່ຽນແປງ master ຈາກການຮ້ອງຂໍດຶງ.

️ໜ້າວຽກ

1. ກົດ "ການ​ຮ້ອງ​ຂໍ​ການ​ດຶງ​ລວມ​"​.
2. ກົດ "ຢືນຢັນການລວມ".
3. ກົດ "ລຶບສາຂາ" ເພາະວ່າພວກເຮົາບໍ່ຕ້ອງການມັນອີກຕໍ່ໄປ.

ນີ້ແມ່ນສິ່ງທີ່ທ່ານຄວນມີໃນເວລານີ້.

ຊົມເຊີຍ!

ທ່ານໄດ້ສຳເລັດຂັ້ນຕອນທັງໝົດທີ່ຄົນທົ່ວໄປເຮັດໃນລະຫວ່າງການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ.

ຖ້າທ່ານສັງເກດເຫັນບັນຫາໃດໆກັບຫຼັກສູດຫຼືຮູ້ວິທີການປັບປຸງມັນ, ກະລຸນາສ້າງບັນຫາໃນ repositories ກັບອຸປະກອນຫຼັກສູດ. ຫຼັກສູດນີ້ຍັງມີ ສະບັບໂຕ້ຕອບ ໃຊ້ GitHub Learning Lab ເປັນເວທີ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com