สอนใช้ Git ตอนที่ 3: Workflows for Teams & Projects

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

พอ Maya กับทีมเริ่มใช้ branch และ pull request ได้คล่อง ปัญหารอบใหม่ก็เริ่มชัดขึ้นอีกแบบ คราวนี้ไม่ใช่แค่เรื่อง “จะ merge อย่างไร” แต่เป็น “ทีมควรมีวิธีทำงานร่วมกันแบบไหนถึงจะไม่วุ่น”

ตอนมีคน 2 คน ทุกอย่างดูง่าย แต่พอทีมโตเป็น 5 คน มีทั้งงาน feature, งานแก้บั๊ก, งานเอกสาร, งาน release และบางอย่างต้องออกตามกำหนด ทีมจะเริ่มรู้สึกทันทีว่าถ้าไม่มีข้อตกลงร่วมกัน เส้นทางของ branch จะเริ่มมั่ว และ main จะเริ่มกลายเป็นพื้นที่ที่ทุกคนกลัว

นี่คือเหตุผลที่ Git workflow สำคัญ

Workflow สำคัญเพราะมันคือข้อตกลงของทีม

คำว่า workflow ในโลก Git ไม่ได้หมายถึงเครื่องมือใหม่ แต่มันหมายถึง “วิธีที่ทีมตกลงร่วมกันว่าจะใช้ branch, review, merge และ release อย่างไร”

พูดง่าย ๆ Git ให้เครื่องมือ แต่ workflow คือกติกาในการใช้เครื่องมือนั้นร่วมกัน

ถ้าไม่มีกติกาเดียวกัน ปัญหาจะตามมาแบบคุ้นเคยมาก:

• บางคน merge ตรงเข้า main
• บางคนเปิด branch ยาวหลายสัปดาห์
• บางคนตั้งชื่อ branch ไม่รู้เรื่อง
• เวลาจะ release ไม่มีใครแน่ใจว่าควรตัดจากตรงไหน

workflow ที่ดีจึงไม่ได้มีไว้เพิ่มขั้นตอน แต่มีไว้ลดความสับสน

จุดที่สำคัญมากคือ workflow ที่ดีควรทำให้ทีมตอบคำถามพื้นฐานได้เร็ว เช่น “งานนี้ควรแตกจาก branch ไหน”, “merge กลับเมื่อไร”, “อะไรถือว่า release-ready” และ “ถ้ามี hotfix ต้องไปทางไหน” ถ้าตอบคำถามพวกนี้ไม่ได้สม่ำเสมอ แปลว่าทีมอาจยังไม่มีกติกาที่ชัดพอ

การมี workflow จึงไม่ได้แปลว่าทุกคนต้องคิดเหมือนกันทุกเรื่อง แต่มันแปลว่าทุกคนมีแผนที่ร่วมกัน เวลามีงานเร่ง งานหลุด หรือ release ใกล้ deadline ทีมจะไม่ต้องมานั่งเดากติกาใหม่ทุกครั้ง

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

Git Flow: เหมาะกับงานที่มี release เป็นรอบ

Git Flow คือ workflow ที่มีโครงสร้างค่อนข้างชัด โดยมักมี branch หลักอย่าง:

• main
• develop
• feature/...
• release/...
• hotfix/...

แนวคิดของมันคือ:

• main เก็บสิ่งที่พร้อม release แล้ว
• develop เป็นเส้นรวมงานที่กำลังจะไป release รอบถัดไป
• feature/... ใช้ทำงานย่อย
• release/... ใช้เตรียม release
• hotfix/... ใช้แก้ปัญหาเร่งด่วนจากของที่ออกไปแล้ว

ข้อดีคือโครงสร้างชัดและคุม release ได้ดี โดยเฉพาะถ้าคุณมีรอบปล่อยงานเป็นช่วง เช่น ทุกสองสัปดาห์หรือทุกเดือน

ข้อเสียคือมันมีพิธีการเยอะกว่าทีมเล็ก ๆ ที่เปลี่ยนเร็ว เพราะยิ่ง branch เยอะ การประสานกันยิ่งต้องมีวินัยมาก

ผมมองว่า Git Flow ไม่ได้ผิดหรือเก่าไปเอง แต่จะดีหรือไม่ดีขึ้นกับบริบท ถ้าคุณมีผลิตภัณฑ์ที่ต้องออกเป็น version, มี QA ชัด, มีรอบ cut release จริง มันยังมีเหตุผลของมันอยู่ แต่ถ้าทีมคุณยังปล่อยของแบบต่อเนื่องและคนไม่มาก โครงสร้างนี้อาจให้ต้นทุนทางพิธีการเยอะเกินผลประโยชน์

