COOL IT IDEAS AND STUFF
Git Commit Guidelines You Might Overlook
02-Oct-24
คัมภีร์เทพ IT
See the original english version Click here!
เชื่อว่า Developers ส่วนใหญ่คงเคยใช้งาน Git มาบ้างแล้ว ซึ่งแน่นอนว่า การทำงานร่วมกันเป็นทีมจะต้องมีการกำหนดมาตรฐานการทำงานเพื่อให้ทุกคนสามารถทำงานไปในแนวทางเดียวกันได้ โดยเฉพาะการ Commit Git และบทความนี้จะกว่าวถึง คำแนะนำเกี่ยวกับ Git Commit ที่คุณอาจมองข้าม
1. ทำไมการกำหนดมาตรฐานจึงมีความจำเป็น
หากไม่มีกฎเกณฑ์ ก็จะส่งผลให้ไม่มีความเป็นระเบียบ ซึ่งในการเขียน Program ก็เช่นเดียวกัน
หากคุณทำ Project ที่เขียนขึ้นมาด้วยตัวเองตั้งแต่ต้นจนจบ คุณสามารถเขียนมันได้ตามใจชอบ เนื่องจากไม่มีใครเข้ามาเกี่ยวข้องกับคุณ แต่ถ้าทุกคนในทีมทำตามที่ตนเองคิดว่าถูกต้อง Code ก็คงจะยุ่งเหยิงและ Project ดี ๆ ก็อาจจะเสียหาย ไม่ว่าจะเป็นการ Develop ในตอนนี้หรือการ Maintain ในอนาคต ก็จะกลายเป็นฝันร้ายได้
ในตอนนี้ มีคนเสนอแนวคิดในเรื่องการกำหนดมาตรฐาน และทุกคนก็ควรปฏิบัติตามมาตรฐานนี้ด้วย นั่นจึงทำให้ Code Tools อย่าง ESLint และ JSHint ได้เกิดขึ้น และจะกลายเป็นสิ่งจำเป็นสำหรับการสร้าง Project
อันที่จริง การกำหนดรูปแบบการเขียน Git Commit อาจจะไม่ได้ซับซ้อนมากขนาดนั้น แต่ถ้าคุณเห็น Commit ที่ยาว ก็อาจทำให้คุณหงุดหงิดตอนที่ต้องย้อนกลับไปยัง Version ก่อนหน้า ดังนั้น คุณควรปฏิบัติตามมาตรฐานเพื่อประโยชน์ของคุณและคนอื่น ๆ ในทีม
2. กฎที่เฉพาะเจาะจง
ลองดูรูปแบบที่ใช้กัน:
- Type: ใช้ระบุประเภทของ Commit โดยอนุญาตให้ใช้ Identifiers เพียง 7 แบบเท่านั้น
- Scope: ใช้เพื่อแสดง Scope ของผลกระทบจาก Commit เช่น Data Layer, Control Layer, View Layer เป็นต้น ซึ่งขึ้นอยู่กับ Project
- Subject: มันเป็นคำอธิบายสั้น ๆ เกี่ยวกับวัตถุประสงค์ของการ Commit ซึ่งไม่ควรเกิน 50 ตัวอักษร
3. การจัดการข้อยกเว้น (Exception handling)
ลองมาดู Exception นี้กันก่อน
เหตุผลที่เกิดการเตือนนี้ก็เพราะ ปัญหา 2 เรื่องใน Commit:
- เรื่องแรก: ใช้ Keywords ที่ไม่เป็นไปตามมาตรฐาน
- เรื่องที่สอง: มีปัญหาที่ค่อนข้างละเอียดมาก เช่น การเว้นวรรคหลัง "Lee:" หายไป
ซึ่งก่อนหน้านั้นพบว่าเกิดความล้มเหลวในการ Commit อยู่ตลอดเวลา จึงจำเป็นต้องบังคับให้ Commit ไปโดยตรง ส่งผลให้ Commit ในอนาคตเกิด Exception เช่นนี้ขึ้น
ดังนั้น ตอนนี้มันจึงกลายเป็นเรื่องที่ยุ่งยาก หากเราจำเป็นต้องแก้ไขข้อผิดพลาดใน Commit ก่อนหน้า คำถามคือ เราจะต้องดำเนินการอย่างไร?
4. จะแก้ไข Commit Information ก่อนหน้า ได้อย่างไร
มันไม่ได้ซับซ้อน เพียงเราแค่ทำตามขั้นตอนเหล่านี้:
- เก็บสถานะของงานที่ไม่เกี่ยวข้องใน Branch ปัจจุบัน
- ย้าย HEAD ไปยัง Commit ที่ต้องการแก้ไข
- ค้นหา Commit ที่ต้องการจะแก้ไข และเปลี่ยนคำว่า "pick" ในบรรทัดแรก เป็นคำว่า "edit"
- เริ่มทำการแก้ไข Bug ของคุณ
- ใช้คำสั่ง “git add” เพื่อเพิ่ม Files ที่แก้ไข เข้าสู่ Staging
- ใช้คำสั่ง “git commit — amend” เพื่อผนวกการแก้ไขเข้ากับการ Commit ครั้งก่อนหน้า
- ใช้คำสั่ง “git rebase — continue” เพื่อย้าย HEAD กลับไปยัง Commit ตัวล่าสุด
- ทำการ Restore Working State ก่อนหน้า
ภารกิจเสร็จสมบูรณ์ แล้วคุณต้องการแก้ไข Commit ทั้งหมดไหม?
5. การใช้งานใน Project
ในตอนนี้ ดันมีปัญหาใหม่เกิดขึ้น: ทำไมถึงได้รับ Warning เมื่อทำการ Commit? สิ่งนี้เกิดขึ้นได้อย่างไร?
ในตอนนี้เราต้องใช้ Node Plugin ที่ชื่อว่า validate-commit-msg เพื่อเช็คว่า Commit message ใน Project นั้นถูกต้องตามมาตรฐานหรือไม่
- ก่อนอื่นให้ติดตั้ง Plugin:
- ใช้วิธีแรกคือ ให้สร้างไฟล์ .vcmrc:
- ใช้วิธีที่สองคือ เขียนลงใน package.json
- แต่ถ้าเราต้องการใช้ Hook Functions ของ ghooks ล่ะ จะทำอย่างไร?
ใน ghooks เราสามารถทำสิ่งต่าง ๆ ได้มากมาย ไม่ใช่แค่ validate-commit-msg เพียงเท่านั้น
สามารถดูรายละเอียดเพิ่มเติม ได้ที่ validate-commit-msg
6. บทบาทของ Commit Specifications
- ให้ข้อมูลเพิ่มเติมเพื่อการแก้ไขปัญหาและการ Rollback ที่ง่ายดายขึ้น
- กรอง Keywords เพื่อการค้นหาที่รวดเร็ว
- สร้าง Documents ได้อย่างสะดวก
7. การสร้าง Change Log
ดังที่กล่าวไว้ก่อนหน้านี้ หากเรา Commit ตามมาตรฐาน การสร้าง Document ก็จะง่ายมาก โดย Document ที่ถูกสร้างขึ้น จะประกอบด้วย 3 ส่วนหลักคือ:
- New features
- Bug fixes
- Breaking changes
แต่ละส่วน จะมีการระบุ Commits ที่เกี่ยวข้อง และมี Links ไปยัง Commits เหล่านั้น แน่นอนว่า Document ที่ถูกสร้างขึ้น สามารถแก้ไขด้วยตนเองได้ ดังนั้น คุณสามารถเพิ่ม Content อื่น ๆ ได้ก่อนที่จะทำการ Publish
ในที่นี้ เราจำเป็นต้องใช้เครื่องมือ Conventional Changelog เพื่อสร้าง Change Log
เพื่อความสะดวก เราสามารถเขียนลงใน "scripts" Field ของ package.json
ด้วยวิธีนี้ จะทำให้การใช้งานง่ายขึ้น:
และตอนนี้เราก็แก้ปัญหาทั้งหมดได้แล้ว
สรุป
และนี่ก็เป็นแนวทางการเขียน Commit ของ Git ที่คุณอาจมองข้าม คำถามคือ หลังจากนี้ คุณยังจะ Commit ตามใจชอบอีกหรือไม่? คุณยังจะใช้คำสั่ง git commit -m “hello Lee” อยู่ไหม?
คำตอบคือ ไม่ เพราะการใช้ hooks จะป้องกันไม่ให้คุณทำอย่างนั้นได้ มิฉะนั้น คุณจะต้องกู้คืน Commit ไปเรื่อย ๆ ซึ่งจะช่วยให้คุณพัฒนานิสัยการ Commit ที่ดีขึ้นได้
ที่มา: https://levelup.gitconnected.com/
รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert
|
|
อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ
|
|
บทความล่าสุด