Git branching strategies vs trunk base development ตอนที่ 3
Branching flow ยอดนิยม
ก่อนหน้านี้ผมเคยเล่าว่า Branching flow หรือ Branching strategy ต้องรองรับสถานการณ์อะไรบ้าง แล้วใน strategy เหล่านี้มี branch ประเภทไหน เอาไว้ใช้ทำอะไร วันนี้ผมจะมาแบ่งปันต่อว่า branching flow ที่ได้รับความนิยมมีอะไรบ้าง แล้วข้อดีข้อเสียเป็นยังไง
GitFlow
Vincent Driessen แนะนำ GitFlow ในปี 2010 เพื่อแบ่งปันแนวคิดการใช้ Git ซึ่งได้รับความนิยมอย่างแพร่หลายในช่วงเวลานั้น
GitFlow ใช้ branch ทุกประเภทที่เคยเล่าไว้ในตอนที่ 2 โดยอยู่อย่างจะถูกรวมใน development branch ที่สมาชิกทุกคนเอาของมา integrate ไว้ใน branch นี้
Trunk ในกรณีนี้จะเก็บ ประวัติของทุกความเปลี่ยนแปลงที่เคยเกิดขึ้นไป production
ข้อดีและข้อเสียของ GitFlow
GitFlow ทำให้ developer ที่ใหม่กับ Git สามารถเริ่มต้นใช้มันได้อย่างรวดเร็วและง่ายมาก โชคร้ายไปหน่อยที่ทิศทางอุตสาหกรรมซอฟต์แวร์พัฒนาไปเผยให้เห็นถึงจุดอ่อนของ GitFlow ในภายหลัง นั่นคือมันมี branch มากมาย โดยเฉพาะ branch ที่อายุยาว ๆ ซึ่งทำให้ทีมต้องปวดหัวกับการ maintain มัน
ถ้าทีมไหนไม่สามารถรักษาวินัยในการคุมให้ feature branch ต่าง ๆ มีอายุสั้น ๆ ได้แล้ว สิ่งที่พวกเค้าต้องเจอคือความยากลำบากในการ merge ของเข้า development branch ใครยิ่ง merge ช้าก็ยิ่งเจอ conflict หนักเข้าไปใหญ่ และแรงที่ต้องใส่ลงไปในการ maintain branch ต่าง ๆ ก็ถ่วงให้ทีมช้าลง
ในปี 2020 Driessen (เจ้าของบทความ) ก็เขียนเพิ่มลงไปใน post ของเค้าว่า GitHub Flow น่าจะเป็นจุดเร่ิมต้นที่ดีกว่า GitFlow สำหรับทีมพัฒนาในยุคนี้ ยุคที่งานพัฒนาส่วนใหญ่จะถูกส่งถึงมือผู้ใช้ผ่าน web แทนที่จะเป็น installed software เหมือนยุคก่อน
GitHub Flow
GitHub ได้แนะนำทางเลือกใหม่แทนที่ GitFlow ซึ่งได้รับความนิยมแพร่หลาย โดย workflow จะมีลำดับดังนี้
- trunk จะต้องอยู่ในสถานะที่พร้อม release เสมอ และตอน release ก็เอาโค้ดจาก trunk นี่แหละไป deploy
- developer แต่ละคนจะแตก feature branch ออกไปจาก trunk เพื่อแก้ไขโค้ดของตัวเอง
- feature branch สามารถถูกเอาไป deploy ใน testing environment เพื่อทำการทดสอบได้ หรือจะ push ใส่ trunk แล้วเอาจาก trunk ไป deploy บน non-production environment ก็ได้
- เราอาจจะแตก release branch อายุสั้น ๆ ออกมาจาก trunk เพื่อเอาไว้เตรียมทำ release ได้
ข้อดีและข้อเสียของ GitHub Flow
เพราะ GitHub Flow มองทุกความเปลี่ยนแปลงเป็น feature branch ทำให้มีของที่ต้อง maintain น้อยกว่า GitFlow มาก branch ที่อายุยาว ๆ มีแค่ trunk อย่างเดียว การ maintain ก็เลยไม่หนักหนาเท่าไหร่ อย่างไรก็ดี ถ้าทีมเผลอปล่อยให้ branch มีอายุยาวหลาย ๆ วัน ก็ยังเจอความปวดหัวจากการ merge ได้อยู่ดี และปัญหาเหล่านั้นจะกระทบ trunk ด้วย ซึ่งอาจจะทำให้ trunk ไม่อยู่ใน state ที่พร้อม release ซึ่งเป็นสิ่งที่รับไม่ได้ใน workflow ชนิดนี้
ปัญหา
ทั้ง GitFlow และ GitHub Flow สามารถทำงานได้ดีในบริบทที่เหมาะสมกับมัน (เช่นเรากำลังทำ version software ที่ต้อง install หรือพัฒนา web ที่ไม่ต้อง track version) อย่างไรก็ดี ทั้งสองแบบมีจุดอ่อนคือมันไม่สนับสนุน continuous integration ซึ่งได้รับการยอมรับมากขึ้น ๆ ใน practice ในการพัฒนาในปัจจุบัน การพึ่งพิง feature branch มันทำให้เราเผลอมองแต่ข้อดีของการ isolate change โดยลืมข้อเสียที่ต้องจ่ายตอน integrate ภายหลังได้ง่าย
กลยุทธ์ที่ดีกว่าสองอันนี้คือกลยุทธ์ที่สนับสนุน continuous integration ซึ่งคือการที่ทุกคนในทีม integrate โค้ดกันบ่อย ๆ (วันละครั้งถือว่าน้อยสุดละ) โชคดีที่มี branching strategy ที่สนับสนุน continuous integration อยู่ ซึ่งก็คือ trunk-based development
ไว้ตอนหน้าเราจะมาเจาะรายละเอียดของ trunk-based development กัน
