คอมโพเนนต์ของโฟลว์ GitHub

เสร็จสมบูรณ์เมื่อ

ในหน่วยนี้ เรากําลังตรวจทานคอมโพเนนต์ต่อไปนี้ของโฟลว์ GitHub:

• สาขา
• ยอมรับ
• คําขอดึงข้อมูล
• โฟลว์ GitHub
• โฟลว์ Git

ส่วนประกอบของ GitHub Flow

ก่อนที่เราจะเข้าสู่เวิร์กโฟลว์เฉพาะของ GitHub คุณควรทําความเข้าใจว่า GitHub Flow สร้างขึ้นโดยตรงจากแนวคิดพื้นฐานของ Git

Git มีเครื่องมือในการติดตามและจัดการการเปลี่ยนแปลงในโค้ดของคุณเมื่อเวลาผ่านไป GitHub สร้างขึ้นจากสิ่งนี้โดยทําให้ง่ายต่อการใช้เครื่องมือเหล่านั้นด้วยคุณสมบัติต่างๆ เช่น สาขา การคอมมิต คําขอดึงข้อมูล และอินเทอร์เฟซภาพสําหรับการทํางานร่วมกัน เริ่มต้นด้วยการดูว่าแนวคิดเหล่านี้ทํางานอย่างไรใน GitHub

สาขามีอะไรบ้าง

ในส่วนสุดท้าย เราได้สร้างไฟล์ใหม่และสาขาใหม่ในที่เก็บของคุณ

สาขาเป็นส่วนสําคัญของประสบการณ์ GitHub ช่วยให้คุณทําการเปลี่ยนแปลงได้โดยไม่ส่งผลกระทบต่อสาขาเริ่มต้น

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

โน้ต

อีกวิธีหนึ่งคือคุณสามารถสร้างสาขาใหม่และตรวจสอบโดยใช้ git ในเทอร์มินัล คําสั่งจะถูก git checkout -b newBranchName

การยอมรับคืออะไร

ในหน่วยก่อนหน้า คุณได้เพิ่มไฟล์ใหม่ลงในที่เก็บโดยการส่งการยอมรับ เรามาทบทวนแบบย่อๆ ว่าความมุ่งมั่นคืออะไร

ยอมรับ คือการเปลี่ยนแปลงไฟล์อย่างน้อยหนึ่งไฟล์บนสาขา การคอมมิตแต่ละครั้งจะถูกติดตามโดย ID การประทับเวลา และผู้สนับสนุนที่ไม่ซ้ํากัน โดยไม่คํานึงถึงว่าจะทําผ่านบรรทัดคําสั่งหรือโดยตรงในเว็บอินเทอร์เฟซของ GitHub Commits ให้บันทึกการตรวจสอบที่ชัดเจนสําหรับทุกคนที่ตรวจสอบประวัติของไฟล์หรือรายการที่เชื่อมโยง เช่น ปัญหาหรือคําขอดึงข้อมูล

คุณสามารถสร้างคอมมิตโดยใช้ Git ในเทอร์มินัลของคุณด้วย:

git commit -m "Add a helpful commit message"

ภายในที่เก็บ git ไฟล์สามารถอยู่ในสถานะที่ถูกต้องหลายสถานะเมื่อผ่านกระบวนการควบคุมเวอร์ชัน สถานะหลักสําหรับไฟล์ในที่เก็บ Git คือ ที่ไม่ได้ติดตาม และ ที่ติดตาม

ไม่ได้ติดตาม: สถานะเริ่มต้นของไฟล์เมื่อยังไม่ได้เป็นส่วนหนึ่งของที่เก็บ Git Git ไม่รู้ถึงการมีอยู่ของมัน

ติดตามแล้ว: ไฟล์ที่ติดตาม คือ ไฟล์ที่ Git กําลังตรวจสอบอย่างแข็งขัน ซึ่งอาจอยู่ในหนึ่งในสถิติย่อยต่อไปนี้:

