Git Branching — แตกกิ่งก้านสาขาให้เป็นระบบ

ก่อนหน้านี้เราได้พูดถึงพื้นฐานของ Git ว่ามันคืออะไร ทำไมต้องใช้ แล้วมี commit กับ repository ยังไงบ้าง พอเราใช้ Git เป็นแล้ว คำถามต่อมาคือ ถ้ามีหลายคนทำงานบนโปรเจกต์เดียวกัน หรือเราอยากลองทำฟีเจอร์ใหม่โดยไม่พัง code หลัก จะทำยังไงดี?

คำตอบคือ Branching — หรือการ "แตกกิ่ง" ออกจากสายหลักของ code เพื่อทำงานแยก แล้วค่อย merge กลับมาทีหลัง

Branch คืออะไร?

Branch ใน Git ก็คือ ตัวชี้ (pointer) ไปยัง commit ตัวหนึ่ง เวลาเราสร้าง branch ใหม่ Git ไม่ได้ copy ไฟล์ทั้งหมด แค่สร้าง pointer ตัวใหม่ขึ้นมาชี้ไปที่ commit เดิม ทำให้การสร้าง branch เร็วมากและแทบไม่เปลืองพื้นที่เลย

จากตัวอย่าง:

• main เป็น branch หลัก มี commit A, B, C
• feature แตกออกจาก C แล้วมี commit D, E ต่อไปเอง
• ทั้งสอง branch ไม่กระทบกัน จนกว่าจะ merge

ทำไมต้อง Branch?

1. ทำงานพร้อมกันได้

สมมติทีมมี 3 คน:

• คนที่ 1 ทำ Login page
• คนที่ 2 ทำ Dashboard
• คนที่ 3 แก้ Bug ด่วน

ถ้าทุกคนทำบน branch เดียวกัน จะวุ่นวายมาก code ชนกัน commit ทับกัน ทำให้เสียเวลาแก้ conflict แต่ถ้าแต่ละคน แตก branch ของตัวเอง ก็ทำงานได้อิสระ เสร็จแล้วค่อย merge กลับ

2. ลองของใหม่ได้โดยไม่เสี่ยง

อยากลอง refactor ครั้งใหญ่? แตก branch ทดลองเลย ถ้าพัง ก็แค่ลบ branch ทิ้ง main ไม่โดนผลกระทบเลย

3. Review code ก่อน merge

ในทีมที่ทำงานจริง เราจะไม่ merge เข้า main ตรงๆ แต่จะเปิด Pull Request (PR) เพื่อให้คนอื่นมา review code ก่อน ซึ่งต้องใช้ branch ในการทำ

คำสั่งพื้นฐาน

Git branch commands ง่ายมาก — สร้าง, สลับ, ดู, ลบ แค่ 4 อย่าง เพราะ branch ใน Git เป็นแค่ pointer (ไม่ copy ไฟล์) ทุกอย่างจึงเร็วมาก ไม่ว่าโปรเจกต์จะใหญ่แค่ไหน:

สร้าง Branch ใหม่

git branch feature-login

คำสั่งนี้สร้าง branch ชื่อ feature-login แต่เรายังอยู่บน branch เดิมอยู่

สลับไป Branch อื่น

สลับ branch ทำให้ working directory เปลี่ยนเป็นไฟล์ของ branch นั้นทันที — เหมือนเปิดโฟลเดอร์คนละชุด แต่จริงๆ Git สลับไฟล์ให้เร็วมาก:

git checkout feature-login

# หรือแบบสั้นกว่า (สร้าง + สลับในคำสั่งเดียว)
git checkout -b feature-login

ใน Git เวอร์ชันใหม่ (2.23+) สามารถใช้ git switch แทนได้:

git switch feature-login
git switch -c feature-login  # สร้าง + สลับ

ดู Branch ทั้งหมด

ดูว่าตอนนี้มี branch อะไรบ้าง เครื่องหมาย * บอกว่ากำลังอยู่ branch ไหน เพิ่ม -a เพื่อดู remote branches ด้วย:

git branch       # ดูเฉพาะ local
git branch -a    # ดูทั้ง local + remote

ลบ Branch

Branch ที่ merge แล้วควรลบทิ้ง — ไม่งั้น branch list จะยาวเป็นหางม้า ใช้ -d (safe delete — ต้อง merge แล้ว) หรือ -D (force delete — ยังไม่ merge ก็ลบ):

git branch -d feature-login   # ลบ (ถ้า merge แล้ว)
git branch -D feature-login   # ลบบังคับ (ยังไม่ merge ก็ลบ)

Merge — รวม Branch กลับ

เมื่อทำงานบน feature branch เสร็จแล้ว ต้องรวม code กลับเข้า main — นี่คือ merge Git มี 2 วิธี merge: Fast-Forward (เลื่อน pointer ไปข้างหน้า — ง่ายสุด) และ Three-Way Merge (สร้าง merge commit ใหม่ — เมื่อทั้งสอง branch มี commits ต่างกัน):

git checkout main
git merge feature-login

Fast-Forward Merge

ถ้า main ไม่มี commit ใหม่ตั้งแต่แตก branch Git จะแค่ เลื่อน pointer ไปข้างหน้า เรียกว่า fast-forward:

Three-Way Merge

ถ้า main มี commit ใหม่เพิ่มมาด้วย Git จะสร้าง merge commit ขึ้นมาเชื่อมสอง branch:

โดย M คือ merge commit ที่รวมทั้งสอง branch เข้าด้วยกัน

Merge Conflict — เมื่อ code ชนกัน

Conflict เป็นเรื่องปกติ ไม่ต้องกลัว! เกิดเมื่อทั้งสอง branch แก้ไข ไฟล์เดียวกัน บรรทัดเดียวกัน — Git ไม่รู้ว่าจะเอาเวอร์ชันไหน จึงบอกให้เรา "เลือกเอง" วิธีหลีกเลี่ยง: merge บ่อยๆ อย่าปล่อยให้ branch ห่างจาก main นานเกินไป แต่ถ้าเจอก็แก้ได้ง่าย:

<<<<<<< HEAD
console.log("version from main");
=======
console.log("version from feature");
>>>>>>> feature-login

วิธีแก้:

1. เปิดไฟล์ที่ conflict
2. เลือกว่าจะเอา code ส่วนไหน (หรือรวมทั้งสอง)
3. ลบ <<<<<<<, =======, >>>>>>> ออก
4. git add แล้ว git commit

Branching Strategy ยอดนิยม

Branching strategy คือ "กฎ" ของทีมว่าจะใช้ branch ยังไง — ไม่มีสูตรตายตัว เลือกตามขนาดทีม, release frequency, และ risk tolerance ส่วนใหญ่ใช้ 1 ใน 3 แบบนี้:

1. Git Flow

เป็นรูปแบบที่เป็นระบบมากที่สุด มี branch หลายประเภท (main, develop, feature, release, hotfix) เหมาะกับโปรเจกต์ที่มี release cycle ชัดเจน เช่น mobile apps ที่ต้อง submit app store — แต่ซับซ้อนเกินไปสำหรับทีมเล็กหรือ web apps ที่ deploy ทุกวัน:

2. GitHub Flow

เรียบง่ายกว่า Git Flow มาก — มีแค่ main + feature branches ทำงานเสร็จ → เปิด PR → review → merge → deploy อัตโนมัติ เหมาะกับทีมที่ deploy บ่อยๆ ผ่าน CI/CD — เป็น strategy ที่ทีมส่วนใหญ่ควรเริ่มต้นใช้:

1. แตก branch จาก main
2. ทำงาน + commit
3. เปิด Pull Request
4. Review + approve
5. Merge เข้า main
6. Deploy

3. Trunk-Based Development

เรียบง่ายสุดๆ ทุกคน commit เข้า main ตรงๆ แต่ใช้ feature flags เปิด/ปิดฟีเจอร์แทน เหมาะกับทีมที่มีประสบการณ์สูง + มี CI/CD ที่แข็งแกร่ง

เปรียบเทียบ Branching Strategy

สรุปข้อดีข้อเสียของแต่ละ strategy — เลือกตามทีม ไม่มีถูกผิด ทีมเล็ก deploy บ่อยเลือก GitHub Flow ทีมใหญ่มี release cycle เลือก Git Flow ทีมเก่งมี CI/CD แข็งเลือก Trunk-Based:

คำสั่งที่ใช้บ่อย — สรุป

รวม Git branch commands ที่ใช้บ่อยที่สุด — จำไม่ได้ก็ไม่เป็นไร แค่รู้ว่ามีอะไรบ้าง พิมพ์ git branch --help เมื่อต้องการ หรือใช้ GUI tools อย่าง VS Code, GitKraken, SourceTree ก็สะดวกดี:

# สร้าง + สลับ branch
git switch -c feature-name

# push branch ไป remote
git push -u origin feature-name

# ดึง branch จาก remote
git fetch origin
git switch feature-name

# merge กลับ main
git switch main
git merge feature-name

# ลบ branch (local + remote)
git branch -d feature-name
git push origin --delete feature-name

# ดู branch graph สวยๆ
git log --oneline --graph --all

สรุป

Git Branching เป็นทักษะพื้นฐานที่ developer ทุกคนต้องเชี่ยวชาญ — ไม่ว่าจะทำงานคนเดียวหรือทีม 100 คน branch ทำให้ทำงานพร้อมกันได้โดยไม่ชนกัน, ลองของใหม่ได้โดยไม่เสี่ยง, และ review code ก่อน merge ได้ เลือก branching strategy ที่เหมาะกับทีม แล้ว CI/CD pipeline จะทำที่เหลือให้:

• Branch = pointer ไปยัง commit → สร้างเร็ว ไม่เปลืองพื้นที่
• ใช้ branch เพื่อ ทำงานพร้อมกัน ทดลองของใหม่ และ review code
• Merge คือการรวม branch กลับ → อาจเจอ conflict ถ้าแก้ไฟล์เดียวกัน
• เลือก branching strategy ตามขนาดทีมและ deployment cycle
• merge บ่อยๆ = conflict น้อย → ชีวิตดี

ในโพสต์หน้าเราจะมาพูดถึง Rebase — อีกวิธีในการรวม branch ที่ทำให้ประวัติ commit สะอาดขึ้น แต่มีข้อควรระวังที่สำคัญมาก! 🐕