บทความ IT เจ๋งๆ

หากคุณเคยใช้งาน Git มาบ้างแล้ว แต่เจอ 2 ปัญหานี้คือ เกิดข้อผิดพลาดในระหว่างการ Commit และจะทำอย่างไรให้ Commit History ไม่สับสนและเป็นระเบียบมากขึ้น หากใครเจอปัญหาลักษณะนี้ อยากให้คุณลองอ่านบทความของคุณ Aditya Sridhar ดู เพราะ หากคุณรู้จัก 2 เรื่องนี้แล้ว จะช่วยให้คุณเชี่ยวชาญการใช้งาน Git ยิ่งขึ้น

จากที่เกริ่นไปข้างต้น เรามาดูกันทีละปัญหา

ปัญหาแรก: หากเกิดข้อผิดพลาดในการ Commit จะแก้ไขอย่างไรดี

สถานการณ์ 1:

สมมุติว่า คุณได้ Commit File ต่างๆ เป็นจำนวนมาก แต่กลับพบว่า Commit Message เกิดความไม่ชัดเจน และคุณก็ต้องการเปลี่ยน Commit Message นั้น ซึ่งในสถานการณ์นี้คุณสามารถใช้ git commit –amend

สถานการณ์ 2:

สมมุติว่า คุณต้องการ Commit File จำนวน 6 File แต่เกิดข้อผิดพลาดที่ไม่ได้ตั้งใจ กลายเป็น Commit ได้เพียง 5 File เท่านั้น ตอนนี้คุณอาจคิดว่า งั้นก็สร้าง Commit ใหม่แล้วเพิ่ม File ที่ 6 เข้าไป

ดูเผินๆ วิธีนี้ไม่ได้มีอะไรที่ผิดเลย แต่หากคุณอยากมี Commit History ที่เป็นระเบียบแล้ว วิธีการดังกล่าวอาจเป็นวิธีที่ไม่ค่อยดีเท่าไรนัก ซึ่งในสถานการณ์นี้คุณก็สามารถใช้ git commit –amend ได้เช่นเดียวกัน

--no-edit หมายถึง Commit Message จะไม่ถูกเปลี่ยนแปลง

สถานการณ์ 3:

เมื่อใดที่คุณทำการ Commit ใน Git แต่ละการ Commit จะมี Author Name และ Author Email ผูกติดไปด้วย โดยทั่วไปเมื่อคุณ Set up Git ในครั้งแรก คุณจะต้องตั้ง Author Name และ Author Email ด้วย ทำให้คุณไม่ต้องกังวลเกี่ยวกับรายละเอียดของ Author สำหรับการ Commit ในทุกครั้ง

แต่มันก็เป็นไปได้ว่า คุณอาจจะอยากใช้ Email อื่นๆ สำหรับบาง Project ของคุณ ดังนั้น คุณจำเป็นต้อง Config ค่า Email ID สำหรับ Project นั้นๆ ด้วยคำสั่ง:

ในกรณีนี้ สมมุติว่า คุณลืม Config ค่า Email แต่ดัน Commit ไปแล้ว คำสั่ง amend ก็สามารถใช้เพื่อเปลี่ยนแปลง Author ของการ Commit ในครั้งก่อนหน้านี้ได้เช่นกัน ซึ่ง Author ของการ Commit จะสามารถเปลี่ยนแปลงได้โดยใช้คำสั่งต่อไปนี้:

หมายเหตุ:

ควรใช้คำสั่ง amend เฉพาะใน Local Repository ของคุณเองเท่านั้น หากใช้ amend ใน Remote Repository อาจทำให้เกิดความสับสนได้

ปัญหาที่ 2: Commit History มันดูยุ่งเหยิงไปหมด จะจัดการกับมันอย่างไรดี

สมมติว่าคุณกำลังทำงานกับ Code บางส่วนอยู่ และคุณก็รู้ว่า Code นี้จะใช้เวลาทำให้เสร็จประมาณ 10 วัน ซึ่งภายใน 10 วันที่ว่านั้น Developer คนอื่นๆ อาจจะมีการ Commit Code ไปยัง Remote Repository ด้วยเช่นกัน

