Be Careful About Branches (ระวังเรื่อง Branch ให้ดี)

จง integrate แต่เนิ่นๆ และ integrate ให้บ่อย หลีกเลี่ยงการใช้ long-lived branches สำหรับการพัฒนาฟีเจอร์ แล้วลองพิจารณาใช้ trunk-based development แทน ถ้าคุณจำเป็นต้องใช้ branch จริงๆ ก็ให้มันมีอายุสั้นที่สุด!

นอกเหนือจากประสบการณ์ส่วนตัวของผมแล้ว ยังมีงานวิจัยเพิ่มขึ้นเรื่อยๆ ที่แสดงให้เห็นถึงประสิทธิภาพของการลดจำนวน branch และการนำ trunk-based development มาใช้ รายงาน 2016 State of DevOps โดย DORA และ Puppet 1 ได้ทำวิจัยอย่างเข้มงวดเกี่ยวกับแนวปฏิบัติด้าน delivery ขององค์กรต่างๆ ทั่วโลก และศึกษาว่าแนวปฏิบัติใดที่ทีมที่มีประสิทธิภาพสูงมักใช้กัน:

เราพบว่าการมี branch หรือ fork ที่มีอายุสั้นมาก (น้อยกว่าหนึ่งวัน) ก่อนจะถูก merge เข้า trunk และมี active branch รวมกันน้อยกว่าสามอัน เป็นแง่มุมสำคัญของ continuous delivery และล้วนมีส่วนช่วยให้ performance สูงขึ้น เช่นเดียวกับการ merge โค้ดเข้า trunk หรือ master เป็นประจำทุกวัน

รายงาน State of DevOps ยังคงสำรวจหัวข้อนี้อย่างลึกซึ้งต่อไปในปีถัดๆ มา และยังคงพบหลักฐานที่ยืนยันประสิทธิภาพของแนวทางนี้อย่างต่อเนื่อง

แนวทางที่ใช้ branch หนักๆ ยังคงพบเห็นได้ทั่วไปในการพัฒนา open source มักผ่านการใช้โมเดลการพัฒนาแบบ "GitFlow" ควรสังเกตว่าการพัฒนา open source นั้นไม่เหมือนกับการพัฒนาในชีวิตประจำวันทั่วไป การพัฒนา open source มีลักษณะเฉพาะคือมีผู้ร่วมพัฒนาแบบ ad hoc จำนวนมากที่เป็น "untrusted" committer ซึ่งมีเวลาจำกัด และการเปลี่ยนแปลงของพวกเขาต้องผ่านการตรวจสอบโดย "trusted" contributor จำนวนน้อยกว่า ในขณะที่การพัฒนา closed source ในชีวิตประจำวันทั่วไปมักทำโดยทีมที่แน่นแฟ้น ซึ่งสมาชิกทุกคนมีสิทธิ์ commit แม้ว่าพวกเขาจะเลือกใช้กระบวนการ code review บางรูปแบบก็ตาม ดังนั้นสิ่งที่ได้ผลกับการพัฒนา open source อาจไม่ได้ผลกับงานประจำวันของคุณ กระนั้นก็ตาม รายงาน State of DevOps ปี 2019 2 ที่สำรวจหัวข้อนี้เพิ่มเติม ได้พบข้อมูลเชิงลึกที่น่าสนใจเกี่ยวกับการพัฒนา open source และผลกระทบของ branch ที่ "มีอายุยืนยาว" :

ผลการวิจัยของเราขยายไปถึงการพัฒนา open source ในบางด้าน:

• การ commit โค้ดเร็วขึ้นนั้นดีกว่า: ในโปรเจกต์ open source หลายคนสังเกตเห็นว่าการ merge patch ให้เร็วขึ้นเพื่อป้องกันการ rebase ช่วยให้นักพัฒนาทำงานได้เร็วขึ้น
• การทำงานเป็นชุดเล็กๆ นั้นดีกว่า: "patch bomb" ขนาดใหญ่ merge เข้าโปรเจกต์ได้ยากและช้ากว่า patchset ขนาดเล็กที่อ่านง่ายกว่า เพราะ maintainer ต้องใช้เวลามากขึ้นในการ review การเปลี่ยนแปลง

ไม่ว่าคุณจะทำงานกับ codebase แบบ closed-source หรือโปรเจกต์ open source การใช้ short-lived branch, patch ขนาดเล็กที่อ่านง่าย และการทดสอบการเปลี่ยนแปลงแบบอัตโนมัติ ล้วนช่วยให้ทุกคนมี productivity สูงขึ้น