• ไม่เปลี่ยนแปลง: ไฟล์ถูกติดตาม แต่ไม่ถูกปรับเปลี่ยนตั้งแต่การยอมรับล่าสุด
• ปรับเปลี่ยนแล้ว: ไฟล์มีการเปลี่ยนแปลงตั้งแต่การยอมรับครั้งล่าสุด แต่การเปลี่ยนแปลงเหล่านี้ยังไม่แสดงลําดับขั้นสําหรับการยอมรับครั้งถัดไป
• Staged: ไฟล์ได้รับการแก้ไข และการเปลี่ยนแปลงถูกเพิ่มลงในพื้นที่จัดเตรียม (หรือที่เรียกว่าดัชนี) การเปลี่ยนแปลงเหล่านี้พร้อมที่จะยอมรับ
• ยืนยันแล้ว: ไฟล์อยู่ในฐานข้อมูลของที่เก็บ ซึ่งแสดงเวอร์ชันที่ผูกมัดล่าสุดของไฟล์

สถานะเหล่านี้ช่วยให้ทีมของคุณเข้าใจสถานะของแต่ละไฟล์และตําแหน่งในกระบวนการควบคุมเวอร์ชัน

คําขอดึงข้อมูลคืออะไร

คําขอดึงข้อมูล คือกลไกที่ใช้เพื่อระบุว่าข้อผูกมัดจากสาขาหนึ่งพร้อมที่จะรวมเข้ากับสาขาอื่น

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

GitHub ยังรองรับ Draft Pull Requests ซึ่งช่วยให้คุณสามารถเปิดคําขอดึงข้อมูลที่ยังไม่พร้อมสําหรับการตรวจสอบ

เมื่อการเปลี่ยนแปลงได้รับการอนุมัติแล้ว (ถ้าจําเป็น) สาขาต้นทางของคําขอดึงข้อมูล (สาขาเปรียบเทียบ) จะถูกรวมเข้ากับสาขาพื้นฐาน

ตอนนี้คุณได้เห็นแล้วว่าสาขา คอมมิต และคําขอดึงข้อมูลทํางานอย่างไร มาดูกันว่าพวกเขามารวมกันใน GitHub Flow ได้อย่างไร

โฟลว์ GitHub

โฟลว์ GitHub เป็นเวิร์กโฟลว์ง่ายๆ ที่ช่วยให้คุณทําและแชร์การเปลี่ยนแปลงได้อย่างปลอดภัย เหมาะอย่างยิ่งสําหรับการทดลองใช้ไอเดียและทํางานร่วมกับทีมของคุณโดยใช้สาขา คําขอดึงข้อมูล และการผสาน

โน้ต

โฟลว์ GitHub เป็นหนึ่งในเวิร์กโฟลว์ยอดนิยมหลายเวิร์กโฟลว์ อื่น ๆ ได้แก่ Git flow และการพัฒนาตามลําต้น

ตอนนี้เราทราบพื้นฐานของ GitHub แล้วเราสามารถทําตามโฟลว์ GitHub และส่วนประกอบได้

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

โฟลว์ Git

ในขณะที่ GitHub Flow เป็นเวิร์กโฟลว์น้ําหนักเบาที่ออกแบบมาสําหรับการส่งมอบอย่างต่อเนื่อง Git flow เป็นโมเดลการแตกแขนงที่มีโครงสร้างมากขึ้นซึ่งมักใช้ในสภาพแวดล้อมที่ขับเคลื่อนด้วยรุ่น Git flow มีมานานกว่า GitHub Flow และคุณอาจยังคงเห็นคําที่ใช้ master แทนเป็น main สาขาเริ่มต้น

ประเภทสาขา Git flow

Git flow ใช้สาขาที่มีอายุยาวนานและชั่วคราวหลายสาขา:

