เมื่อวาน (วันที่ 9/1/2558) มีการถกเถียงกันในกลุ่มเฟชบุกที่ชื่อ https://www.facebook.com/groups/440497309296387/ เรื่อง gitflow เรียกได้ว่าทำเอาคึกคักกันเลยทีเดียว

ในบทความนี้ผมจะอธิบายความเข้าใจของผมต่อเรื่อง gitflow ให้ฟัง บอกไว้ก่อนนะครับว่า มันจะเหมาะกับคนที่ใช้งาน git เป็นแล้วเท่านั้น ใครที่ไม่เคยใช้ก็ข้ามๆไปครับ

เล่าก่อนว่า git นั้นมันมีฟีเจอร์ๆหนึ่ง คือความสามารถในการแตก branch ใช่มั้ย การแตก branch ก็เพื่อจะให้การเขียนโค้ดเป็นทีม บริหารจัดการง่าย สมมติ ในบริษัทมี 2 ทีม ประชุมกันแล้วว่าจะให้ 2 ทีมนี้ทำกันคนละฟีเจอร์ ก็แตก branch ไปให้ทีมละ branch โค้ดก็จะได้ไปปะปนกัน ในขั้นตอนการพัฒนา (พัฒนาเสร็จค่อยเอามันมารวมกัน) git นั้นมันไม่ได้บอกในตัวมันเองหรอกว่า ต้องแตก branch อย่างนั้นอย่างนี้ เท่านั้น branch เท่านี้ branch ไม่เลย มึงไปแตกกันเอาเอง กูมีคุณสมบัติยังเงี้ยให้มึงใช้  ไปประชุมจัดการกันซะ

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

เขาว่ายังงี้

1. เมื่อจะพัฒนาฟีเจอร์ใหม่ ให้แตก branch Feature มาจาก Develop ให้ทีมพัฒนาโค้ดกันใน branch นั้น เมื่อพัฒนาเสร็จให้ merge โค้ดเข้า Develop แล้วลบ branch Feature ทิ้ง

2. เมื่อจะเอาโค้ดขึ้นโปรดักชั่น ให้แตก branch Release ออกมาจาก Develop ให้ Tester ตรวจสอบว่าโปรแกรมทำงานถูกต้องหรือเปล่า มีบักหรือเปล่า หากมีบักก็แก้ใน Branch Release เลย จนเมื่อโปรแกรมถูกต้องสมบูรณ์จึง merge เข้า Master เพื่อเอาขึ้นโปรดักชั่นต่อไป อย่าลืม Tag เวอร์ชั่น และ merge เข้า Develop ด้วยจากนั้นจึงลบ branch Release ทิ้ง

3. ทีนี้หลังจากที่เอาโค้ดขึ้นโปรดักษ์ชั่นแล้ว มันอาจจะพบบักที่ไม่คาดฝัน อาจจะเพราะ environment เครื่องหรืออะไรก็แล้วแต่ ซึ่งจำเป็นต้องรีบแก้ ให้แตก branch Hotfix ออกมาจาก Master แล้วแก้ไขบักซะ หลังจากแก้ไขเสร็จแล้ว ให้ merge โค้ดเข้าไปยัง Master แล้วลบ branch Hotfix ทิ้ง

จากภาพ เราจะเห็นวิธีการตั้งเวอร์ชั่นของโปรแกรมที่เราเขียนด้วย ถ้าหากเป็นการเอาโค้ดจาก Release ขึ้นโปรดักชั่น เขาจะใช้หมายเลขเวอร์ชั่นใหญ่ เช่น 1.0, 2.0, 3.0 แต่ถ้าเป็นการ Hotfix เขาจะใช้เลขเวอร์ชั่นย่อย เช่น 1.1,  1.2, 2.1, 3.1 เป็นต้น

จากที่กล่าวมา 3 ข้อด้านบน จะเห็นว่ามีการ สร้าง branch , merge branch, ลบ branch วนๆซ้ำไปซ้ำมา เวลาคุยกันในทีม มันก็กลายเป็นคำภาษาเทคนิคไป  คนที่เขาเสนอแนวทาง gitflow ก็เลยสร้างชุดคำสั่งเสริมเข้าไปใน git เพิ่มเติม เพื่อให้ฟิลลิ่งมันระรื่น  feature start, feature finish, release start, release finish, hotfix start, hotfix finish  อ้างอิง https://github.com/nvie/gitflow/wiki/Command-Line-Arguments

เบื้องหลังการทำงานของคำสั่งก็คือ แตก branch, merge โค้ด, ลบ branch ให้นั่นเอง

การจะใช้ gitflow นั้น ให้พยายามทำความเข้าใจจากภาพที่เขาวาดอธิบายแหละว่า แนวความคิดมันเป็นยังไง  เราอาจจะไม่ใช้คำสั่งตระกูล gitflow ( feature start, feature finish, release start, release finish, hotfix start, hotfix finish ) ก็ได้ อาศัยการแตก branch, merge โค้ด, ลบ branch เอง มันก็ยังเป็น gitflow อยู่ดี

อือนี่ เอามาให้ดูว่า มันมี workflow หลายแบบ (เพิ่งรู้ว่า เราทุกคนใช้ gitflow กันโดยไม่รู้ตัว) มีแบบโซ้ยใน master เลยด้วยนะ

http://blog.endpoint.com/2014/05/git-workflows-that-work.html

วัชรเมธน์ ชิษณุคุปต์ ศรีเนธิโรทัย

Programmer, Blogger

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