Modern Git Commands and Features You Should Be Using

05-Jun-24

คัมภีร์เทพ IT

See the original english version Click here!

 

ในฐานะของ Software Engineers เชื่อว่าคงมีการใช้งาน Git เป็นประจำอยู่แล้ว แต่คนส่วนใหญ่มักจะใช้งานแค่คำสั่งพื้นฐาน เช่น Add, Commit, Push หรือ Pull แต่อันที่จริงแล้ว Git ยังมี Features ต่าง ๆ อีกมากมาย และการใช้ Features เหล่านั้นก็ช่วยให้ชีวิตของคุณง่ายขึ้นมาก ดังนั้นเรามาดู 5 Git Commands และ Features ที่มีประโยชน์ต่อการทำงานของคุณ

1. Switch

ตั้งแต่ Git version 2.23 ที่เปิดตัว ทำให้เราได้รู้จักกับคำสั่งใหม่คือ Git Switch ซึ่งเราสามารถใช้เพื่อสลับ Branches ได้:

อันที่จริง เราสามารถเปลี่ยน Branches ใน Git ได้โดยใช้คำสั่ง Git Checkout แต่คำถามน่าสนใจคือ แล้วทำไมถึงต้องมีอีกคำสั่งเพิ่มขึ้นมา Git Checkout เป็นคำสั่งที่ใช้งานได้หลากหลาย มันสามารถ Check out หรือ Restore Files รวมทั้งแม้แต่ Commits ที่ต้องการได้ ในขณะที่คำสั่ง Git Switch จะเปลี่ยนเฉพาะ Branch เท่านั้น นอกจากนี้ Switch ยังมีการตรวจสอบความถูกต้องเพิ่มเติมเพื่อความปลอดภัย ในขณะที่ Checkout ไม่มี อย่างเช่น Switch จะยกเลิกการทำงานถ้าเสี่ยงที่จะทำให้ Local Changes หายไป

2. Restore

อีกหนึ่งคำสั่งใหม่ที่เปิดตัวใน Git version 2.23 คือ Git Restore ซึ่งสามารถใช้เพื่อ Restore Files ให้กลับสู่ Version ที่ Commit ล่าสุดได้:

จาก Snippet ด้านบนนี้ได้อธิบายวิธีการทำงานของ Git Restore ซึ่งโดยรวมแล้ว Git Restore จะเข้ามาแทนที่และลดความซับซ้อนในการใช้งาน Git Reset และ Git Checkout

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเปรียบเทียบคำสั่ง RevertRestore และ Reset สามารถดูได้ที่ Document Section นี้

3. Sparse Checkout

ต่อไปคือ Git Sparse-Checkout ซึ่งเป็น Feature ที่ยังไม่ค่อยเป็นที่รู้จักมากนัก มันถูกเพิ่มเข้ามาใน Git 2.25 ที่ปล่อยออกมาเมื่อวันที่ 13 มกราคม 2020

สมมติว่าคุณมี Monorepo ขนาดใหญ่ ที่มี Microservices แบ่งออกเป็น Directories ต่าง ๆ ทำให้คำสั่งอย่าง Checkout หรือ Status ทำงานค่อนข้างช้าเนื่องจากขนาดของ Repo แต่จริง ๆ แล้ว คุณอาจต้องการทำงานกับแค่ subtree/directory เดียว ซึ่งคำสั่ง Git Sparse-Checkout เองจะเข้ามาช่วยตรงนี้:

ในตัวอย่างข้างบน เราเริ่มด้วยการ Clone Repo โดยไม่ Checkout ทุก Files  จากนั้นใช้ git sparse-checkout init --cone เพื่อกำหนดค่าให้ Git ทำการตรวจสอบเฉพาะ Files ใน Root ของ Repository ดังนั้น หลังจาก Run Checkout เราได้แค่ 3 Files แทนที่จะเป็น Tree ทั้งหมด หลังจากนั้นจึง Download/Checkout Directory ที่ต้องการโดยใช้ git sparse-checkout set ...

อย่างที่บอกไปแล้ว ว่า Feature นี้มีประโยชน์มากเมื่อต้องทำงานกับ Repos ขนาดใหญ่ในเครื่องของเรา อีกทั้งมันก็ยังมีประโยชน์ใน CI/CD เพื่อเพิ่มประสิทธิภาพของ Pipeline ในกรณีที่ต้องการ Build/Deploy แค่ส่วนหนึ่งของ Monorepo  โดยไม่จำเป็นต้อง Checkout ไปเสียทุกอย่าง

สำหรับคำอธิบายแบบละเอียดเกี่ยวกับ Sparse-Checkout สามารถดูได้ที่บทความนี้

4. Worktree

