คุณได้เรียนรู้คำสั่ง Git แล้ว แต่อยากจินตนาการว่าการบูรณาการอย่างต่อเนื่อง (CI) ทำงานอย่างไรในความเป็นจริง หรือบางทีคุณอาจต้องการเพิ่มประสิทธิภาพกิจกรรมประจำวันของคุณ? หลักสูตรนี้จะมอบทักษะเชิงปฏิบัติในการบูรณาการอย่างต่อเนื่องโดยใช้พื้นที่เก็บข้อมูล GitHub หลักสูตรนี้ไม่ได้ตั้งใจให้เป็นวิซาร์ดที่คุณสามารถคลิกผ่านได้ ในทางกลับกัน คุณจะดำเนินการแบบเดียวกับที่ผู้คนทำในที่ทำงาน ในลักษณะเดียวกับที่พวกเขาทำ ฉันจะอธิบายทฤษฎีเมื่อคุณทำตามขั้นตอนที่เกี่ยวข้อง

พวกเราทำอะไร?

ขณะที่เราดำเนินการ เราจะค่อยๆ สร้างรายการขั้นตอน CI ทั่วไป ซึ่งเป็นวิธีที่ดีในการจดจำรายการนี้ กล่าวอีกนัยหนึ่ง เราจะสร้างรายการการดำเนินการที่นักพัฒนาทำในขณะที่ทำการบูรณาการอย่างต่อเนื่อง ทำการบูรณาการอย่างต่อเนื่อง นอกจากนี้เรายังจะใช้ชุดการทดสอบง่ายๆ เพื่อให้กระบวนการ CI ของเราใกล้เคียงกับของจริงมากขึ้น

GIF นี้แสดงการคอมมิตในพื้นที่เก็บข้อมูลของคุณตามแผนผังเมื่อคุณดำเนินการผ่านหลักสูตร อย่างที่คุณเห็นไม่มีอะไรซับซ้อนที่นี่และจำเป็นที่สุดเท่านั้น

คุณจะต้องผ่านสถานการณ์ CI มาตรฐานต่อไปนี้:

• ทำงานกับฟีเจอร์
• การใช้การทดสอบอัตโนมัติเพื่อรับรองคุณภาพ
• การดำเนินงานตามลำดับความสำคัญ
• การแก้ไขข้อขัดแย้งเมื่อรวมสาขา (ผสานข้อขัดแย้ง);
• มีข้อผิดพลาดเกิดขึ้นในสภาพแวดล้อมการผลิต

คุณจะได้เรียนรู้อะไร?

คุณจะสามารถตอบคำถามต่อไปนี้:

• การบูรณาการอย่างต่อเนื่อง (CI) คืออะไร?
• การทดสอบอัตโนมัติประเภทใดที่ใช้ใน CI และตอบสนองต่อการดำเนินการใดบ้าง
• คำขอดึงคืออะไรและจำเป็นเมื่อใด
• Test Driven Development (TDD) คืออะไร และเกี่ยวข้องกับ CI อย่างไร
• ฉันควรรวมหรือรีบูตการเปลี่ยนแปลงหรือไม่
• ย้อนกลับหรือแก้ไขในเวอร์ชันถัดไป?

ตอนแรกฉันแปลสิ่งต่าง ๆ เช่น "คำขอดึง" ทุกที่ แต่ด้วยเหตุนี้ฉันจึงตัดสินใจส่งคืนวลีเป็นภาษาอังกฤษในบางที่เพื่อลดระดับความบ้าคลั่งในข้อความ บางครั้งฉันจะใช้ “programmer surzhik” เหมือนกริยาวิเศษสุด “commit” ที่ผู้คนใช้มันในที่ทำงานจริงๆ

การบูรณาการอย่างต่อเนื่องคืออะไร?

การบูรณาการอย่างต่อเนื่องหรือ CI คือแนวทางปฏิบัติทางเทคนิคที่สมาชิกในทีมแต่ละคนรวมโค้ดของตนไว้ในที่เก็บข้อมูลทั่วไปอย่างน้อยวันละครั้ง และอย่างน้อยโค้ดผลลัพธ์จะต้องถูกสร้างขึ้นโดยไม่มีข้อผิดพลาด