มันถือเป็นแนวทางปฏิบัติที่ดี ที่คุณจะเก็บ Code ที่ Update ล่าสุดจาก Remote Repository ลงใน Local Repository ด้วย ด้วยวิธีนี้จะลดการเกิด Conflicts เมื่อคุณทำการ Pull Request ดังนั้น คุณอาจจะใช้การ Pull สิ่งที่ Update ล่าสุดจาก Remote Repository ทุกๆ 2 วัน

ทุกครั้งที่คุณ Pull Code จาก Remote Repository ไปยัง Local Repository การ Merge Commit จะถูกสร้างขึ้นใน Local Repository ของคุณด้วย นั่นหมายความว่า Commit History ใน Local Repository ของคุณ มีแนวโน้มที่จะเกิด Merge Commit เป็นจำนวนมากซึ่งมันอาจสร้างความสับสนให้แก่ Reviewer ได้

แล้วจะทำอย่างไรให้ Commit History ดูเป็นระเบียบและเข้าใจง่ายขึ้น?

ตัวช่วยในการแก้ปัญหาของเรื่องนี้ คือ Rebase นั่นเอง

แล้ว Rebase คืออะไร?

ขออธิบายให้คุณเข้าใจง่ายขึ้นด้วยตัวอย่างนี้ ก็แล้วกัน

1. ใน Release Branch มี 3 Commits ประกอบด้วย Rcommit1, Rcommit2 และ Rcommit3
2. คุณได้สร้าง Feature Branch จาก Release Branch ตอนที่มีเพียง 1 Commit ซึ่งก็คือ Rcommit1
3. คุณได้เพิ่มอีก 2 Commits เข้าไปใน  Feature Branch ซึ่งประกอบด้วย Fcommit1 และ Fcommit2
4. เป้าหมายของคุณ ก็คือ การได้รับ Commit จาก Release Branch ลงไปใน Feature Branch
5. คุณสามารถใช้ Rebase เพื่อทำสิ่งนี้
6. ให้ชื่อ Release Branch เป็น Release และชื่อของ Feature Branch เป็น Feature
7. สามารถทำ Rebasing ได้โดยใช้คำสั่งต่อไปนี้:

Rebasing

ขณะที่ทำการ Rebasing นั้น เป้าหมายของคุณคือ ทำให้แน่ใจว่า Feature Branch จะได้รับ Code ที่ Update ล่าสุดจาก Release Branch

Rebasing จะทำการเพิ่มแต่ละ Commit แบบ 1 ต่อ 1 และจะทำการตรวจสอบ Conflicts ไปด้วย แบบนี้ยิ่งทำให้สับสนหรือไม่?

ถ้าอย่างงั้น ลองมาดูสิ่งที่ Rebasing ทำกันจาก Diagram ด้านล่าง:

Step 1:

1. ขณะที่คุณ Run คำสั่ง อยู่นั้น Feature Branch จะชี้ไปที่ Head ของ Release Branch
2. ตอนนี้ Feature Branch มี 3 Commits ประกอบด้วย Rcommit1, Rcommit2 และ Rcommit3
3. คุณอาจกำลังสงสัยอยู่ว่า แล้วเกิดอะไรขึ้นกับ Fcommit1 และ Fcommit2
4. Commits ต่างๆ ยังคงมีอยู่ และมันจะถูกใช้ใน Step ถัดไป

Step 2:

1. ตอนนี้ Git พยายามเพิ่ม Fcommit1 ลงไปใน Feature Branch
2. กรณีที่ ไม่เกิด Conflict ใดๆ, Fcommit1 จะถูกเพิ่มเข้าไปหลังจาก Rcommit3
3. กรณีที่ เกิด Conflicts, Git จะแจ้งให้คุณทราบ และคุณจะต้องแก้ไข Conflicts นั้นเสียก่อน จากนั้น หลังจากที่ Conflicts ต่างๆ ถูกแก้ไขเรียบร้อยแล้ว ให้ใช้คำสั่งต่อไปนี้ เพื่อทำการ Rebasing ต่อ:

