วิธีจัดการ Git เวอร์ชันคอนโทรลให้ดี

1. กำหนดกลยุทธ์การใช้บรันช์แบบเดียวกัน

   • เมื่อสมาชิกทีมที่มีความรู้เฉพาะทางหลากหลายทำงานร่วมกัน แนวทางการเข้าถึงเวิร์กโฟลว์อาจขัดแย้งกันได้
   • เพื่อป้องกันปัญหานี้ ผู้นำควรกำหนดกลยุทธ์การใช้บรันช์แบบเดียวและสื่อสารให้ทุกคนรับทราบ
   • การตัดสินใจเลือก branch workflow อาจแตกต่างกันไปตามหลายปัจจัย เช่น ขนาดทีม ระดับประสบการณ์ ความต้องการด้านการขยายระบบ และข้อจำกัดของงาน
   • ทีมพัฒนาสามารถใช้เวิร์กโฟลว์ที่กำหนดไว้แล้ว หรือออกแบบเวิร์กโฟลว์ให้เหมาะกับความต้องการของทีมก็ได้
   • สิ่งที่เวิร์กโฟลว์อาจรวมไว้
     • Centralized workflow: มีรีโพซิทอรีเดียวและ master branch เดียว มีความเสี่ยงที่การเปลี่ยนแปลงจะถูกเขียนทับ
     • Feature branch: ทุกครั้งที่เพิ่มฟีเจอร์ใหม่จะสร้างบรันช์ใหม่ และทำคอมมิตที่เกี่ยวข้องกับฟีเจอร์นั้นใน feature branch ดังกล่าว
     • Git Flow: เป็นรูปแบบสุดโต่งของ feature branch ในการพัฒนาด้วย Git Flow จะมี master และ development branch แยกจากกัน รองรับ feature, release และ hotfix branch โดยพัฒนาบน development branch ย้ายไปยัง release branch แล้ว merge เข้าสู่ master branch
     • Task-branch development: GitLab Flow เป็นตัวอย่างของรูปแบบการพัฒนาประเภทนี้ เป็นการพัฒนาแบบยึดฟีเจอร์เป็นศูนย์กลางและผสาน feature branch เข้ากับการติดตาม issue โดย GitLab Flow ใช้บรันช์เฉพาะแยกต่างหากเพื่อดูแลหลายสภาพแวดล้อม เช่น staging, การทดสอบบน production และ production เพื่อให้แน่ใจว่าการเปลี่ยนแปลงที่คอมมิตถูกทดสอบข้ามทุกสภาพแวดล้อม
   • ผลต่อการทำงานร่วมกัน:
     • เมื่อทุกคนทำงานสอดคล้องกันบนเวิร์กโฟลว์เดียวกัน โอกาสที่จะเขียนทับโค้ดหรือทำให้ master branch เสียหายจะลดลง
     • ผู้ร่วมงานทุกคนจะคุ้นเคยกับกระบวนการพัฒนาและการ deploy ทำให้สมาชิกทีมมีส่วนร่วมกับงานของกันและกันได้ง่าย
     • กลยุทธ์การใช้บรันช์ที่ชัดเจนและกระชับจะนำไปสู่วงจรที่ดีของการ merge โค้ดใหม่และพัฒนาโปรเจกต์ต่อเนื่อง
     • สภาพแวดล้อมลักษณะนี้ช่วยให้สมาชิกทีมจัดประชุม จัดการกำหนดส่ง และปริมาณงานได้ดีขึ้น
     • ผลกระทบของแต่ละเวิร์กโฟลว์ต่อการทำงานร่วมกัน
       • Centralized workflow: เหมาะกับทีมขนาดเล็ก (นักพัฒนาน้อยกว่า 5 คน) ที่สามารถสื่อสารกันได้ดี เพื่อไม่ให้นักพัฒนา 2 คนทำงานซ้ำบนโค้ดเดียวกันพร้อมกัน
       • Feature branch และ GitFlow: ต้องการ code review มากขึ้น มีกฎการ push, ผู้อนุมัติโค้ด และการทดสอบที่ครอบคลุมมากขึ้น จึงช่วยเชื่อมโยงทีมที่หลากหลาย
       • Task-branch development: ช่วยให้สมาชิกทีมแตก requirement ออกเป็นก้อนฟีเจอร์เล็ก ๆ ที่ส่งต่อผ่าน task branch เวิร์กโฟลว์นี้รวมแนวปฏิบัติการทำงานร่วมกัน เช่น code snippet, code review และ unit test หากการทดสอบล้มเหลว สมาชิกทีมจะร่วมกันตรวจสอบว่าเกิดอะไรผิดพลาด

