COOL IT IDEAS AND STUFF

See the original english version Click here!

อาจมี Developer หลายๆ ท่านที่กำลังตัดสินใจเลือกระหว่าง “Merge” และ “Rebase” จากข้อมูลต่างๆ ที่เราได้เห็นจาก Internet มีหลายคนเชื่อว่า “ไม่ควรใช้ Rebase” เพราะมันอาจเป็นต้นเหตุของปัญหาต่างๆ ได้ ดังนั้นเพื่อขจัดข้อสงสัย ในบทความนี้จะช่วยอธิบายว่า Git Merge กับ Git Rebase คืออะไร ต่างกันอย่างไร และใช้ในโอกาสใดบ้าง

โดยรวมแล้ว แม้ว่า Git Merge และ Git Rebase จะมีวัตถุประสงค์ที่ไม่ต่างกัน แต่ก็มีวิธีการที่แตกต่างกัน  และหากคุณรู้ถึงข้อแตกต่างของมัน ก็จะสามารถใช้งานได้อย่างเหมาะสมและจะเป็นประโยชน์อย่างมาก

Git Merge

การ Merge ถือเป็นสิ่งที่ต้องทำสำหรับ Developer ที่ใช้งาน Version Control ไม่ว่า Branch นั้น จะถูกสร้างขึ้นสำหรับการ Test,การแก้ Bug หรือด้วยเหตุผลใดก็ตาม การ Merge Commit จะไปเปลี่ยนแปลงที่ Location อื่น หากให้เจาะจงมากขึ้นก็คือ การ Merge จะนำ Content ของ Branch ต้นทาง (Source Branch) ไป Integrate เข้ากับ Branch ที่เป็นเป้าหมาย (Target Branch) ซึ่งในกระบวนการนี้ Target Branch เท่านั้นที่มีการเปลี่ยนแปลง แต่ History ของ Source Branch ยังคงเหมือนเดิม

ข้อดี

• เข้าใจได้ง่าย
• เก็บ History ทั้งหมดและเรียงตามลำดับ
• ดูแลรักษา Context ของ Branch

ข้อด้อย

• History ของการ Commit อาจกลายเป็นสร้างปัญหาจากการ Merge Commit เป็นจำนวนมากๆ ได้
• ทำให้การ Debug โดยใช้ git bisect ยากขึ้น

แล้วจะใช้อย่างไร

สามารถ Merge ตัว Master Branch ไปยัง Feature Branch โดยใช้คำสั่ง Checkout และ Merge

เมื่อทำแบบนี้ มันจะสร้าง “Merge commit” ใหม่ขึ้นมาใน Feature Branch ซึ่งเก็บ History ของทั้งสอง Branch

Git Rebase

Rebase เป็นอีกวิธีในการ Integrate การเปลี่ยนแปลงจาก Branch หนึ่งไปอีก Branch หนึ่ง การ Rebase จะทำการรวบรวมการเปลี่ยนแปลงทั้งหมดให้อยู่ใน "Patch" เดียว จากนั้นมันจะ Integrate Patch ไปยัง Target Branch

Rebase แตกต่างจาก Merge ตรงที่การ Rebase จะทำให้ History ดูไม่ซับซ้อน เนื่องจากมันจะย้าย Work ที่เสร็จแล้วจาก Branch หนึ่งไปอีก Branch หนึ่ง ในกระบวนการนี้ History ที่ไม่ต้องการจะถูกกำจัดออกไป

ข้อดี

• ปรับปรุง History ที่ซับซ้อนให้มีประสิทธิภาพมากขึ้น
• จัดการกับ Single Commit ได้ง่าย (เช่น การคืนค่า)
• ช่วย Clean ตัว Intermediate Commits ด้วยการทำให้มันเป็น Single Commit ซึ่งจะเป็นประโยชน์สำหรับทีม DevOps

ข้อด้อย

• ด้วยเหตุที่มันลดจำนวน Commit ให้เหลือน้อยลง อาจเป็นซ่อน Context บางอย่างได้
• การ Rebase ตัว Public Repositories อาจสร้างความเสียหายได้หากมีการทำงานกันเป็นทีม
• มี Process การทำงานมากขึ้น: เพราะเมื่อใช้ Rebase จะมีการ Update Feature Branch ของคุณตลอดเวลา
• การ Rebase ด้วย Remote Branches นั้น มันจำเป็นต้อง Force Push ซึ่งปัญหาใหญ่ที่คุณต้องเจอคือ มีการ Force Push โดยที่ยังไม่ได้ตั้งค่า default ของ git push ส่งผลให้มีการ Update ทุก Branch ที่มีชื่อเหมือนกันทั้งใน Local และที่เป็น Remote ซึ่งถือเป็นสิ่งที่น่ากังวลอย่างมาก

หากคุณ Rebase อย่างไม่ถูกต้อง และทำการ Rewrite History โดยไม่ได้ตั้งใจ มันอาจนำไปสู่ปัญหาร้ายแรงได้ ดังนั้น คุณต้องรู้ว่าคุณกำลังทำอะไรอยู่

