บทความนี้เป็นบทความต่อเนื่องจากบทความ "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 mergeis จะทำคือรวมการเปลี่ยนแปลงทั้งหมดไว้ในคอมมิตเดียวและเขียนไว้ที่ด้านบนของบันทึกคอมมิต

คอมไพล์รีเบส

ในทางกลับกัน การรีบูตจะเขียนประวัติการคอมมิตทั้งหมดใหม่โดยการแทรกการคอมมิตที่หายไป และเรียงลำดับบันทึกการคอมมิตตามลำดับเวลาคอมมิต

โบนัส

คอมไพล์ ดึงข้อมูล

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 เช่นกัน