2. คอมมิตบ่อย ๆ ในหน่วยย่อย

   • หากให้ความสำคัญกับความสมบูรณ์แบบเป็นอันดับแรก อาจลงเอยด้วยการคอมมิตครั้งใหญ่เฉพาะตอนที่โปรเจกต์ใกล้เสร็จแล้ว
   • หากข้ามการตรวจสอบฟีเจอร์แบบง่าย ๆ และขั้นตอนย่อย ๆ อาจพัฒนาฟังก์ชันผิดพลาดหรือเสียเวลาไปกับทิศทางที่ไม่ถูกต้อง
   • ควรคอมมิตทุกครั้งที่มีทั้งการทดสอบที่ใช้งานได้และโค้ดที่พร้อมทำงาน
   • ควรทำให้โปรเจกต์ง่ายลงเป็นขั้นตอนเล็ก ๆ และหาวิธีไปให้ถึงเป้าหมายใหญ่ด้วยการคอมมิตอย่างสม่ำเสมอ
   • ผลต่อการทำงานร่วมกัน:
     • เมื่อมีวัฒนธรรมการคอมมิตบ่อย ทุกคนจะมองเห็นสิ่งที่เกิดขึ้นในรีโพซิทอรีและเข้าใจได้ง่ายว่าทีมอื่นกำลังทำอะไรอยู่
     • หากแชร์งานผ่าน feature branch หรือ merge request จะช่วยป้องกันการทำงานซ้ำซ้อนของทีมอื่นได้
     • แม้งานยังไม่พร้อมสำหรับการรีวิว ก็ควร push ไปยัง feature branch บ่อย ๆ
     • การแชร์งานก่อนเสร็จสมบูรณ์จะกระตุ้นการพูดคุยและ feedback ทำให้ปรับปรุงคุณภาพได้ก่อนถึงขั้น code review
     • การแบ่งงานออกเป็นหลายคอมมิตช่วยให้ทั้งนักพัฒนาและทีมอื่นใช้เป็นข้อมูลที่มีประโยชน์เมื่อทบทวนโค้ดในอนาคต
     • สามารถระบุได้อย่างชัดเจนเป็นรายคอมมิตว่าฟีเจอร์นั้นถูกพัฒนามาอย่างไร
     • สามารถคงประวัติการเปลี่ยนแปลงที่ไม่เกี่ยวข้องไว้ พร้อม rollback ไปยังช่วงเวลาที่ต้องการ หรือย้อนเฉพาะการเปลี่ยนแปลงโค้ดบางส่วนได้

3. เขียนข้อความคอมมิตให้ละเอียด

   • ข้อความคอมมิตควรสะท้อนทั้งเนื้อหาของคอมมิตและเจตนาของนักพัฒนา
   • ควรอธิบายผ่านข้อความคอมมิตว่าทำไมจึงเกิดการเปลี่ยนแปลงนั้น
   • ตัวอย่างข้อความคอมมิตที่ดี: “รวมเทมเพลตเพื่อลดโค้ดซ้ำในหน้าจอผู้ใช้”
   • คำอย่าง ‘เปลี่ยนแปลง’, ‘ปรับปรุง’, ‘แก้ไข’, ‘ปรับโครงสร้าง’ ในข้อความคอมมิตไม่ได้ให้ข้อมูลที่มีประโยชน์มากนัก
   • ผลต่อการทำงานร่วมกัน:
     • ข้อความคอมมิตที่ละเอียดช่วยเพิ่มความโปร่งใสและมองเห็นความคืบหน้า ช่วยให้สมาชิกทีม ลูกค้า และผู้มีส่วนร่วมในอนาคตเข้าใจกระบวนการพัฒนา
     • เมื่อต้องทำ code review ข้อความคอมมิตช่วยให้ทำตามขั้นตอนที่ทำซ้ำได้ และช่วยตรวจสอบการเปลี่ยนแปลงที่เกิดขึ้นหลังการรีลีส การหารือ หรือการเปลี่ยน requirement
     • ข้อความคอมมิตที่ละเอียดช่วยให้ทีม QA และทีมความปลอดภัยระบุจุดที่มีปัญหาระหว่างตรวจสอบโค้ด และช่วยย้อนการเปลี่ยนแปลงเฉพาะจุดได้
     • การเขียนข้อความคอมมิตอย่างละเอียดช่วยลดการทำงานซ้ำของสมาชิกทีมอื่น ลดความล่าช้า และทำให้ความคืบหน้าของโปรเจกต์ดำเนินไปอย่างมั่นคง