อีกเรื่องที่ควรคิดคือใครเป็นคนดูแล branch พิเศษอย่าง release หรือ hotfix ถ้าทีมไม่มีความรับผิดชอบที่ชัด branch พวกนี้จะกลายเป็นพื้นที่กลางที่ทุกคนแตะได้แต่ไม่มีใครดูจริง ซึ่งอันตรายกว่าการไม่มีมันเสียอีก

Maya เริ่มมอง Git Flow ตอนทีมมี 5 คน เพราะพวกเขาไม่ได้แก้แค่เว็บแอป แต่ยังดูแล wiki, docs และ internal guide ด้วย การมี develop แยกจาก main ทำให้พอจะหายใจได้ขึ้นเวลา release ใกล้เข้า

แต่สิ่งที่ Maya เรียนรู้เร็วมากคือ Git Flow จะช่วยได้จริงก็ต่อเมื่อทีมยอมรับต้นทุนของมันร่วมกัน ถ้ามี branch เพิ่มขึ้นแต่ไม่มีวินัยเรื่อง review, sync และการดูแล release branch โครงสร้างที่ตั้งใจให้เป็นระเบียบก็อาจกลายเป็นอีกชั้นของความสับสนแทน

GitHub Flow: เรียบง่ายและเร็ว

GitHub Flow ในแก่นของมันเรียบกว่ามาก:

1. ทุกอย่างแยกออกจาก main
2. ทำงานบน feature branch
3. เปิด pull request
4. review
5. merge กลับเข้า main

main ในแนวทางนี้ควรอยู่ในสถานะที่พร้อม deploy ได้เสมอ

ข้อดีคือเรียนรู้ง่าย, ตัด branch น้อย, และเหมาะกับทีมที่ปล่อยของบ่อย

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

ชื่อมันจะมีคำว่า GitHub อยู่ก็จริง แต่จริง ๆ วิธีคิดนี้ใช้ได้กับ Git host แทบทุกเจ้า รวมถึง Gitea ด้วย เพราะสิ่งสำคัญคือ pattern ไม่ใช่ชื่อแพลตฟอร์ม

นี่เป็นเรื่องที่ผมชอบย้ำเสมอ เพราะหลายคนเผลอคิดว่า workflow ผูกกับ vendor ทั้งที่จริงสิ่งที่ผูกอยู่คือพฤติกรรมของทีม ถ้าคุณมี branch, review, merge policy และ remote คุณก็ใช้วิธีคิดเดียวกันได้เกือบหมด

นั่นหมายความว่าถ้าทีมของคุณย้ายจาก GitHub ไป Gitea หรือจาก Gitea ไปแพลตฟอร์มอื่น สิ่งที่ควรย้ายตามไปด้วยจริง ๆ คือข้อตกลงเรื่อง workflow ไม่ใช่แค่ repository อย่างเดียว

ข้อดีของแนวทางที่เรียบง่ายอย่าง GitHub Flow คือมันทำให้ทุกคนรู้ว่าศูนย์กลางอยู่ที่ main งานใหม่แตกออกไป review แล้วกลับเข้ามา ถ้าทีมมี automation พอสมควร วิธีนี้มักรักษาทั้งความเร็วและความชัดเจนได้ดี โดยไม่ต้องมี branch พิเศษจำนวนมาก

Trunk-Based Development: สำหรับทีมที่เคลื่อนเร็วมาก

อีกแนวคิดหนึ่งคือ Trunk-Based Development หรือ TBD ซึ่งเน้นให้ทุกคนรวมงานกลับเข้าหา trunk หลักบ่อยมาก branch ย่อยมีอายุสั้น และทีมพยายามลดการค้างงานไว้บน branch นาน ๆ

แนวทางนี้เหมาะกับทีมที่มี automation ดี, test ครอบคลุมพอ, และมีวินัยสูง เพราะความเร็วของมันมาพร้อมเงื่อนไขว่าคุณต้องมั่นใจได้ว่าการรวมงานบ่อย ๆ จะไม่ทำให้ทุกอย่างพัง

สำหรับทีมเล็กที่ยังไม่มี test, review และ CI ที่ดีพอ ผมมองว่า TBD อาจฟังดูเท่ แต่ใช้งานจริงจะเหนื่อย เพราะคุณกำลังยืมความเรียบง่ายจาก workflow ที่ต้องอาศัยวินัยทางวิศวกรรมสูงมาค้ำไว้

พูดอีกแบบคือ TBD ไม่ได้ยากเพราะคำสั่ง Git ยาก แต่มันยากเพราะคุณต้องมีระบบรอบข้างที่พอจะรองรับการรวมงานถี่ ๆ เช่น test ที่ไว้ใจได้, review ที่ไม่ช้าเกินไป, และทีมที่ไม่เปิด branch ค้างไว้ยาวจน trunk เสียความหมาย

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