แล้วจะใช้อย่างไร

ทำการ Rebase ตัว Feature Branch ไปยัง Master Branch โดยใช้คำสั่งต่อไปนี้

สิ่งนี้จะย้าย Feature Branch ทั้งหมดไปอยู่บน Master Branch ซึ่งทำได้โดยการ Re-write ตัว History ของ Project ด้วยการสร้างCommit ใหม่สำหรับแต่ละ Commit ใน Original (Feature) Branch

Interactive Rebasing

วิธีนี้มีประสิทธิภาพกว่าการ Rebase แบบอัตโนมัติเนื่องจากสามารถควบคุม Commit History ของ Branch ได้เป็นอย่างดี โดยทั่วไปแล้วใช้วิธีนี้เพื่อ Clean ตัว History (ที่มีอยู่เป็นจำนวนมาก) ก่อนที่จะรวม Feature Branch เข้ากับ Master Branch

นี่จะเป็นการเปิด Editor โดยการแสดงรายการ Commit ทั้งหมดที่กำลังจะถูกย้าย

นี่จะเป็นการกำหนดว่า Branch จะมีลักษณะอย่างไรหลังจากการ Rebase แล้ว ด้วยการจัดลำดับใหม่ คุณสามารถทำให้ History เป็นไปตามที่คุณต้องการ อย่างเช่น คุณสามารถใช้คำสั่งอย่าง fixup, squash, edit เป็นต้นแทนการใช้ pick

แล้วจะใช้แบบไหนดี?

มันยากที่จะตัดสินใจเลือกว่าจะใช้แบบไหนดี เนื่องจากแต่ละทีมก็มีความแตกต่างกัน ในทีมเองต้องพิจาณาคำถามหลายข้อขณะที่ตั้ง Policy ของ Git Rebase กับ Git Merge ซึ่งทุกอย่างล้วนขึ้นอยู่กับแต่ละทีม

พิจารณา Level ของการ Rebase กับทักษะในเรื่อง Git ของทีมงาน กำหนดระดับความสำคัญที่คุณให้กับความยาก-ง่ายของการ Rebase เทียบกับเรื่อง Traceability และ History ของการ Merge

ที่สุดแล้ว การตัดสินใจว่าจะใช้ Merge หรือ Rebase ควรพิจารณาไปถึงบริบทที่ชัดเจนของ Branching Strategy

ข้อแนะนำ

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

• คุณกำลัง Develop งานคนเดียว: หากคุณไม่จำเป็นต้อง Share งานกับคนอื่น ในจุดนี้คุณควรเลือกใช้ Rebase มากกว่า Merge เพื่อรักษาความเป็นระเบียบของ History หากคุณมีที่เก็บงานส่วนตัวแยกออกมา ซึ่งไม่ได้ Share กับ Developer คนอื่น คุณจะปลอดภัยที่จะใช้ Rebase แม้หลังจากที่คุณ Push Branch ไปแล้วก็ตาม
• Code ของคุณพร้อมสำหรับการ Review แล้ว: คุณสร้าง Pull Request แล้ว แต่มีคนอื่นกำลัง Review งานของคุณอยู่ ขณะเดียวกันอาจกำลังนำงานของคุณไป Review ในเครื่องของพวกเขา ในจุดนี้ คุณไม่ควร Rebase งานของคุณ คุณควรสร้าง "Rework" Commits และทำการ Update Feature Branch ของคุณ ซึ่งจะช่วยในการตรวจสอบย้อนกลับในการ Pull Request และป้องกันปัญหาที่อาจเกิดขึ้นกับ History อีกด้วย
• การ Review เสร็จแล้ว และพร้อมที่จะ Integrate เข้ากับ Target Branch: ถึงตอนนี้ คุณกำลังจะลบ Feature Branch ของคุณ ทำให้ Developer คนอื่นไม่สามารถมาดึงข้อมูลการเปลี่ยนแปลงเหล่านี้ได้อีก นี่เป็นโอกาสของคุณที่จะทำให้ History ของคุณเป็นระเบียบ ในจุดนี้คุณสามารถ Rewrite History และเก็บ Original Commits และ ‘PR Rework’ ที่น่ารำคาญและ ‘Merge’ Commits เข้ากับกลุ่มของ Commit ที่คุณ Focus อยู่ การสร้าง Merge สำหรับ Commits เหล่านี้ถือเป็นทางเลือก แต่มันมีประโยชน์มาก โดยมันจะ Record เมื่อ Feature ไปอยู่ที่ Master แล้ว

สรุป

หวังว่าบทความนี้จะให้ข้อมูลเชิงลึกเกี่ยวกับ Git Merge และ Git Rebase มากขึ้น แม้จะเป็นที่ถกเถียงกันระหว่างเรื่อง Merge และ Rebase Strategy แต่บางทีบทความนี้อาจช่วยขจัดข้อสงสัยบางอย่างของคุณ และช่วยให้เลือกแนวทางที่เหมาะกับทีมของคุณได้

ที่มา:  https://medium.freecodecamp.org/