มีความขัดแย้งเกี่ยวกับคำนี้

ประเด็นของการโต้แย้งคือความถี่ของการบูรณาการ บางคนแย้งว่าการรวมโค้ดเพียงวันละครั้งไม่เพียงพอที่จะบูรณาการอย่างต่อเนื่อง ตัวอย่างคือทีมที่ทุกคนรับโค้ดใหม่ในตอนเช้าและรวมเข้ากับโค้ดครั้งเดียวในตอนเย็น แม้ว่านี่จะเป็นข้อโต้แย้งที่สมเหตุสมผล แต่เป็นที่ยอมรับกันโดยทั่วไปว่าคำจำกัดความวันละครั้งนั้นใช้ได้จริง มีความเฉพาะเจาะจง และเหมาะสำหรับทีมที่มีขนาดต่างกัน

ข้อโต้แย้งอีกประการหนึ่งคือ C++ ไม่ใช่ภาษาเดียวที่ใช้ในการพัฒนาอีกต่อไป และเพียงแค่ต้องใช้แอสเซมบลีที่ปราศจากข้อผิดพลาดเนื่องจากวิธีการตรวจสอบยังอ่อนแอ การทดสอบบางชุด (เช่น การทดสอบหน่วยที่ดำเนินการในเครื่อง) จะต้องดำเนินการให้สำเร็จด้วย ในขณะนี้ ชุมชนกำลังก้าวไปสู่การสร้างข้อกำหนดนี้ และในอนาคต "การทดสอบ build + unit" อาจจะกลายเป็นเรื่องปกติหากยังไม่ได้เป็นเช่นนั้น

การบูรณาการอย่างต่อเนื่อง แตกต่างจาก การส่งมอบอย่างต่อเนื่อง (Continuous Delivery, CD) โดยที่ไม่จำเป็นต้องปล่อยผู้สมัครหลังจากแต่ละรอบการรวมระบบ

รายการขั้นตอนที่เราจะใช้ตลอดหลักสูตร

1. ดึงรหัสล่าสุด สร้างสาขาจาก master. เริ่มทำงาน.
2. สร้างความมุ่งมั่นในสาขาใหม่ของคุณ สร้างและทดสอบในเครื่อง ผ่าน? ไปที่ขั้นตอนถัดไป ล้มเหลว? แก้ไขข้อผิดพลาดหรือการทดสอบแล้วลองอีกครั้ง
3. พุชไปยังพื้นที่เก็บข้อมูลระยะไกลหรือสาขาระยะไกลของคุณ
4. สร้างคำขอดึง หารือเกี่ยวกับการเปลี่ยนแปลง เพิ่มความมุ่งมั่นเพิ่มเติมเมื่อการสนทนาดำเนินต่อไป ทำการทดสอบผ่านสาขาฟีเจอร์
5. ผสาน / รีบูตคอมมิตจากต้นแบบ ทำการทดสอบผ่านผลการผสาน
6. ปรับใช้จากสาขาฟีเจอร์ไปจนถึงการใช้งานจริง
7. หากทุกอย่างทำงานได้ดีในช่วงระยะเวลาหนึ่ง ให้รวมการเปลี่ยนแปลงเป็นข้อมูลหลัก

️การเตรียมตัว

ตรวจสอบให้แน่ใจว่าคุณมีซอฟต์แวร์ที่ถูกต้อง

คุณจะต้องมีหลักสูตรนี้ Node.js и ลูกค้าคอมไพล์.

คุณสามารถใช้ไคลเอนต์ Git ใดก็ได้ แต่ฉันจะให้เฉพาะคำสั่งสำหรับบรรทัดคำสั่งเท่านั้น

ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งไคลเอนต์ Git ที่รองรับบรรทัดคำสั่ง

หากคุณยังไม่มีไคลเอ็นต์ Git ที่รองรับบรรทัดคำสั่ง คุณสามารถดูคำแนะนำในการติดตั้งได้ ที่นี่.

เตรียมพื้นที่เก็บข้อมูล