แล้วควรเลือกแบบไหน

ถ้าจะสรุปแบบ practical ผมมองประมาณนี้

เลือก Git Flow ถ้า

• คุณมี release เป็นรอบ
• งานมีหลายประเภทและหลายทีม
• ต้องแยกสิ่งที่ “กำลังพัฒนา” ออกจากสิ่งที่ “พร้อมปล่อย” ชัดเจน

เลือก GitHub Flow ถ้า

• ทีมไม่ใหญ่มาก
• ปล่อยของบ่อย
• อยากให้กระบวนการเรียบง่ายที่สุด

เลือก TBD ถ้า

• ทีม deploy บ่อยมาก
• test และ automation พร้อม
• ทุกคนมีวินัยกับ branch อายุสั้นและการ integrate งานถี่ ๆ

ถ้าคุณยังไม่แน่ใจ ผมมักแนะนำให้เริ่มจาก GitHub Flow ก่อน เพราะต้นทุนการอธิบายต่ำ และพอทีมโตขึ้นค่อยขยับไป workflow ที่ซับซ้อนกว่า ถ้าจำเป็นจริง

Git ใช้กับ docs และ content team ก็ต้องมี workflow เหมือนกัน

จุดที่คนมองข้ามคือ workflow ไม่ได้สำคัญเฉพาะ code

ถ้าทีมของ Maya ใช้ Git กับ wiki, product docs และ spec ด้วย กติกาเรื่อง branch และ review ก็ยังสำคัญเหมือนกัน เพราะเอกสารผิดเวอร์ชันก็สร้างความเสียหายได้เหมือนโค้ดผิดเวอร์ชัน

เช่น ถ้ามีคนแก้ onboarding guide ตรงบน main โดยไม่ review ทีม support อาจเอาเอกสารที่ยังไม่พร้อมไปใช้ต่อทันที เพราะฉะนั้น PR และ branch strategy ไม่ใช่เรื่องของ developer อย่างเดียว แต่เป็นเรื่องของทีมที่ทำงานบน shared history ร่วมกัน

จุดนี้สำคัญกับหลายองค์กร เพราะพอเอกสารอยู่ใน Git แล้ว คนมักเผลอคิดว่า “ก็ไม่ใช่ production code” เลยลดมาตรฐานลง แต่ในโลกจริง spec ผิดหนึ่งบรรทัดหรือ runbook เก่าหนึ่งหน้า อาจทำให้ทีมอื่นทำงานผิดทางได้ไม่ต่างจาก code bug เลย

เพราะฉะนั้นถ้าคุณใช้ Git สำหรับ docs ด้วย ให้ตกลงกันให้ชัดว่าเอกสารประเภทไหนต้อง review แบบไหน เอกสารไหน merge ตรงได้ และเอกสารไหนควรผ่าน approval ก่อน publish เพื่อไม่ให้ทุกอย่างใช้มาตรฐานเดียวแบบผิดบริบท

ในหลายทีม การมีกติกาสำหรับ docs ยังช่วยให้คนที่ไม่ใช่ developer กล้าใช้ Git มากขึ้นด้วย เพราะเมื่อขั้นตอนชัด ทุกคนจะรู้ว่าควรเริ่มจาก branch ไหน ต้องขอ review เมื่อไร และอะไรถือว่าเผยแพร่ได้แล้ว ความชัดเจนนี้ช่วยลดความกลัวเครื่องมือได้มาก

Tags และ releases ช่วยอะไร

อีกเรื่องที่ควรรู้เมื่อทีมเริ่มจริงจังคือ tag

git tag ใช้สำหรับปักหมุด commit สำคัญ เช่น release

ตัวอย่าง:

git tag v1.2.0
git push origin v1.2.0

ถ้าทีมใช้ semantic versioning เช่น v1.2.0 ก็จะช่วยให้ประวัติ release อ่านง่ายขึ้นมาก:

• major: เปลี่ยนใหญ่
• minor: เพิ่มความสามารถ
• patch: แก้บั๊ก

tag ไม่ได้ทำให้งานดีขึ้นเอง แต่ช่วยให้ “รู้ว่าปล่อยอะไรไปเมื่อไร” แบบชัดเจน ซึ่งสำคัญมากเวลา troubleshoot หรือ rollback

ถ้าคุณเริ่มจริงจังกับ releases ผมแนะนำให้ตกลงภาษาร่วมกันตั้งแต่ต้นว่าอะไรคือ release, อะไรคือ draft milestone, และใครเป็นคนมีสิทธิ์ tag เพื่อไม่ให้ประวัติเต็มไปด้วยป้ายที่ไม่มีความหมายร่วมกัน

