บทความนี้เป็นบทความต่อเนื่องจากบทความ "Gitty Workflow" ซึ่งเราได้พูดถึงพื้นฐานของ Git และเวิร์กโฟลว์ Push/Pull แบบง่ายๆ
บทความนี้จะมุ่งเน้นไปที่เวิร์กโฟลว์คอมไพล์ที่ดีขึ้นซึ่งเกี่ยวข้องกับสาขาการจัดเตรียม/พัฒนาตัวกลาง ยังสำรวจแนวคิดใหม่ๆ เช่น ความขัดแย้ง การรีเบส และการผสานระหว่างทาง
คุณอาจสงสัยว่า ทำไมใครๆ ก็ต้องประสบปัญหาในการดูแลสาขาตัวกลาง ในเมื่อเราสามารถพุชคุณสมบัติใหม่หรืออัปเดตไปยังสาขาหลักได้โดยตรง
โครงการพัฒนาซอฟต์แวร์ที่พร้อมสำหรับการผลิตเกือบทั้งหมดจำเป็นต้องมีวงจรการพัฒนา การทดสอบ และการควบคุมคุณภาพหลายระดับ ดังนั้นความเป็นไปได้ที่จะเกิดข้อผิดพลาดหรือข้อบกพร่องในโค้ดเบสหลักของคุณก็เพิ่มสูงขึ้นเช่นกัน ดังนั้นจึงไม่ใช่ความคิดที่ดีที่จะผลักดันคุณสมบัติของคุณไปที่สาขาหลักโดยตรงจนกว่าจะได้รับการทดสอบอย่างละเอียด เพื่อป้องกันสิ่งนี้ เรามักจะใช้สำเนาของสาขาหลัก ซึ่งปกติเรียกว่าสาขาการแสดงละครหรือการพัฒนา
วัตถุประสงค์ของสาขา "การจัดเตรียม" คือเพื่อใช้เป็นสาขารูทสำหรับสาขาฟีเจอร์ทั้งหมด และเมื่อฟีเจอร์เสร็จสมบูรณ์ ก็จะถูกรวมเข้ากับสาขา “ชั่วคราว” ซึ่งได้รับการทดสอบอย่างละเอียดโดยใช้สภาพแวดล้อมชั่วคราว ก่อนที่จะถูกพุชไปที่สาขา “หลัก”
ข้อขัดแย้ง
ขณะฝึกเวิร์กโฟลว์นี้ คุณมักจะพบกับสิ่งที่เรียกว่าข้อขัดแย้งในการผสานเมื่อคุณพยายามรวมสองสาขาเข้าด้วยกัน
และรหัสของคุณอาจกลายเป็นเรื่องยุ่งเหยิงนี้ได้
มาดูกันว่าข้อขัดแย้งในการผสานคืออะไร ปกติจะเกิดขึ้นเมื่อใด และจะแก้ไขอย่างไร
ข้อขัดแย้งเกิดขึ้นเมื่อสองสาขาแยกกันทำการแก้ไขบรรทัดเดียวกันในไฟล์
ให้เราเข้าใจสิ่งนี้โดยใช้ตัวอย่าง สมมติว่านักพัฒนาสองคนกำลังทำงานในไฟล์เดียวกัน sample.html
Dev-A และ Dev-B สร้างสาขา f1
และ f2
จาก develop
ตามลำดับ
Dev-A เพิ่มโค้ดที่บรรทัด 10 คอมมิต และรวมโค้ดของเขากลับเข้าไปในสาขา develop
ในขณะเดียวกัน Dev-B จะเพิ่มโค้ดที่แตกต่างกันเล็กน้อยที่บรรทัดเดียวกัน 10 ตำแหน่ง
ตอนนี้ เมื่อ Dev-B ซิงค์ develop
ตามลำดับโดยใช้ git pull และพยายามรวมเวอร์ชันของโค้ดที่อยู่ใน Branchf2
เข้ากับ develop
; มันทำให้เกิดความขัดแย้งในการผสานเนื่องจากสาขา f2
ยังคงมีเวอร์ชันที่ล้าสมัยของ sample.html
เช่น เวอร์ชันก่อนที่สาขา f1
จะถูกรวมเข้าด้วยกัน
ดังนั้น เมื่อ f2
พยายามทำการเปลี่ยนแปลงตรงจุดที่ f1
ได้กระทำการเปลี่ยนแปลง Git ทำให้เกิดข้อขัดแย้งในการผสาน ทำให้ Dev-B สามารถเลือกเวอร์ชันของโค้ดที่ถือเป็นที่สิ้นสุดได้
อย่างไรก็ตาม เราสามารถหลีกเลี่ยงข้อขัดแย้งในการผสานดังกล่าวในขณะที่ดึงคำขอได้โดยใช้คำสั่ง Rebaseing or Merge ก่อนที่จะส่งคอมมิตของคุณไปยังระยะไกล
ทั้ง git rebase
& git merge
แก้ปัญหาพื้นฐานเดียวกัน: การซิงค์การเปลี่ยนแปลงจากสาขาหนึ่งไปยังอีกสาขาหนึ่ง มาดูที่git rebase
& git merge
แบบเจาะลึกอีกหน่อยกันดีกว่า
คอมไพล์ผสาน
git merge
เป็นตัวเลือกที่ง่ายและปลอดภัยที่สุดในการรวมการเปลี่ยนแปลงของผู้อื่นเข้ากับการเปลี่ยนแปลงของคุณ
สมมติว่าคุณกำลังสร้าง API ของอาคารบนสาขาชื่อ api-dev
ซึ่งคุณแยกจาก main
ในขณะเดียวกัน หนึ่งในสมาชิกในทีมของคุณรวมการเปลี่ยนแปลงที่เกี่ยวข้องกับ UI ใน main
หากต้องการผสานรวม API ของคุณโดยสมบูรณ์ คุณต้องนำการเปลี่ยนแปลง UI ที่เพิ่งรวมใน main
ภายในสาขาคุณลักษณะของคุณ api-dev
คุณสามารถใช้ได้
git merge <source_branch> <target_branch>
OR
git checkout <target_branch> git merge <source_branch>
ในกรณีนี้ target_branch คือ api-dev
และ source_branch คือ main
สิ่งที่ git merge
is จะทำคือรวมการเปลี่ยนแปลงทั้งหมดไว้ในคอมมิตเดียวและเขียนไว้ที่ด้านบนของบันทึกคอมมิต
คอมไพล์รีเบส
ในทางกลับกัน การรีบูตจะเขียนประวัติการคอมมิตทั้งหมดใหม่โดยการแทรกการคอมมิตที่หายไป และเรียงลำดับบันทึกการคอมมิตตามลำดับเวลาคอมมิต
โบนัส
คอมไพล์ ดึงข้อมูล
git fetch
ใช้เพื่อซิงค์การเปลี่ยนแปลงจาก repo ระยะไกลของคุณไปยัง repo ในพื้นที่ของคุณ ตัวอย่างเช่น สมมติว่าเพื่อนร่วมทีมของคุณพุชฟีเจอร์แบรนช์ใหม่และคุณต้องการทดสอบแบรนช์นั้น หากต้องการตรวจสอบสาขา คุณต้องซิงค์สาขานั้น และนั่นคือสิ่งที่ git fetch
มีประโยชน์
หมายเหตุ: git fetch
ซิงค์เฉพาะการคอมมิต repo ระยะไกลเท่านั้น โดยไม่ได้นำการเปลี่ยนแปลงเหล่านั้นจากระยะไกลมาสู่ท้องถิ่น เพื่อสิ่งนั้น คุณจะต้องรวม repo ระยะไกลเข้ากับ repo ท้องถิ่นโดยใช้ git merge origin/<branch_name> <branch_name>
หรือใช้ git pull
ดึงคอมไพล์
git pull
เป็นคำสั่งชวเลขสำหรับ git fetch
และ git merge
ดังนั้นเมื่อใดก็ตามที่ repo ระยะไกลของคุณนำหน้า repo ในพื้นที่ของคุณ คุณต้องการที่จะนำการเปลี่ยนแปลงเหล่านั้นมาใช้ คุณสามารถใช้ git pull
ดังนั้นแทนที่จะ
git checkout main git fetch git merge origin/main
คุณก็สามารถทำได้
git checkout main git pull
และสาขา repo ในพื้นที่ของคุณจะสอดคล้องกับสาขา repo ระยะไกล
หมายเหตุ:คุณอาจพบข้อขัดแย้งขณะทำ git pull
เช่นกัน