• master: สะท้อนถึงโค้ดที่พร้อมใช้งานจริงเสมอ
• develop: มีงานพัฒนาล่าสุดสําหรับรุ่นถัดไป
• feature/*: ใช้เพื่อสร้างคุณสมบัติใหม่ แตกแขนงและ develop รวมกลับเมื่อเสร็จสมบูรณ์
• release/*: เตรียมรุ่นการผลิตใหม่จาก develop; อนุญาตให้ทดสอบขั้นสุดท้ายและแก้ไขข้อบกพร่องเล็กน้อย
• โปรแกรมแก้ไขด่วน/*: ใช้เพื่อแก้ไขปัญหาการผลิตอย่างรวดเร็ว แตกแขนงจาก master.

กระบวนการโฟลว์ Git ทํางานอย่างไร

1. นักพัฒนาสร้าง สาขาคุณลักษณะ เพื่อสร้าง develop ฟังก์ชันการทํางานใหม่
2. เมื่อถึงเวลาสําหรับการนําออกใช้ สาขาการนําออกใช้จะถูกสร้างขึ้นจากdevelop สิ่งนี้แยกงานเตรียมการปล่อยเพื่อให้การพัฒนาสามารถดําเนินต่อไปได้โดยไม่หยุดชะงัก
3. สามารถเพิ่มการแก้ไขข้อบกพร่องลงในสาขาการเผยแพร่ได้ แต่คุณสมบัติหลักควรรอการเปิดตัวในอนาคต
4. เมื่อพร้อมแล้ว สาขารุ่นจะถูกรวมเข้าด้วยกัน master และติดแท็กด้วยหมายเลขเวอร์ชัน GitHub สามารถใช้แท็กเหล่านี้เพื่อช่วยคุณสร้างบันทึกประจํารุ่น
5. ควรรวมสาขาการเผยแพร่เดียวกันกลับเข้าไปเพื่อให้ develop ซิงค์กัน
6. หากเกิดข้อบกพร่องในการผลิตที่สําคัญ สาขาโปรแกรมแก้ไขด่วนจะถูกสร้างขึ้นจากmaster เมื่อแก้ไขแล้ว จะรวมเป็นทั้งและ masterdevelop.

เมื่อใดควรใช้โฟลว์ Git

• เหมาะที่สุดสําหรับโปรเจ็กต์ที่มี การเผยแพร่ตามกําหนดเวลาหรือตามเวอร์ชัน
• มีประโยชน์หากคุณรักษาเวอร์ชัน ที่ใช้งานจริงหลายเวอร์ชัน (เช่น สาขาการสนับสนุนระยะยาว)
• เหมาะอย่างยิ่งสําหรับ วงจรการพัฒนาที่ช้าลงและมีโครงสร้างมากขึ้น (เช่น องค์กรหรือสภาพแวดล้อมที่มีการควบคุม)
• ถือว่า "รุ่นเฮฟวี่เวท" มากกว่า GitHub Flow เนื่องจากมี การจัดการสาขาเพิ่มเติม

โน้ต

โฟลว์ Git ถือว่าการคอมมิตผสานสําหรับการรวมสาขา การใช้การผสานรีเบสหรือสควอชอาจรบกวนโครงสร้างสาขาและการติดตามประวัติ

สําหรับหลายทีมที่ใช้ GitHub GitHub Flow นั้นง่ายและรวดเร็วกว่า แต่ถ้าทีมของคุณให้ความสําคัญกับความสามารถในการคาดการณ์และต้องการการวางแผนการเผยแพร่เพิ่มเติม Git flow อาจเหมาะสมกว่า

Congratulations! คุณเพิ่งได้เดินผ่าน GitHub Flow แบบเต็ม และสํารวจว่าโฟลว์ Git นําเสนอทางเลือกที่มีโครงสร้างสําหรับโครงการที่ขับเคลื่อนด้วยการเผยแพร่อย่างไร

เราไปต่อกันที่ส่วนถัดไป ซึ่งเราจะกล่าวถึงความแตกต่างระหว่างประเด็นและการสนทนา