เรื่องนี้ฟังดูเล็ก แต่มีผลมากเวลาเกิด incident เพราะ tag ที่ดีช่วยให้ทีมตอบคำถามอย่าง “ตอนนี้ production อยู่บนอะไร” หรือ “feature นี้เข้า release ไหนแล้ว” ได้ไวขึ้นอย่างเห็นได้ชัด

ความผิดพลาดที่เจอบ่อย: ใช้ workflow ใหญ่เกินทีม

หนึ่งใน pitfall ที่เห็นบ่อยที่สุดคือ ทีม 2 คนเลือก Git Flow แบบเต็มทุก branch ตั้งแต่วันแรก แล้วสุดท้ายเหนื่อยกับพิธีการมากกว่าประโยชน์ที่ได้

ผมมองว่า workflow ที่ดีไม่ใช่อันที่ดู professional ที่สุด แต่คืออันที่เหมาะกับขนาดทีม จังหวะ release และ maturity ของกระบวนการตอนนี้

เริ่มง่ายไว้ก่อนได้ แล้วค่อยเพิ่มโครงสร้างเมื่อปัญหาจริงเรียกร้อง ไม่ใช่เพิ่มทุกอย่างเผื่อไว้ก่อน

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

workflow ที่ไม่มีใครใช้จริงไม่ใช่ workflow มันเป็นเพียงแผนภาพสวย ๆ เพราะฉะนั้นถ้าคุณเป็นคนเริ่มวางกติกาให้ทีม ลองเริ่มจากของที่ทุกคนยอมใช้ได้ก่อน แล้วค่อยยกระดับทีละขั้น จะได้ผลกว่าการประกาศระบบที่ดูครบแต่ไม่มีใครอิน

ถ้าคุณยังไม่แน่ใจว่าจะเริ่มตรงไหน ผมมักแนะนำสูตรง่าย ๆ คือเริ่มจาก branch สั้น, PR เล็ก และ main ที่พยายามให้พร้อมใช้งานเสมอ จากนั้นค่อยเพิ่มกติกาเรื่อง release branch, hotfix branch หรือ tags เมื่อทีมเริ่มมีปัญหาจริงที่แนวทางเดิมรับมือไม่ไหว วิธีคิดแบบนี้ทำให้ workflow โตตามปัญหา ไม่ใช่โตนำหน้าความจำเป็น

สรุปสั้น ๆ ก่อนจบตอนนี้

• Git workflow คือข้อตกลงร่วมกันของทีมในการใช้ branch, review, merge และ release
• Git Flow เหมาะกับงานที่มี release cycle ชัด, GitHub Flow เหมาะกับทีมที่อยากเรียบง่าย, TBD เหมาะกับทีมที่ automation สูง
• อย่าเลือก workflow ที่ซับซ้อนเกินความจำเป็นของทีม

ตอนนี้ Maya กับทีมเริ่มรู้แล้วว่าการใช้ Git ให้เป็นไม่ได้จบที่คำสั่ง แต่ต้องมีวิธีทำงานร่วมกันที่พอดีด้วย

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

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

ถ้าจะเริ่มเลือกจริงวันนี้ ผมยังยืนยันคำแนะนำเดิมว่าเริ่มจากของที่อธิบายง่ายที่สุดก่อน แล้วดูว่าทีมสะดุดตรงไหนบ้าง จากนั้นค่อยเพิ่มโครงสร้างเฉพาะจุดที่จำเป็น วิธีนี้มักได้ผลดีกว่าการพยายามออกแบบ workflow ที่สมบูรณ์แบบตั้งแต่วันแรก

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

และนั่นคือเหตุผลที่ workflow ควรถูกออกแบบให้ทีมใช้ได้จริงทุกวัน

workflow ที่ดีจึงควรชัด สั้น และทำซ้ำได้เสมอในงานจริง

เมื่อทุกคนใช้กติกาเดียวกัน ความสับสนรายวันก็จะลดลงมาก

ในตอนสุดท้าย เราจะขยับไปอีกขั้น จากการใช้ Git host ของคนอื่น ไปสู่การเป็นเจ้าของ pipeline ของตัวเองด้วย Gitea และ self-hosted CI/CD ซึ่งเป็นจุดที่หลายทีมเริ่มเห็นคำถามเรื่องต้นทุน, ความเป็นส่วนตัว และการควบคุมระบบมากขึ้น

อ่านก่อนหน้า: สอนใช้ Git ตอนที่ 2 อ่านต่อ: สอนใช้ Git ตอนที่ 4: Self-Hosted CI/CD with Gitea

แหล่งอ้างอิง

• Git Reference
• git-tag documentation
• GitHub Docs: About pull requests