[Git Flow] ทำความเข้าใจ Git Flow และ Code Review

บทความนี้ต้องบอกก่อนว่าใครยังใช้ Git ไม่คล่องหรือไม่รู้จักเลย ผมแนะนำว่าให้ไปอ่านเรื่อง Git หรือพวก Source Control ก่อน เพราะผมจะไม่ไล่พื้นฐานให้กับคนที่เข้ามาอ่านบทความนี้ครับ โดยตัวนี้ผมจะเน้นไปทางการปฏิบัติเพื่อทำให้เห็นถึงประโยชน์เผื่อว่าเราจะเอาไปปรับใช้กับการจัดการทีมเขียนโค้ดของคุณหรือโปรเจคของคุณเอง โดยบทความนี้เราจะมาเน้นการจัดการ Branch ด้วย Git Flow และการทำ Review code โดยใช้ Pull Request

 

What’s a Git Flow

ปกติทั่วไปเราจะใช้ Git เพื่อเก็บโค้ดและแชร์โค้ดกันในทีม ซึ่งเราจะมี Timeline การทำงานแบบว่าง่าย สมมุติให้มีคนสองคน คือ Jonh กับ Mary ก็ checkout โค้ดจาก Master มาแก้งานใครทำเสร็จก็ push  ปกติเราก็จะทำแบบนี้ ไม่ว่าจะแก้บัค หรือเพิ่ม Feature ใหม่ๆ ตามที่หัวหน้าสั่ง ฝ่ายการตลาดขอมา หรือลูกค้าขอแก้ ปัญหาที่ตามมาคือ conflict แน่นอน ซึ่งหลีกเลี่ยงไม่ได้ไม่ว่าจะเกิดจากการ Pull โค้ดลงมาหรือ Merge Branch ก็ตาม ที่นี้ผมจะมาแนะนำให้ใช้ Git Flow ให้ไม่ conflict ระหว่างที่เรากำลังทำงานอยู่และโค้ดไม่ไปปนกับของคนอื่น และเพื่อให้ระบบการบริหารงาน การ deploy production เป็นไปอย่างสมบรูณ์ เราจะมาดูกันว่า Git Flow  ช่วยอะไรได้บ้าง

Git Flow จะใช้ความสามารถของ Branch ให้เป็นประโยชน์ โดยจะแยก Branch ออกมาเป็น 3 อันหลักๆ เพื่อแยกวงจรการพัฒนาระบบในแต่ละขั่นให้เห็นภาพชัดเจนและแยกโค้ดออกจากกันโดยสิ้นเชิง ดังนี้

 

Feature branch

เราจะแตกออกมาจาก develop เท่านั่น เพื่อพัฒนาฟีเจอร์ใหม่ๆ ของระบบ หรือพัฒนาระบบในเวอร์ชันอะไรทำนองนั่นครับ เมื่อเราทดสอบฟีเจอร์นั่นนิ่งแล้วเราก็เอามันกลับเข้าไปที่ develop วิธีการสร้าง Feature ก็ง่ายๆ ตามคำสั่งด้านล่าง ปล. ผมแนะนำวิธีที่สองครับ

 

Release branch

เราจะแตกออกมาจาก develop เท่านั่น เพื่อเตรียมการ deploy ระบบในเวอร์ชันใหม่ๆ อย่างเช่นเมื่อเราพัฒนาระบบและฟีเจอร์จนพอใจแล้วเราก็แยก realease ออกมาแล้วใส่เลขเวอร์ชั่นไป โดยเมื่อแตกออกมาแล้วสิ่งที่มักจะทำต่อไปก็คือแต่แก้บัค ทำ Document หรือพัฒนาต่อเพื่อให้ระบบเกิดความสเถียรเพื่อรอขึ้นเป็น new version ต่อไป วิธีการสร้างเราก็จะมีการใส่เลขเวอร์ชั่นที่ชื่อ Branch เช่น

เมื่อพัฒนาเสร็จแล้วเราก็เอากลับเข้ารวมกับ develop และ master แล้วอย่าลืมสร้าง tag ให้มีเลขตรงกับ realease เวอร์ชั่นที่เราแตกออกมาด้วย เช่น

 

Hotfix branch

เราจะแตกออกมาจาก master เท่านั่น ในกรณีที่ production ที่เราปล่อยออกไปแก้มีปัญหาอาจจะบัค หรืออะไรก็ตามแต่ โดยมากมักจะเป็นพวก critical bug ใน production หรืออะไรที่ต้องแก้โดยด่วน เราก็จะแตกมันออกมาเพื่อแ้กบัคนั่น หรืออีกทางนึงเขาเรียก Maintenance Branch และเราก็จะติด tag เป็น 0.2.1 (ยกเลขมาจาก release ด้านบน) วิธีการทำก็คือ

เมื่อพัฒนาเสร็จแล้วเราก็เอากลับเข้ารวมกับ develop และ master แล้วอย่าลืมสร้าง tag ให้มีเลขตรงกับ hotfix เวอร์ชั่นที่เราแตกออกมาด้วย เช่น

 

[Code review] Complete git workflow by pull request

ไม่ใช่แค่การแตก branch แล้วก็ merge กลับเข้าจะเพียงพอต่อการทำให้ flow งานนั่นดีขึ้น แต่เพื่อให้ทุกอย่างเป็นระบบขึ้นไปอีกทุกครั่งที่ commit เราควรจะทำ code review ก่อน โดยการเปิด pull request บน git ของเราที่เราใช้อยู่ จึงค่อยสั่ง merge เพื่อไม่ให้เกิดความผิดพลาดขึ้นโดยเฉพาะ hotfix ที่ต้องรีบแก้ เพราะงั่นแนะนำให้ senior ของทีมอย่างน้อยสองคน อนุมัติโค้ดให้ผ่านจึงจะค่อย merge หรือถ้า junior ควรจะ 2 คนและมี senior 1 คนเพื่อความแน่นอน

 

Demo

 

Summery

ข้อดีของ Git Flow

  • ช่วยให้เรา revert โค้ดได้ในกรณีที่เราเกิดปัญหา เราสามารถสลับ Branch อย่างเช่นพวก release เวอร์ชันต่างๆ
  • ช่วยให้งานเป็นระบบมากขึ้น
  • ทำให้ไม่กระทบกับโค้ดใน Branch หลัก ถ้าเกิดมีคน commit มาแล้วทำให้โค้ดพังหรืออะไรกตามแต่ ดังนั่นเมื่อพังก็จะไปแก้แค่ใน Branch ที่คนนั่นแตกออกไป
  • ทำให้เราแยก config หลายๆ อย่างออกจากกันได้เมื่อพัฒนาเสร็จจึงค่อยเอามารวมกันในจุดเดียว

ข้อดีของ Pull Request

  • ทำให้เราสามารถเห็นโค้ดที่ถูกเปลี่ยนและตัดสินใจได้ว่าโค้ดนั่นควรจะให้ขึ้นมาใน production ได้ไหม
  • ทำให้ลดความเสี่ยงที่จะมีใครก็ตาม commit โค้ดขึ้นมาแล้วทำให้โปรเจคพัง

ข้อดีของการรีวิวโค้ด

  • ทำให้คำนวน performance ของการทำงานโค้ดได้ เพื่อประสิทธิภาพของโปรแกรม
  • ทำให้แชร์ความรู้ด้าน Programming กันได้ หลายๆ คนหลายๆ ความคิดมาจากหลายประสบการณ์
  • ทำลดการเกิดบัคหลังจากที่ merge ไปแล้ว เพราะเรามีคนช่วยดูหลายคน

git-model2x

Facebook Comments