มาทำความรู้จักกันกับ Git workflows กัน
จากการที่ผมได้มีโอกาสพูดคุยกับหลายคนในสายอาชีพโปรแกรมเมอร์สิ่งนึงที่ไม่ค่อยเป็นประเด็นที่น่าสนใจแต่มักต้องจำเป็นในการใช้งานทั่วไปนั้น นั่นก็คือการใช้งาน version control ในการจัดการตัว Source code ของเราเอง หลายคนตอบไม่ได้ว่าตัวเองกำลังใช้ workflow แบบไหนอยู่กันแน่ หลายคนก็ใช้แต่ยังไม่เข้าใจว่าทำไมต้องทำแบบนี้ หรือ อีกหลายคนก็ไม่รู้ว่าแบบไหนจะเหมาะกับทีมของเราเอง
โดยวันนี้ผมจะมาเล่าเรื่องของ git workflow ทั้ง 4 แบบที่ควรต้องทราบ กันว่าแต่ละแบบมันหน้าตาเป็นยังไงกันบ้าง มีข้อดีข้อเสียและแนวทางการใช้งานในรูปแบบใดบ้าง ซึ่งก็พอดีที่ผมได้มีโอกาสไปเจอบทความที่น่าสนใจเกี่ยวกับเรื่องนี้เข้า จึงจะลองเอามาสรุปให้ทุกคนได้ฟังกันครับ สำหรับผู้ที่สนใจอยากอ่านจากต้นฉบับก็สามารถศึกษาเพิ่มเติมได้จากลิงค์ด้านล่างได้เลยครับ
- Simple branch— แบบนี้มีความง่ายและเข้าใจได้อย่างชัดเจนที่สุด นั่นก็คือเราจะทำงานกันบน branch master เท่านั้น โดยทุกการ commit ของการเปลี่ยนแปลงจะต้องอยู่บน branch นี้ด้วยกัน ไม่มีการแยก branch ออกไป มันจะเหมาะกับการทำ Project ขนาดเล็ก มีทีมจำนวนไม่มาก หรือ จะไว้ทำส่วนตัวก็ได้ ส่วนตัวแล้วสำหรับผมมักจะใช้รูปแบบนี้ในช่วงแรกของการเริ่มทีมที่มีขนาดเล็ก เนื่องจากมันทำให้ Code ที่กองอยู่ตรงนี้สดใหม่ตลอดเวลา อีกทั้งยังทำให้ฟีเจอร์ที่แต่ละคนทำมีขนาดไม่ใหญ่มากด้วย (เห็นชัดเจนว่าทุก commit มาจากฟีเจอร์ไหน ใครแก้เรื่องใดบ้าง) ซึ่งมันส่งผลทำให้ขนาดของฟีเจอร์เราถูกซอยให้เล็กลงไปในตัวด้วย เนื่องจากถ้าเรามีฟีเจอร์ใหญ่มาก มันก็จะทำให้เราห่างกันกับ Master ไปมากเช่นกัน ผลที่ตามมาก็จะเกิดมหกรรม Merge conflict ที่หลายคนน้ำตาไหลรินกัน
2. Feature branch — นั่นคือการมองว่าในขั้นตอนก่อนการลงมือแก้ไขเราจะต้องทำการแตกสายของ branch ออกมาจาก Master branch เป็นฟีเจอร์ที่เรากำลังพัฒนาอยู่ ซึ่งก็คือการแก้ไขปัญหาจาก Simple branch ในแบบแรกนั่นคือ Master ของเราจะไม่ขยับไปเร็ว และ ช่วยลดปัญหาจากการ Merge conflict ได้บ้าง โดยฟีเจอร์ที่พัฒนาจะต้องเสร็จก่อนถึงจะสามารถ merge กับมาที่ Master branch ได้ ซึ่ง Feature branch นี้จะหายไปทันทีถ้าเราพัฒนาเสร็จแล้ว (Short-lived) สำหรับวิธีนี้ก็ต้องระวังเช่นกันในการที่ Feature branch มีอายุยาวเกินไป ทำให้ห่างจาก master branch ไปเรื่อย ๆ ทางแก้ก็คือการทยอย merge master เข้ามาเรื่อยใน branch ของตัวเอง กับ อีกทางคือการซอยให้ฟีเจอร์ที่แต่ละคนทำให้มีขนาดเล็กลง ก็จะช่วยลดปัญหาเหล่านี้ได้เช่นกัน
3. Develop branch — จะเกิดอะไรขึ้นถ้าผู้ใช้งานอยากทดลองใช้งานโปรแกรมที่ทีมเรากำลังพัฒนาอยู่ ถ้าเราให้ผู้ใช้มาทดสอบบน Master branch โดยใช้ 2 รูปแบบตามที่กล่าวมาข้างต้นปัญหาก็จะเกิดแล้วครับ นั่นคือมันจะมีฟีเจอร์ หรือ การแก้ไขบั๊กต่าง ๆ ตลอดเวลา ซึ่งอาจจะส่งผลกับการใช้งานของผู้ใช้ ทำให้เกิดการผิดพลาดได้หลายอย่าง ดังนั้นรูปแบบที่จะเล่าต่อไปนี้คือการพยายามสร้าง long-lived branch รองลงมาจาก Master branch เพื่อใช้ในการพัฒนาเท่านั้นแยกออกไปเลย ถ้าถามว่าเมื่อไรควรใช้ก็นึกภาพว่าเมื่อเราต้องการปล่อยให้ผู้ใช้ทดสอบโปรแกรม โดยไม่อยากให้การพัฒนาของเราไปกระทบการใช้งานนั่นเอง
4. Release branch — จากวิธีที่ 3 เราจะสามารถแบ่ง Source code ออกมาได้ถึง 2 ลักษณะของการใช้งานนั่นก็คือ Master branch ใช้สำหรับให้ผู้ใช้งานเข้าใช้งานจริง ส่วนสายของ Develop branch คือสายของทีมพัฒนาที่อาจจะไว้ใช้เข้าไปลองทดสอบการ intregrate code กันว่าเกิดปัญหาอะไรไหม เพื่อไม่ให้กระทบกันกับผู้ใช้งานจริง แต่เวลาการปล่อยฟีเจอร์ออกมาโดยปกติแล้วเค้าจะไม่ทำการปล่อยออกมาหลังจากการพัฒนาเสร็จเรียบร้อยเลย แต่จะมีการทดสอบก่อนว่าฟีเจอร์ในช่วงนั้น ๆ สามารถใช้งานได้ตามที่คาดหวังไว้หรือไม่ อีกทั้งยังมีผลในเชิงของทางฝั่ง Business อีกด้วยที่การปล่อยฟีเจอร์ใหม่ออกไปบางครั้งต้องผ่านการโปรโมทรวมทั้งมีการวางกำหนดการที่ชัดเจน ดังนั้นจึงเกิดแนวคิดในการทำ branch เพิ่มมาอีก 1 เส้นนั่นก็คือ Release branch ที่จะทำหน้าที่ในการพักเอา feature ที่เสร็จแล้วมาทดสอบก่อน จากนั้นค่อย merge กลับเข้าไปยัง Master เมื่อเป็นตามที่ทดสอบได้ ซึ่งแนวคิดนี้จะคล้ายกันกับตัว Feature branch เพียงแต่มองในมุมของการรวบเอาหลาย ๆ ฟีเจอร์เข้าไว้ด้วยกันรวมกันเป็นรอบของการ Release นั่นเอง
สำหรับการวางแผนในการทำ Release strategy ให้ลองศึกษาดูเพิ่มเติมได้จากลิงค์ด้านล่างนี้ครับ
จาก 4 ข้อด้านบนนี้เป็น Git workflow ที่เรามักจะเจอกันทั่วไปเวลาเริ่มทำโปรเจกต์อย่างแน่นอนครับ แต่ก็มีหลายคนที่เริ่มต้นด้วยการใช้ Git-flow ซึ่งบางทีอาจจะลืมไปว่าที่มาที่ไปของการแตก branch หรือ การออกแบบการใช้งานแบบนี้มีไว้เพื่ออะไรกันแน่ การศึกษาแนวคิดพื้นฐานและเข้าใจมันอย่างดีก็จะช่วยให้บางครั้งเราก็ไม่จำเป็นต้องทำตามเค้าตลอดไปทั้งหมด แต่เลือกท่าที่มันเหมาะกับโจทย์ที่เราเจอ
อย่างช่วงแรกทีมที่ผมทำงานมักเริ่มด้วยการทำ Simple branch ทุกคนอยู่บน Master branch ด้วยกัน ซึ่งมันก็ดีมากกับโปรเจกต์ที่เพิ่งเริ่มกันใหม่, ทีมที่ยังเพิ่งฟอร์มกันใหม่ หรือ มีสมาชิกหลายคนในทีมที่ยังไม่มีประสบการณ์ในการใช้งาน version control มาก่อน เพราะ มันเข้าใจง่าย แต่เมื่อเจอปัญหาต่าง ๆ ผมก็ค่อย ๆ อธิบายที่มาที่ไปให้กับทีม นำแนวคิดเหล่านี้มาเสริมเพื่อให้ทีมสามารถเข้าใจที่มาที่ไปว่าทำไมต้องใช้ และ ทำแบบนี้ ผมเคยเจอน่ะครับกับการที่ทีมไม่เข้าใจเลยว่าภาพรวมของ workflow ที่ตัวเองทำอยู่หน้าตาแบบไหน ทีมเข้าใจเพียงแค่ว่าก่อน deploy ขึ้นต้องแตกออกมาเป็น release branch ก่อน เพียงเพราะทำตามที่เค้าสั่งให้ทำ…