คุณจะต้องสร้างสำเนาส่วนตัว (ทางแยก) ที่เก็บเทมเพลตพร้อมโค้ดสำหรับหลักสูตร บน GitHub เราตกลงที่จะเรียกสำเนาส่วนตัวนี้ ที่เก็บหลักสูตร.

เสร็จแล้ว? หากคุณไม่ได้เปลี่ยนการตั้งค่าเริ่มต้น เป็นไปได้มากว่าพื้นที่เก็บข้อมูลหลักสูตรของคุณจะถูกเรียก 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ซึ่งอยู่ในที่เก็บเริ่มต้นของคุณ
กรุณาอย่ารวมกัน 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)
  • ระหว่างการประกอบ (เมื่อจำเป็นต้องรวบรวม)
  • เมื่อกระทำ;
  • เมื่อเผยแพร่ไปยังพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

• บนบิลด์เซิร์ฟเวอร์หรือสภาพแวดล้อมบิลด์:
  • เมื่อโค้ดถูกเผยแพร่ไปยังสาขา/พื้นที่เก็บข้อมูลส่วนบุคคล
  • รหัสในชุดข้อความนี้กำลังได้รับการทดสอบ
  • มีการทดสอบผลลัพธ์ที่เป็นไปได้ของการควบรวมกิจการ (โดยปกติกับ master).
  • เป็นขั้นตอนการบูรณาการอย่างต่อเนื่อง/ไปป์ไลน์การส่งมอบอย่างต่อเนื่อง

โดยทั่วไป ยิ่งชุดทดสอบรันเร็วเท่าไร คุณก็ยิ่งสามารถรันชุดทดสอบได้บ่อยมากขึ้นเท่านั้น การกระจายตัวของเวทีทั่วไปอาจมีลักษณะเช่นนี้

• การทดสอบหน่วยอย่างรวดเร็ว - ระหว่างการสร้างในไปป์ไลน์ CI
• การทดสอบหน่วยที่ช้า ส่วนประกอบที่รวดเร็ว และการทดสอบการรวม - เมื่อคอมมิต ในไปป์ไลน์ CI
• การทดสอบส่วนประกอบและการรวมที่ช้า - ในไปป์ไลน์ CI
• การทดสอบความปลอดภัย การทดสอบโหลด และการทดสอบอื่นๆ ที่ใช้เวลานานหรือมีราคาแพง - ในไปป์ไลน์ CI/CD แต่เฉพาะในบางโหมด/ระยะ/ไปป์ไลน์ของบิลด์ เช่น เมื่อเตรียมตัวเลือกการเปิดตัวหรือเมื่อรันด้วยตนเอง

️งาน

ฉันขอแนะนำให้รันการทดสอบด้วยตนเองก่อนโดยใช้คำสั่ง npm test. หลังจากนั้น เรามาเพิ่ม git hook เพื่อรันการทดสอบการคอมมิตของเรา สิ่งหนึ่งที่พบได้คือ Git hooks ไม่ถือว่าเป็นส่วนหนึ่งของ repository ดังนั้นจึงไม่สามารถโคลนจาก GitHub พร้อมกับเนื้อหาส่วนที่เหลือของหลักสูตรได้ ในการติดตั้ง hook คุณต้องรัน 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 จะประสบความสำเร็จได้โดยการเผยแพร่งานไปยังสำเนาส่วนตัวของพื้นที่เก็บข้อมูล (ทางแยกส่วนบุคคล) หรือสาขาส่วนบุคคล

