[Git Flow] หัวข้อเชิงลึก Git Branching Models และการทำ Git Flow

จากบทความตอนที่แล้ว เรื่องการใช้งาน Git Flow และ Code review ไปสั่นๆ ในบทความนี้ผมก็จะมาต่อเรื่องการพูดถึงเรื่อง Git Flow ต่อแต่เราจะมาเน้นกันด้วยคำสั่ง git flow กันโดยตรงเพื่อจัดการ Branch และอธิบายว่ามันทำงานยังไง เราเริ่มกันที่ทำความเข้าใจเรื่อง Branch อีกรอบ

 

Normal Branching Models

เราจะมาดูโครงสร้างทั่วไปของของ git เวลาเราใช้งานแบบปกติกัน

Master branch

ปกติเวลาสร้าง git ขึ้นมาเราจะได้ default คือ Master ซึ่งมันคือ Branch สำหรับ deploy prodution  และมันเป็น stable code แล้วและเราก็จะติด Tag ให้กับทุกๆ เวอร์ชันที่เรา deploy เพื่อเป็นการติดตามว่าระบบที่ทำงานอยู่ใน server ที่ลูกค้ากำลังใช้งานอยู่คือเวอร์ชันอะไรและฟีเจอร์อะไรในเวอร์ชันนี้ และถ้าเกิดปัญหาในเวอร์ชันใหม่ที่เรา deploy ไปเราก็จะสามารถ roll back กลับมาเวอร์ชันก่อนหน้าโดยดูจาก Tag แทนการอ่านชื่อ Commit

 

Develop branch

เมื่อเราสร้างโปรเจคใหม่ปกติเราจะได้ Master branch ซึ่งโดยปกติแล้วเราจะ clone ออกมาอีกอันคือ develop branch สำหรับพัฒนาระบบอย่างเดียว จะไม่ยุ่งกับ Master เพราะตรงนั่นเราจะตั่งค่าต่างๆ เป็นการใช้งานจริงไม่มี Environment test แล้ว พร้อมที่จะปรับเปลี่ยน หรือ deploy ระบบได้ตลอดเวลา ส่วนตรงนี้จะเป็นศูนย์รวมของการพัฒนาระบบ ไม่ว่าจะเป็นฟีเจอร์ต่างๆ หรือเทสก็ตาม เราจะทำการยำกันได้เต็มที่ตรงนี้ พังก็ทำใหม่

 

Workflow Branching Models

พอมันเราหันมาเริ่มทำ Git Flow มันทำให้เราต้องสร้าง Branch เพิ่มเพื่อมาจัดการกระบวนการทำงานเพิ่มขึ้นโดยผมขอยกเอาคำพูดที่เขียนบทความก่อนมาต่อยอดอธิบายให้อ่านอีกรอบ

 

Feature branch

เราจะแตกออกมาจาก develop เท่านั่น เพื่อพัฒนาฟีเจอร์ใหม่ๆ ของระบบ หรือพัฒนาระบบในเวอร์ชันอะไรทำนองนั่นครับ ซึ่งใน 1 Feature ที่แตกออกจาก Develop เราจะพัฒนาแค่ 1 Feature เท่านั่น เช่น ระบบ Login เมื่อทำเสร็จก็เอากลับเข้าไปใน Develop ย้ำว่าเอาเข้า Develop นะครับ แล้วลบ branch ทิ้งไป เราจะไม่ทำ Login หรือ Logout พร้อมกัน 2 Feature พร้อมกัน (จริงๆ Login, Logout มันรวมกันได้ผมยกตัวอย่างเฉยๆ มันง่ายดี) นอกจากนี้เรายังเอาไว้แตกมาแก้บัคด้วย

 

Release branch

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

 

Hotfix branch

เราจะแตกออกมาจาก master เท่านั่น ในกรณีที่ production ที่เราปล่อยออกไปแก้มีปัญหาอาจจะบัค หรืออะไรก็ตามแต่ โดยมากมักจะเป็นพวก critical bug ใน production หรืออะไรที่ต้องแก้โดยด่วน เมื่อแก้เสร็จเราจะต้องเอากลับเข้าไปใน Master เพื่อ Deploy ระบบอีกรอบ และเอาไปรวมกับ Develop เพื่อแก้บัคในของ Develop ด้วยแต่เราจะให้ความสำคัญกับ Master ก่อนเพราะต้องรีบแก้

โดยสรุปคือระบบ Branching Models ของ Git จะมีดังนี้ ที่ควรจะทำไว้ในโปรเจค

  • Master
  • Develop
  • Hotfix
  • Release
  • Feature