4. พัฒนาโดยใช้บรันช์

   • การพัฒนาบนบรันช์ก็เหมือนการคัดลอกสถานะปัจจุบันจากบรันช์หนึ่งมาใช้ทำงาน
   • การใช้บรันช์ช่วยให้เปลี่ยนแปลงโค้ดได้โดยไม่กระทบ codebase หลัก
   • ประวัติการเปลี่ยนแปลงจะถูกจัดการอยู่ภายในบรันช์
   • เมื่อโค้ดพร้อมแล้วสามารถ merge เข้าสู่ master branch ได้
   • การเขียนโค้ดบนบรันช์ช่วยให้เข้าถึงการพัฒนาได้อย่างเป็นระบบมากขึ้น
   • สามารถแยกจัดการฉบับร่างที่กำลังพัฒนาออกจาก master code ที่ผ่านการทดสอบอย่างเสถียรแล้วได้
   • ผลต่อการทำงานร่วมกัน:
     • เปิดโอกาสให้สมาชิกลองใช้แนวทางใหม่ ๆ และการทดลองเพื่อแก้ปัญหาที่ซับซ้อน
     • ทีมพัฒนาสามารถท้าทายอย่างสร้างสรรค์ได้โดยไม่ต้องกังวลว่าจะกระทบ master branch
     • สามารถทำงานร่วมกันเพื่อตรวจสอบว่าโซลูชันทำงานได้ถูกต้องก่อน merge เข้า master branch
     • ทีม operations, QA และ security สามารถตรวจสอบโค้ดก่อน deploy และทำให้ทุกคนมีโอกาสเสนอไอเดียรวมถึงอภิปรายปัญหาที่อาจเกิดขึ้นก่อนการรีลีส

5. ทำ code review อย่างสม่ำเสมอ

   • เพื่อรับประกันการปรับปรุงอย่างต่อเนื่องและป้องกันโค้ดที่ไม่เสถียร
   • เมื่อมีโค้ดที่ต้องตรวจสอบ ควรขอ code review จากเพื่อนร่วมงาน สมาชิกทีม หรือผู้เชี่ยวชาญในโดเมนที่เข้าใจโปรเจกต์เป็นอย่างดี
   • สิ่งที่ควรระวังเมื่อทำ code review:
     • อธิบายว่าจำเป็นต้องเปลี่ยนอะไร
     • เสนอทางเลือกได้ แต่ควรตั้งสมมติฐานว่านักพัฒนาได้พิจารณาเรื่องนั้นมาแล้ว
     • แม้ในกระบวนการแก้ปัญหา ก็ควรมองหาวิธีทำให้โค้ดเรียบง่ายขึ้น
   • ผลต่อการทำงานร่วมกัน:
     • code review ช่วยนำเสนอมุมมองอื่นเกี่ยวกับการแก้ปัญหาและการนำไปใช้จริง
     • เป็นอีกสายตาหนึ่งที่ช่วยค้นหาบั๊ก ปัญหาเชิงตรรกะ หรือ corner case ที่อาจเกิดขึ้น
     • ช่วยลดปัญหาที่อาจเกิดขึ้นระหว่างฝ่าฟันประเด็นยาก ๆ และเร่งไปสู่การรีลีส
     • สามารถรีวิวผ่านการตรวจสอบแนวทางแก้ปัญหา การเสนอความคิดเห็น และความร่วมมือของสมาชิกทีม
     • สามารถเรียนรู้รูปแบบการเขียนโค้ดที่หลากหลาย เทคนิคเวิร์กโฟลว์ และวิธีแก้ปัญหาใหม่ ๆ ได้