• ด้วย Fork นักพัฒนาจะโคลนพื้นที่เก็บข้อมูลที่ใช้ร่วมกันระยะไกล โดยสร้างสำเนาระยะไกลส่วนตัวของพื้นที่ดังกล่าว หรือที่เรียกว่า Fork จากนั้นจะโคลนพื้นที่เก็บข้อมูลส่วนตัวนี้เพื่อทำงานร่วมกับในเครื่อง เมื่องานเสร็จสมบูรณ์และ Commit เสร็จสิ้น เขาจะผลักมันเข้าไปใน Fork ซึ่งคนอื่นๆ จะสามารถเข้าถึงได้และสามารถรวมเข้ากับ Repository ทั่วไปได้ แนวทางนี้ใช้กันทั่วไปในโครงการโอเพ่นซอร์สบน GitHub นอกจากนี้ยังใช้ในหลักสูตรขั้นสูงของฉัน [การทำงานเป็นทีมและ CI พร้อม Git] (http://devops.redpill.solutions/).
• อีกวิธีหนึ่งคือใช้พื้นที่เก็บข้อมูลระยะไกลเพียงแห่งเดียวและนับเฉพาะสาขาเท่านั้น master พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน "ป้องกัน" ในสถานการณ์นี้ นักพัฒนาแต่ละรายเผยแพร่โค้ดของตนไปยังสาขาของพื้นที่เก็บข้อมูลระยะไกลเพื่อให้ผู้อื่นสามารถดูโค้ดนี้ได้ หากทุกอย่างเป็นไปตามลำดับ ให้รวมเข้ากับ master พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

ในหลักสูตรนี้โดยเฉพาะ เราจะใช้เวิร์กโฟลว์ที่ใช้สาขา

มาเผยแพร่โค้ดของเรากัน

️งาน

• เผยแพร่การเปลี่ยนแปลงไปยังสาขาระยะไกลด้วยชื่อเดียวกันกับสาขาการทำงานของคุณ

Команды

git push --set-upstream origin feature

สร้างคำขอดึง

สร้างคำขอดึงพร้อมชื่อ ทบทวนขั้นตอน... ติดตั้ง feature เช่น "สาขาหัว" และ master เหมือน "สาขาฐาน"

ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งแล้ว master ในของเขา แยกที่เก็บ ในฐานะ "สาขาฐาน" ฉันจะไม่ตอบสนองต่อคำร้องขอให้เปลี่ยนแปลงคลังสื่อการเรียนการสอนของหลักสูตร

ในศัพท์แสง GitHub "สาขาฐาน" คือสาขาที่คุณใช้เป็นฐานงานของคุณและ "สาขาหลัก" คือสาขาที่มีการเปลี่ยนแปลงที่เสนอ

หารือเกี่ยวกับการเปลี่ยนแปลง เพิ่มการคอมมิตใหม่ในขณะที่การสนทนาดำเนินต่อไป

คำขอดึง (PR)

คำขอดึง (PR) เป็นวิธีการอภิปรายและจัดทำเอกสารโค้ดตลอดจนดำเนินการตรวจสอบโค้ด คำขอดึงได้รับการตั้งชื่อตามวิธีทั่วไปในการรวมการเปลี่ยนแปลงแต่ละรายการเข้ากับโค้ดโดยรวม โดยทั่วไปแล้ว บุคคลจะโคลนพื้นที่เก็บข้อมูลอย่างเป็นทางการระยะไกลของโปรเจ็กต์และทำงานกับโค้ดในเครื่อง หลังจากนั้น เขาจะวางโค้ดลงในที่เก็บระยะไกลส่วนตัวของเขา และขอให้ผู้ที่รับผิดชอบในที่เก็บอย่างเป็นทางการมารับ(ดึง) โค้ดลงในที่เก็บข้อมูลในเครื่อง ซึ่งพวกเขาจะตรวจสอบและอาจรวม (ผสาน) ของเขา. แนวคิดนี้มีชื่อเรียกอื่น ๆ เช่น คำขอรวม.

คุณไม่จำเป็นต้องใช้ฟีเจอร์คำขอดึงของ GitHub หรือแพลตฟอร์มที่คล้ายกัน ทีมพัฒนาอาจใช้วิธีการสื่อสารอื่น รวมถึงการสื่อสารแบบเห็นหน้ากัน การโทรด้วยเสียง หรืออีเมล แต่ก็ยังมีเหตุผลหลายประการที่จะใช้คำขอดึงข้อมูลแบบฟอรัม นี่คือบางส่วนของพวกเขา:

• จัดการอภิปรายที่เกี่ยวข้องกับการเปลี่ยนแปลงรหัสเฉพาะ
• เป็นสถานที่ในการดูข้อเสนอแนะเกี่ยวกับงานระหว่างดำเนินการจากทั้งผู้ทดสอบอัตโนมัติและเพื่อนร่วมงาน
• การทบทวนโค้ดอย่างเป็นทางการ
• เพื่อที่คุณจะได้ทราบเหตุผลและข้อควรพิจารณาเบื้องหลังโค้ดนี้หรือโค้ดนั้นในภายหลัง

โดยปกติแล้ว คุณจะสร้างคำขอดึงเมื่อคุณต้องการหารือเกี่ยวกับบางสิ่งบางอย่างหรือรับคำติชม ตัวอย่างเช่น หากคุณกำลังพัฒนาคุณลักษณะที่สามารถนำไปใช้ได้มากกว่าหนึ่งวิธี คุณสามารถสร้างคำขอดึงก่อนที่จะเขียนโค้ดบรรทัดแรกเพื่อแบ่งปันแนวคิดของคุณและหารือเกี่ยวกับแผนของคุณกับผู้ทำงานร่วมกัน หากงานนั้นง่ายกว่า คำขอดึงจะถูกเปิดเมื่อมีบางสิ่งที่เสร็จสิ้น มุ่งมั่น และสามารถพูดคุยได้ ในบางสถานการณ์ คุณอาจต้องการเปิด 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 hook ก่อนหน้านี้ การทดสอบที่เพิ่มเข้ามาใหม่จะถูกรัน จะล้มเหลว และจะไม่มีการดำเนินการใดๆ โปรดทราบว่านี่คือวิธีที่เรารู้ว่าการทดสอบของเรากำลังทดสอบบางสิ่งบางอย่างจริงๆ ที่น่าสนใจคือ ถ้าเราเริ่มต้นด้วยโค้ดก่อนการทดสอบ การผ่านการทดสอบอาจหมายความว่าโค้ดทำงานได้ตามที่คาดไว้ หรือการทดสอบไม่ได้ทดสอบอะไรเลย นอกจากนี้ หากเราไม่ได้เขียนข้อสอบตั้งแต่แรก เราอาจลืมข้อสอบเหล่านี้ไปเลย เนื่องจากไม่มีอะไรทำให้เรานึกถึงข้อสอบได้

การพัฒนาแบบทดสอบขับเคลื่อน (TDD)

TDD แนะนำให้เขียนการทดสอบก่อนโค้ด ขั้นตอนการทำงานทั่วไปที่ใช้ TDD มีลักษณะเช่นนี้

1. เพิ่มการทดสอบ
2. รันการทดสอบทั้งหมดและตรวจสอบให้แน่ใจว่าการทดสอบใหม่ล้มเหลว
3. เขียนโค้ด
4. ดำเนินการทดสอบ ตรวจสอบให้แน่ใจว่าการทดสอบทั้งหมดผ่าน
5. ปรับโครงสร้างโค้ดของคุณใหม่
6. ทำซ้ำ.

เนื่องจากผลลัพธ์ของการทดสอบที่ล้มเหลวมักจะแสดงเป็นสีแดง และการทดสอบที่ผ่านการทดสอบมักจะแสดงเป็นสีเขียว วงจรนี้จึงเรียกว่ารีแฟคเตอร์สีแดง-เขียว

️งาน

ขั้นแรก ให้ลองดำเนินการทดสอบและปล่อยให้การทดสอบล้มเหลว จากนั้นจึงเพิ่มและคอมมิตข้อความของรายการขั้นตอน 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 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 ในขณะที่เรากำลังทำงานประชาสัมพันธ์นี้
นี้จะสร้างสถานการณ์ที่สาขาระยะไกล master มีเวอร์ชันใหม่กว่าเวอร์ชันที่เรายึดตามสาขา feature. ด้วยเหตุนี้เราจึงไม่สามารถย้อนกลับ HEAD เพียงอย่างเดียวได้ master จนถึงจุดสิ้นสุดของเธรด feature. ในสถานการณ์นี้ เราจำเป็นต้องผสานหรือใช้การคอมมิต feature รีบูต master. GitHub สามารถทำการผสานอัตโนมัติได้จริงหากไม่มีข้อขัดแย้ง อนิจจา ในสถานการณ์ของเรา ทั้งสองสาขามีการเปลี่ยนแปลงที่แข่งขันกันในไฟล์ ci.md. สถานการณ์นี้เรียกว่าข้อขัดแย้งในการผสาน และเราจำเป็นต้องแก้ไขด้วยตนเอง

ผสานหรือรีบูต

ผสาน

• สร้างการคอมมิตการผสานเพิ่มเติมและบันทึกประวัติการทำงาน
  • เก็บรักษาข้อผูกพันดั้งเดิมของสาขาด้วยการประทับเวลาและผู้เขียนดั้งเดิม
  • บันทึก SHA ของการคอมมิตและลิงก์ไปยังสิ่งเหล่านั้นในการสนทนาคำขอเปลี่ยนแปลง
• ต้องมีการแก้ไขข้อขัดแย้งเพียงครั้งเดียว
• ทำให้เรื่องราวไม่เป็นเชิงเส้น
  • เรื่องราวอาจอ่านได้ยากเนื่องจากมีสาขาจำนวนมาก (ชวนให้นึกถึงสายเคเบิล IDE)
  • ทำให้การดีบักอัตโนมัติยากขึ้น เช่น git bisect มีประโยชน์น้อยกว่า - จะพบเฉพาะการคอมมิตแบบผสานเท่านั้น

rebase

• การเล่นซ้ำจะดำเนินการจากสาขาปัจจุบันที่ด้านบนของสาขาฐานทีละรายการ
  • คอมมิตใหม่ที่มี SHA ใหม่จะถูกสร้างขึ้น ส่งผลให้คอมมิตใน GitHub ตรงกับคำขอดึงข้อมูลดั้งเดิม แต่ไม่ใช่ความคิดเห็นที่เกี่ยวข้อง
  • คอมมิตสามารถรวมตัวกันใหม่และแก้ไขได้ในกระบวนการ หรือแม้แต่รวมเป็นหนึ่งเดียว
• ข้อขัดแย้งหลายประการอาจต้องได้รับการแก้ไข
• ช่วยให้คุณรักษาเรื่องราวเชิงเส้นได้
  • เรื่องราวอาจอ่านง่ายกว่าตราบใดที่ไม่ยาวเกินไปโดยไม่มีเหตุผลอันสมควร
  • การดีบักและการแก้ไขปัญหาอัตโนมัตินั้นง่ายกว่าเล็กน้อย: ทำให้เป็นไปได้ git bisectสามารถทำให้การย้อนกลับอัตโนมัติชัดเจนขึ้นและคาดเดาได้มากขึ้น
• จำเป็นต้องเผยแพร่สาขาที่มีการคอมมิตที่โยกย้ายพร้อมแฟล็ก --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 และปรับใช้เวอร์ชันใหม่โดยเร็วที่สุด เนื่องจาก API และสคีมาฐานข้อมูลเปลี่ยนไปเมื่อมีการปรับใช้โค้ดกับการใช้งานจริง โดยมีการส่งมอบอย่างต่อเนื่องและครอบคลุมการทดสอบที่ดี การย้อนกลับจึงมักทำได้ยากและมีความเสี่ยงมากกว่าการแก้ไขในเวอร์ชันถัดไป

เนื่องจากการย้อนกลับไม่มีความเสี่ยงใดๆ ในกรณีของเรา เราจะไปเส้นทางนี้ เพราะมันช่วยให้เรา

• แก้ไขข้อผิดพลาดเกี่ยวกับผลิตภัณฑ์โดยเร็วที่สุด
• ทำโค้ดเข้า 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. ข่าวร้ายก็คือรายการขั้นตอนการบูรณาการอย่างต่อเนื่องอันล้ำค่าของเราก็หายไปเช่นกัน ตามหลักการแล้ว เราจำเป็นต้องใช้โปรแกรมฟิกซ์กับคอมมิตจาก 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 เป็นแพลตฟอร์ม

ที่มา: will.com