โดยเรามาดู Flow ทั่งหมดกันว่าระบบงานเราจะมี Timelime แบบไหน

git-model2x

จากรุปจะเห็นว่า Feature จะไม่มีทางไปยุ่งกับ Master ได้เลยจนกว่าจะได้รับการ Merge เข้า Develop และ Maser จะถูกควบคุมโค้ดด้วย Release เท่านั่น จะเห็นว่าใน Timeline เราจะไม่มีการ Merge develop ไปหา Master ตรงๆ และ Hotfix จะต้องถูกรวมกับทั่ง Develop และ Master

 

Installing GitFlow

เมื่อบทความที่แล้ว [link] ผมสอนวิธีการสร้าง flow ด้วยคำสั่งพื้นฐานของ git ไปครั่งนี้ผมจะมาสอนโดยใช้คำสั่ง git flow จริงๆ แต่จริงๆ เราใช้ได้ทั่งสองอันแล้วแต่คนชอบ มาเริ่มกันที่ไปโหลด Git flow จาก Github ก่อน

สำหรับวิธีการติดตั่งแต่ละ OS ให้เข้าไปดูตามลิ้งนี้

เมื่อติดตั่งเสร็จเราก็จะสามารถพิมพ์ git flow ได้ผ่าน command

 

Start working with Git flow

Git flow จะมีคำสั่งดังนี้

  • init – เริ่มต้นใช้งาน
  • feature – สำหรับจัดการ feature branch
  • release – สำหรับจัดการ release branch
  • hotfix – สำหรับจัดการ hotfix branch
  • support – คล้ายๆ hotfix แตกจาก Master เหมือนกันแต่ผมจะไม่พูดถึงเพราะเราไม่ใช้

เพื่อเปิดการทำงานให้โปรเจคเราใช้คำสั่ง git flow ได้ให้พิมพ์ git flow init มันถามไรก็กด enter ไปครับ เราจะเอาตั่งค่า default

screen-shot-2559-11-10-at-11-18-59-pm

ข้อควรจำ: ในกรณีที่เรามี Master, Develop อยู่แล้วมันจะถามให้ตั่งค่า Master , Develop ใหม่ซึ่งหน้าตาจะต่างออกไปจากด้านบนนิดหน่อย แต่ไม่ต้องไปทำไรมันครับกด enter ไปเลย

 

Work in git flow feature

สำหรับจัดการ Feature Branch ทั่งหมดเราก็ได้มีคำสั่งไว้ในแบบเหมือน shortcut ให้แล้วรีบร้อยตามนี้

  • start <name> – เอาไว้สร้าง branch เหมือน checkout -b
  • finish <name> – เอาไว้สั่ง merge
  • publish <name> – เวลาสร้าง branch ใหม่เอาไว้เป็นคำสั่ง shortcut ของ git push origin

ซึ่งจริงๆ แล้วมันมีคำสั่งอีกแต่ผมเอาแค่ที่จำเป็นต้องใช้มาอธิบายก็พอ สามารถเข้าไปดูคำสั่งทั่งหมดได้ที่ Command Line Arguments

 

Create branch

เวลาสร้าง Branch เราจะใช้ git flow feature start แบบนี้

screen-shot-2559-11-10-at-11-44-31-pm

ผมก็จะได้ feature/test มาทันที ซึ่งมันย่อมาจากคำสั่ง

ซึ่งมันจะต่างจากเมื่อบทความที่แล้วนิดหน่อย แต่ก็ได้ผลเหมือนกัน แต่จำไว้ว่าต้องสลับมาอยู่ develop ก่อนนะครับ

 

Commit branch

พอเราสร้าง Branch ใหม่ขึ้นมาปกติมันจะอยู่ใน local เพราะงั่นต้องสร้าง commit และ push origin ก่อนเสมอ แต่ถ้าเราสั่ง git flow feature publish <name> มันก็จำทำ push origin ให้เลยและตั่งค่าพร้อม

screen-shot-2559-11-11-at-12-04-29-am

จะเห็นว่ามันก็ทำการ push branch ขึ้นไปบน server git เราให้เลยทันที่ซึ่งมันก็เป็น shortcut ของการทำ git push origin นั่นเองแต่มันมีคำสั่งเพิ่มต่อท้ายอีกนิดหน่อยซึ่งผมไม่ขออธิบายละกัน

 

Merge branch

ในการ Merge branch นั่นทำได้ง่ายๆ ครับ เพียงแค่สั่ง git flow feature finish <name>  มันก็จะทำการ merge เข้า develop ให้เลย

