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

อ่านบทความเรื่อง Focusing on a Team Workflow With Git แล้วน่าสนใจ
เลยนำมาแปล และ สรุป กันหน่อย
มาดูกันว่า ทีมพัฒนาควรจะใช้ Git อย่างไรดี
รวมทั้งมี workflow การทำงานอย่างไรดี

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

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

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

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

1. สิ่งสำคัญที่สุด Master branch จะต้องพร้อม deploy เสมอ โดยไม่มีข้อยกเว้น

เนื่องจาก master branch คือสิ่งที่สำคัญสุดๆ
ดังนั้น ระบบงานที่อยู่ใน master branch ต้องสามารถ deploy ได้เสมอ

ดังนั้นใน master จะต้อง

คนในทีมสามารถดึง 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 ที่มักถูกสร้างขึ้นมาจากทีม
เป็น branch หลักสำหรับการพัฒนา

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

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

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

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

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

4. ในการ merge code ด้วยแนวคิดการ rebase อยู่เสมอ

แน่นอนว่า ถ้าคุณใช้ 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 ไปซะ

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

git checkout my-awesome-feature
git rebase develop
git checkout develop
git merge my-awesome-feature

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

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

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

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

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

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

git checkout master
git merge --no-ff develop

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

ปล. อย่าลืมสร้าง 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

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

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

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

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

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

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

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

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