Workflow ของการใช้ git ภายในทีม

git workflows

ไม่นานมานี้ ผมเพิ่งมีโอกาสได้อ่านบทความ “มาหาแนวทางการใช้ git ของคุณและทีมกันดีกว่า” ที่หยิบเอาเนื้อหาของบทความ Focusing on a Team Workflow With Git มาเรียบเรียงให้อ่านได้ง่ายขึ้น พอผมอ่านจบก็พบว่าเนื้อหานั้นมีประโยชน์มากๆ จึงได้ติดต่อไปยังคุณ Somkiat Puisungnoen ผู้เขียนบทความดังกล่าว เพื่อขออนุญาตนำเนื้อหามาลงที่ SiamHTML ด้วย ซึ่งพี่เค้าก็ใจดีมากๆ อนุญาตให้ผมนำไปเผยแพร่ต่อได้ ต้องขอขอบคุณอีกทีนะครับ

มาหาแนวทางการใช้ git ของคุณและทีมกันดีกว่า

ต้องยอมรับกันว่าในปัจจุบัน ทีมพัฒนานำ git มาใช้จำนวนมาก
โดยที่หัวใจหลักของการนำ git มาใช้งานคือ workflow การทำงาน
เนื่องจากมันบ่งบอกถึง รูปแบบการสื่อสาร (communication) ของทีม

รูปแบบของ workflow ในการใช้ git นั้นมีหลากหลาย
เนื่องจากตัวมันยืดหยุ่นมากๆ แต่ทีมพัฒนานั้น
จำเป็นต้องตัดสินใจเลือก workflow ว่าจะไปในทิศทางไหน
เพื่อลด conflict ต่างๆ
เพื่อลดความสับสนต่างๆ
เพื่อทำให้ทีมใช้งาน git ได้อย่างเต็มความสามารถ
โดย workflow ที่ดี จะทำให้ทีมมี productivity ที่สูงขึ้น

รูปแบบของ workflow ที่ได้รับความนิยมสูง คือ Git-Flow
โดยในบทความนี้ ก็จะอ้างอิงจาก Git-Flow เช่นกัน
แต่เหนือสิ่งอื่นใด ทีมจะต้องทำการตัดสินใจว่า
จะเลือกใช้ workflow แบบใด เพื่อให้เกิดประโยชน์สูงสุดกับทีม

เริ่มกันเลยดีกว่า …

1. Master Branch จะต้องพร้อม Deploy เสมอ

ระบบงานที่อยู่ใน master branch จะต้องสามารถ deploy ได้เสมอ

ดังนั้น คนในทีมจะต้องสามารถดึง code จาก master branch ไปทำการ build และ deploy ได้ทันที
โดยที่ไม่มี error ใดๆ เกิดขึ้น

และเนื่องจาก master branch คือสิ่งที่แสดงสถานะปัจจุบันของ code ที่อยู่บนระบบ production
ดังนั้น ถ้าต้องการทำ hot fix ก็ให้ทำการสร้าง branch มาจาก master เสมอ

แล้วถ้า master branch ของคุณมันสามารถ deploy ได้เสมอ
นั่นหมายถึงคุณ และ ทีมพัฒนาจะรู้สึกปลอดภัย
ไม่กังวลว่า จะ deploy ได้ถูก version หรือไม่
ไม่ต้องกังวลว่า code จะ conflict หรือไม่
ผมเชื่อว่า ไม่มีใครต้องการสิ่งที่ไม่ดีหรอกนะ

2. รูปแบบของการสร้าง Branch

develop branch เป็น branch หลักสำหรับการพัฒนา

ดังนั้นถ้าใช้รูปแบบการทำงานแบบ feature branch แล้วนั้น
ทุกๆ feature branch จะต้องถูกสร้างมาจาก develop branch เสมอ
เมื่อทำการพัฒนาบน feature branch เสร็จแล้ว
ก็ต้องทำการลบ feature branch และ merge code กลับไปยัง develop branch เสมอ

create feature branch

3. รูปแบบการตั้งชื่อ Branch

ถ้าคุณมีการสร้าง branch ต่างๆ ขึ้นมา จำเป็นจะต้องมีรูปแบบการตั้งชื่อที่ดี
เป็นชื่อที่อธิบายการทำงาน หรือ เป้าหมายได้อย่างชัดเจน
หรือบางครั้งชื่อ branch อาจจะเป็นชื่อที่ขำๆ หรือ ตลกก็ได้
ซึ่งมันขึ้นอยู่กับทีมพัฒนา

ตัวอย่างการตั้งชื่อของ branch มักจะตั้งชื่อ ดังนี้

  • fix-<to do something> สำหรับการ fix bug ต่างๆ
  • release-<version number> สำหรับการ release ระบบออกไปตาม version

4. Rebase แล้วแก้ Conflict ก่อน Merge เข้า Develop