screen-shot-2559-11-11-at-12-27-25-am

จะเห็นว่าทำจัดงานให้เรารีบร้อยพร้อมลบ branch ออกให้ด้วย ซึ่งมันย่อมาจากคำสั่ง

 

ข้อควรจำ: สำหรับ release และ hotfix ก็ใช้คำสั่งเหมือนกันเลยครับ แต่ตัว hotfix จะมีแค่ start กับ finish เท่านั่น  เพราะงั่นผมจะไม่อธิบายในการทำ release และ hotfix เพิ่มนะ 

 

Sourcetree

สำหรับใครที่ไม่ถนัดใช้คำสั่งพิมพ์เอาเรามี Sourcetree สามารถทำได้เหมือนกัน โดยเมนูมีตามนี้ อย่าลืม init ก่อนนะ เมนูแรก ถ้า init แล้วก็ใช้งานได้เลย

screen-shot-2559-11-08-at-7-53-21-pm

 

Don’t worry code conflict

จากบทความก่อนๆ มีคนสงสัยเรื่อง code จะ conflict ไหม ผมจะอธิบายให้ฟังตรงนี้เลยคือ conflict แน่นอน แต่ช้าก่อนมันจะ conflict เฉพาะตอนที่ merge เข้า master หรือ develop เท่านั่น เพราะการใช้ git ที่ดีไม่ควร merge กันระหว่าง develop กับ develop หรือ  merge ตอนที่กำลังทำงนอยู่ มันควร conflict กันเมื่อเอา branch มารวมกันนะครับ ตัวอย่างเช่น

  1. John กับ Mary ทำงานอยู่ที่ develop โดยไม่มีการแตกออกไปเป็น Feature ของตัวเอง
  2. John ทำฟีเจอร์ตัวองเสร็จและ commit มา ขณะที่ Mary กำลังทำงานอยู่
  3. Mary เห็นว่า develop มี commit มาใหม่ ก็ pull code มา ถ้าโชคดีก็ไม่ conflict โชคร้ายก็ conflict ไป

จากกรณีข้างบอกอะไรได้บ้างคือ

  1. ทำให้เราเสียเวลาในการแก้ error คนอื่นหรือ config ที่คนอื่นจะมาชนกับเรา เพราะระบบมักมีไฟล์ global config เดียว
  2. ในกรณีที่แต่ละ feature อาจจะมี config ต่างกันไปหรือมี lib ต่างกัน ถ้าเราทำใน develop รวมกันแปลว่า Mary อาจจะต้องนั่งติด lib ก่อนที่จะทำงานต่อได้ หรือเจอ error เพรา config เปลี่ยน เช่น John ใช้ database จาก เครื่องตัวเอง ขณะที่ Mary ใช้ database จาก server กลางแต่ใช้ไฟล์  config เดียวกัน ทำให้ Mary ต้องแก้ไฟล์ใหม่

ข้อดีของการแยกแบบนี้คือ

  1. เมื่อ feature แต่ละอันทำงานได้เราก็เอาไปรวมใน develop แล้วก็ แตก devlop มาทำ feature ใหม่ แล้วไปตั่งค่าของใครของมันไม่มีขึ้นตรงกับใคร
  2. เราสามารถส่งเทสให้ Tester ทีละฟรีเจอร์ ได้
  3. เมื่อเรา commit โค้ดที่ bug ขึ้นมาก็ไม่กระทบคนอื่นๆ เพราะเราไมได้ทำใน develop แต่มัน branch ของแต่ละคน
  4. ไม่เสียเวลาแก้ error ของคนอื่นๆ ใน branch เดียวกัน
  5. แยกงานได้อย่างชัดเจน สามารถจัดการวงจรการพัฒนาระบบได้อย่างดี
  6. สามารถติดต่อการทำงานได้ โดยดูจาก branch ต่างๆ ของแต่ละคน

Summery

การทำ Git flow มันมีข้อดีคือถ้าเราจัดการโปรเจคแบบ agile , scrum จะทำให้เราจัดการระบบและฟีเจอร์หรือทำงานได้เป็นระบบมากขึ้นเลยครับ เราสามารถแท็กการทำงานของแต่ละคนก็ได้ในกรณีที่เรามีเป็นผู้ดูเลยโปรเจค แถมยังเหมาะกับบริษัทที่มีการทำ review code ด้วยเพราะงั่นผมแนะนำให้ Project manager, PO หรือใครก็ตามหันมาใช้แบบนี้ดูครับมันช่วยงานได้เยอะเลยทีเดียว

Facebook Comments