คงมีบ่อยครั้ง ที่เราต้องทำงานหลาย Features ใน Application (Repository) เดียวในเวลาเดียวกัน หรืออาจมีข้อผิดพลาดร้ายแรงที่เกิดขึ้น ในขณะที่คุณกำลังดำเนินการตาม Feature Request บางอย่างอยู่

ในกรณีเหล่านี้ ทางแก้คือ คุณต้อง Clone Repository ไว้หลาย ๆ Version/Branch หรืออาจจะต้อง Stash/Discard สิ่งที่กำลังทำอยู่  คำตอบของปัญหานี้ก็คือ Git Worktree ที่ถูกปล่อยออกมาเมื่อวันที่ 24 กันยายน 2018:

คำสั่งนี้ทำให้เราสามารถ Checkout ออกมาจากหลาย ๆ Branch ของ Repository เดียวกันได้พร้อม ๆ กัน ในตัวอย่างด้านบนนี้ เราจะเห็น 2 Branches คือ dev และ master สมมุติว่าเรากำลังทำงานบน Feature ใน Branch Dev อยู่ แต่เราต้องรีบแก้ Bug อย่างเร่งด่วน แทนที่เราจะต้อง Stash การเปลี่ยนแปลง (Change) หรือ Reset Branch เราก็แค่สร้าง Worktree ใหม่ใน Subdirectory ที่ชื่อ ./hotfix จาก Branch master จากนั้นเราก็ย้ายไปที่ Directory นั้น แล้วทำการเปลี่ยนแปลง (Change) เสร็จแล้วก็ Push พวกมัน แล้วกลับไปที่ Worktree เดิม

สำหรับคำอธิบายแบบละเอียดเพิ่มเติม สามารถดูที่บทความนี้

5. Bisect

สุดท้ายของบทความนี้คือ Git Bisect ซึ่งไม่ใช่อะไรที่ใหม่ซะทีเดียว (Git 1.7.14 เปิดตัวเมื่อวันที่ 13 พฤษภาคม 2012) แต่คนส่วนใหญ่ยังคงใช้แค่ Git Features จากประมาณปี 2005 ดังนั้น มันจึงยังคงมีประโยชน์อยู่

ตามที่ Docs Page ได้อธิบายไว้: Git Bisect ใช้ Binary Search เพื่อค้นหา Commit ที่ทำให้เกิด Bug:

เราทำการเริ่ม Bisect Session ด้วย Git Bisect Start หลังจากนั้น เราก็ระบุ Commit ที่ใช้งานไม่ได้ (ซึ่งส่วนใหญ่จะเป็น HEAD) และ Commit หรือ Tag ล่าสุดที่ยังใช้งานอยู่ ด้วยข้อมูลนี้ Git จะตรวจสอบ Commit ที่อยู่กึ่งกลางระหว่าง Commit "ไม่ดี" และ "ดี" จากนั้นเราต้องทดสอบว่า Version นั้นมี Bug หรือไม่ จากนั้นใช้ git bisect good เพื่อบอก Git ว่า มันยังใช้งานได้ หรือ git bisect bad เพื่อบอกว่า ยังพบปัญหาอยู่ เราทำซ้ำขั้นตอนนี้ต่อไปเรื่อย ๆ จนกว่าจะไม่เหลือ Commit อื่นให้ตรวจสอบแล้ว จากนั้น Git จะบอกเราว่า Commit ไหนเป็นตัวที่ทำให้เกิดปัญหา 

ขอแนะนำให้ดู Docs Page นี้ซึ่งจะมี Options อื่น ๆ อีกสำหรับ Git Bisect รวมถึง Visualizing, Replaying หรือ Skipping Commits

สรุป

ถ้าคุณค้นหาปัญหาเกี่ยวกับ Git ส่วนใหญ่คุณจะเจอคำถามใน StackOverflow แม้ว่าบางคำตอบจะยังใช้ได้ แต่ก็อาจจะมีบางส่วนที่ล้าสมัยไปแล้ว ยิ่งถ้าคำตอบนั้นถูกเขียนขึ้นมาเมื่อ 10 ปีที่แล้ว ดังนั้น ถ้าเจอปัญหาเกี่ยวกับ Git ขอแนะนำให้ตรวจสอบ Git Docs สำหรับคำสั่งใหม่ ๆ ซึ่งจะมีตัวอย่างที่ใช้งานได้อยู่มาก หรือศึกษา man Pages เพื่อดู Flags และ Options ต่าง ๆ ที่ถูกเพิ่มเข้ามาในคำสั่งที่เราคุ้นเคยนั่นเอง

ที่มา: https://itnext.io/

 

 

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

 

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

เพิ่มเพื่อน

 

บทความล่าสุด