Step 3:

1. เมื่อ Fcommit1 ถูกเพิ่มเข้าไปแล้ว, Git ก็พยายามที่จะเพิ่ม Fcommit2 เข้าไป
2. กรณีที่ ไม่เกิด Conflict ใดๆ, Fcommit2 จะถูกเพิ่มเข้าไปหลังจาก Fcommit1 ซึ่งถือว่า การ Rebase เสร็จสิ้นอย่างสมบูรณ์แล้ว
3. กรณีที่ เกิด Conflicts, Git ก็จะแจ้งให้คุณทราบ และคุณจะต้องแก้ไข Conflicts นั้นให้เรียบร้อยเสียก่อน จากนั้นจึงสามารถใช้คำสั่งเช่นเดียวกับที่ใช้ใน Step 2
4. หลังจากการ Rebase เสร็จสิ้น คุณจะสังเกตเห็นว่าใน Feature Branch จะมี Rcommit1, Rcommit2, Rcommit3, Fcommit1 และ Fcommit2

หมายเหตุ:

1. ทั้ง Rebase และ Merge ล้วนมีประโยชน์ต่อการใช้งาน Git ทั้งคู่ ไม่มีอะไรที่ดีไปกว่ากัน
2. ในกรณีของการ Merge คุณสามารถใช้ Merge Commit แต่ในกรณีของการ Rebase ไม่มีการ Commit ที่พิเศษเหมือนอย่าง  Merge Commit
3. หนึ่งใน Best Practice ก็คือ การใช้คำสั่งในจุดต่างๆ โดยจะใช้ Rebase เมื่อคุณกำลัง Update Code ใน Local Repository ด้วย Code ล่าสุดจาก Remote Repository และใช้ Merge เมื่อต้องจัดการกับ Pull Requests เพื่อ Merge Feature Branch กลับไปด้วย Release หรือ Master Branch
4. ใช้การ Rebase เพื่อเปลี่ยนแปลง Commit History (ให้เป็นระเบียบขึ้น) แต่ขณะเดียวกันก็สามารถพูดได้ว่าการเปลี่ยนแปลง Commit History ก็มีความเสี่ยง ดังนั้นเพื่อให้แน่ใจว่าจะไม่เกิดข้อผิดพลาดกรณีคุณไม่เคยใช้ Rebase มาก่อน คุณไม่ควร Rebase Code ของคุณใน Remote Repository แต่ควรทำ ใน Local Repository ก่อน
5. ถ้าการ Rebase ถูกทำใน Remote Repository อาจสร้างความสับสนให้กับ Developer คนอื่นๆ ที่ไม่ทราบว่ามีอะไรเปลี่ยนแปลงไปแล้วบ้าง
6. นอกจากนี้ ถ้าการ Rebase ถูกทำใน Remote Repository ยังสามารถสร้างปัญหาได้ เมื่อ Developer คนอื่นๆ พยายามที่จะ Pull Code ล่าสุดจาก Remote Repository จึงขอย้ำอีกครั้งว่า คุณควรใช้ Rebase ใน Local Repository ก่อนเสมอ

จากบทความนี้ คุณได้เรียนรู้เกี่ยวกับ การแก้ไขการ Commit และการ Rebase แล้ว เชื่อว่าตอนนี้คุณคงจะเชี่ยวชาญการใช้งาน Git มากขึ้นแล้ว

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

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

บทความที่เกี่ยวข้อง

• 5 เครื่องมือ ที่ช่วยให้เขียน Clean Code ง่ายขึ้น
• 4 แนวทาง ช่วยให้ Database ปลอดภัย
• ชีวิตแต่ละวันของ Coder ต้องทำอะไรบ้าง