แน่นอนว่า ถ้าคุณใช้ workflow แบบ feature branch ดังนั้น
ในทุกๆ  feature จำเป็นจะต้องสร้าง feature branch จาก develop branch อยู่เสมอ
เมื่อทำการพัฒนา feature เรียบร้อยแล้ว
ก็จะต้อง merge code กลับไปยัง develop branch

แต่ก่อนที่จะทำการ merge code นั้น
คุณควรที่ทำให้มั่นใจก่อนว่า codeใน feature branch
มันจะไม่เกิด conflict กับ code ใน develop branch

ดังนั้น ถ้าเกิด conflict ขึ้นมา คุณควรทำการแก้ไขใน feature branch คุณก่อน
ด้วยการ rebase จากนั้นจึงทำการ merge กลับไปยัง develop branch
หลังจากนั้น คุณก็ลบ feature branch ทิ้งซะ

ขั้นตอนการใช้งานเป็นดังนี้

ปล. ควรระมัดระวังในการใช้งาน rebase ด้วยนะครับ

5. ทำการ Peer Review ซะนะ

เมื่อคุณทำการ merge code จาก feature branch ไปยัง develop branch แล้ว
จำเป็นจะต้อง review code อยู่เสมอ
มันทำให้คุณเห็นว่า code ที่คุณคิดว่ามันทำให้งานเสร็จนั้นเป็นอย่างไร
รวมทั้งทำให้ทีมเห็นด้วยว่า code เป็นอย่างไร
และควรจะต้องปรับแก้อะไรตรงไหน
วิธีการที่มักใช้คือการ Pull request นั่นเอง

แต่อย่าให้มันเป็นปัญหาคอขวดนะครับ …

6.  ปล่อยของดีกว่า

ก่อนที่จะทำการปล่อย release ออกไปต้องทำการ merge code
จาก develop branch มายัง master branch ก่อนเสมอ ดังนี้

ใช้ –no-ff เพื่อทำให้มั่นใจว่า การ merge จะไม่ใช่เป็น fast-forward
รูปแสดงความแตกต่างระหว่าการใช้และไม่ใช้ –no-if

merging feature branch

ปล. อย่าลืมสร้าง tag เพื่อบอก version ของ code ด้วยนะ
โดยที่ version มักอยู่ในรูปแบบ MAJOR.MINOR.PATCH

7. Hot Fix

แน่นอนว่า เราไม่อยากปล่อยของที่มีข้อผิดพลาดออกไปหรอกนะ
แต่เรามักจะทำ !!!

ดังนั้น ถ้าเกิดข้อผิดพลาดเรามักจะต้องทำการแก้ไขให้รวดเร็ว
ดังนั้น ในการแก้ไขก็จะต้องแก้ไขจาก code ใน master branch
ดังนั้น ก่อนทำการแก้ไขจะต้องสร้าง hotfix branch มาจาก master branch เช่นกัน
เพราะว่า master branch มันคือจุดที่สามารถ deploy ได้ตลอดเวลา

เมื่อทำการแก้ไขเรียบร้อย ก็ให้ merge กลับมายัง master branch
และก็ลบ hotfix branch ทิ้งซะ

8. รูปแบบของ Commit Message

ทีมพัฒนาควรตกลงในเรื่อง รูปแบบของ commit message เสมอนะครับ
เพื่อให้ทีมสามารถอ่าน และ เข้าใจ commit message ได้ง่าย

ตัวอย่างของรูปแบบที่ดี

  • ควรใช้ present tense คือ อธิบายว่าปัจจุบันทำอะไร เช่น fix bug เป็นต้น
  • ในบรรทัดแรกของ commit message ควรที่จะสั้นๆ จำนวนตัวอักษรไม่เกิน 50 ตัว
  • commit message ควรจะต้องสอดคล้องกับสิ่งที่ทำจริงๆ

ตัวอย่างของการเขียน commit message ที่ดี

สุดท้ายคุณ หา และ สร้างแนวทางของตัวเอง

รูปแบบ และ แนวทางที่อธิบายมานั้น มันดูดีนะ
แต่เป็นเพียงแนวทางที่ดีเท่านั้น

ส่วนมันจะเหมาะสมกับทีมของคุณหรือไม่นั้น ไม่มีใครบอกได้
คุณ และ ทีม เท่านั้นที่จะบอกได้
ถ้าใช้แล้วมันดีกับทีม ก็ใช้มัน
ถ้าใช้แล้วทีมรู้สึกไม่ดี หรือ รู้สึกว่ามันเป้นภาระ ก็โยนมันทิ้งไปซะ

เนื่องจาก มันจะสะท้อนถึง รูปแบบการทำงานของทีม
เนื่องจาก มันจะสะท้อนถึง รูปแบบการสื่อสารของทีม
และมันจะช่วยให้คุณทำงานกันเป็นทีม
ดังนั้น ทีมจึงต้องเลือกเส้นทางและสร้างทางที่เหมาะสมกับตัวเองขึ้นมาให้ได้ครับ

(Visited 4,790 times, 3 visits today)

Leave a Reply