10ทำงานเป็นทีม

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

10.1 Pull Request — ประตูตรวจงานก่อนรวม

แทนที่จะ push เข้า main ตรง ๆ ทุกคนทำงานบน branch ของตัวเองแล้วเปิด Pull Request (PR) — คำขอให้ทีมรีวิวก่อนรวม PR ทำให้เกิดสามอย่างที่ดีต่อทีม: มีคนตรวจโค้ดก่อนเข้า main, มีที่ถกเถียงเป็นลายลักษณ์อักษร, และรัน CI (ทดสอบอัตโนมัติ) ก่อน merge ได้ — main จึงสะอาดและพร้อมใช้เสมอ

10.2 แก้ merge conflict อย่างเข้าใจ

Conflict เกิดเมื่อสองสายแก้ไฟล์เดียวกัน ตำแหน่งเดียวกัน Git เปิดเครื่องหมายไว้ให้คุณเลือก:

<<<<<<< HEAD
ราคา = total * 1.07          # ฝั่งเรา (branch ปัจจุบัน)
=======
ราคา = total * 1.10          # ฝั่งที่กำลังรวมเข้ามา
>>>>>>> feature-vat

หน้าที่คุณคือตัดสินใจว่าเก็บอันไหน (หรือผสมเป็นอันใหม่) ลบสามบรรทัดเครื่องหมายออกให้หมด แล้ว git add ไฟล์นั้นเพื่อบอกว่าแก้เสร็จ จากนั้น commit — conflict ไม่ใช่ความผิดพลาด แต่เป็น Git ฉลาดพอที่จะไม่เดาแทนคุณ วิธีแก้ไฟล์เหมือนกันทุกประการไม่ว่าจะชนตอน merge หรือตอน rebase ต่างแค่ตอน rebase อาจเจอซ้ำได้หลายรอบทีละ commit (รายละเอียดบทที่ 8.3)

10.3 สองปรัชญาการจัดการ branch

กระแสปัจจุบันเอนไปทาง trunk-based เพราะ branch ที่อยู่สั้นแปลว่า conflict น้อยและรวมงานง่าย — หลักการลึก ๆ คือ ยิ่งรวมงานบ่อย ยิ่งเจ็บน้อย แนวโน้มนี้เชื่อมกับการเลือก merge/rebase ด้วย (บทที่ 8) — trunk-based มักคู่กับ rebase, Git Flow มักคู่กับ merge

10.4 ข้อความ commit ที่ทีมอ่านรู้เรื่อง

หลายทีมใช้ Conventional Commits ขึ้นต้นด้วยชนิดงาน เช่น feat: (ฟีเจอร์ใหม่), fix: (แก้บั๊ก), docs:, refactor: — รูปแบบสม่ำเสมอนี้ทำให้สแกนประวัติได้เร็วและสร้าง changelog อัตโนมัติได้

✅ สรุปบทที่ 10 — PR = ประตูรีวิว+ทดสอบก่อนเข้า main ทำให้ branch หลักสะอาดเสมอ · conflict คือ Git ขอให้คุณตัดสินใจ — เลือก ลบเครื่องหมาย add แล้ว commit · Git Flow เหมาะงานปล่อยเป็นรอบ, trunk-based เหมาะ deploy บ่อย · รวมงานบ่อยเจ็บน้อย · Conventional Commits ทำให้ประวัติอ่านง่าย