Pull Request workflow

ก่อนหน้านี้คุณเรียน Git ล้วนๆ มาเยอะแล้ว ถึงเวลามาดู feature ของ GitHub (หรือ GitLab/Bitbucket) ที่ทำให้ การทำงานเป็นทีมกลายเป็นเรื่องง่าย นั่นคือ Pull Request (บางที่เรียก Merge Request)

Pull Request คืออะไร

PR คือ “คำขอ” ที่คุณบอกทีมว่า “ผมทำงานบน branch นี้เสร็จแล้ว ขอให้รีวิวแล้ว merge เข้า main ให้หน่อย” มันไม่ใช่การ merge จริง แต่เป็น discussion space ที่ทีมคุยกันก่อน merge

PR ทำให้ทีมได้:

• อ่าน diff ของ code ที่จะเข้าทั้งหมดในที่เดียว
• คอมเมนต์ชี้จุดที่ต้องแก้
• ให้ CI (automated test) run ก่อน merge
• approve/request changes เพื่อยืนยันว่าผ่าน
• keep history ว่า feature นี้เกิดขึ้นจาก PR ไหน คุยอะไรกันบ้าง

Lifecycle ของ PR

ลองคลิกผ่านแต่ละขั้นตั้งแต่เริ่มทำงานจนกระทั่ง merge ด้านล่างคือ mockup flow จริงที่จะเจอเวลาทำงานจริง

$ git checkout -b feature/new-login
$ git commit -m "add login form"
$ git commit -m "add OTP verify"
$ git push -u origin feature/new-login

Best practices สำหรับ PR ที่ดี

• PR เล็ก review ง่าย 200-400 บรรทัด diff reviewer อ่านได้ละเอียด PR 3000 บรรทัดจะถูก approve ทั้งๆ ที่ reviewer เปิดอ่านไม่หมด
• Title ชัด ใช้ prefix ตามมาตรฐาน conventional commit(ข้อตกลงการเขียน commit message) เช่น feat: = feature ใหม่, fix: = แก้ bug, docs: = แก้ documentation, chore: = งานจิปาถะ
• Description บอก why ไม่ใช่แค่ what diff บอก what อยู่แล้ว เขียนว่าทำเพื่ออะไร มี trade-off อะไร ที่ reviewer ควรระวัง
• Screenshot ถ้าเปลี่ยน UI reviewer จะได้ดูได้โดยไม่ต้อง checkout + run
• ตอบ comment ทุกอัน แม้ว่าจะ agree ก็ reply “fixed in abc123” reviewer จะรู้ว่าคุณได้แก้แล้ว

CI คืออะไร ทำไมต้องรอสีเขียว

CI (Continuous Integration) คือระบบที่รัน test / build / type-check / lint อัตโนมัติทุกครั้งที่ push commit ขึ้น GitHub จะแสดงผลของ CI ใน PR เป็น 2 สีหลัก:

• สีเขียว = ทุกอย่างผ่าน merge ได้ปลอดภัย
• สีแดง = มีอะไรพัง (test fail / type error / lint error) ห้าม merge จนกว่าจะแก้ให้เขียว

CI เป็นด่านป้องกันไม่ให้โค้ดเสียเข้า main ต่อให้ reviewer อ่านไม่ครบก็ยังมี CI คอย catch ตัวอย่าง CI ที่ใช้กัน: GitHub Actions, CircleCI, GitLab CI config ส่วนใหญ่เป็น YAML ใน repo (เช่น .github/workflows/ci.yml)

3 วิธี merge PR บน GitHub

ตอนกดปุ่ม “Merge pull request” GitHub จะให้เลือก 1 ใน 3 option แต่ละแบบมีผลต่อประวัติของ main ต่างกัน

• Create a merge commit (default): ทำ 3-way merge สร้าง merge commit ใหม่ ประวัติเห็นว่าเคยมี branch ดีสำหรับทีมที่อยากเก็บร่องรอยทุก PR ข้อเสีย main graph รกถ้า PR เยอะ
• Squash and merge: รวม commit ทุกก้อนของ PR ให้เหลือ 1 commit เดียว บน main ประวัติ main สะอาดมาก (1 PR = 1 commit) ข้อเสีย: รายละเอียด commit ย่อยใน PR หายไป
• Rebase and merge: rebase commit ของ PR ขึ้นบน main tip แล้ว fast-forward ได้ประวัติเส้นตรง เห็น commit แยกครบ ไม่มี merge commit ข้อเสีย: hash เปลี่ยนทุกก้อนถ้ามีคน reference

ภาษาที่ใช้ใน PR review

เวลาเจอ comment ใน review มีคำศัพท์ที่ทีมใช้กันบ่อยๆ

• LGTM = Looks Good To Me = approve
• nit = nitpick = comment เล็กน้อย ไม่ block merge
• blocker = ต้องแก้ก่อน merge
• OOS = Out Of Scope = ไม่เกี่ยวกับ PR นี้ ค่อยแยกอีก PR
• WIP = Work In Progress = ยังไม่พร้อม

สรุป

• PR = คำขอให้ merge + discussion space ของทีม ไม่ใช่การ merge จริง
• Workflow 6 ขั้น: push branch → เปิด PR → review → iterate → approve + CI → merge
• PR เล็ก title ชัด description มี why → review ง่าย
• LGTM, nit, blocker คือคำที่ต้องรู้

lesson ถัดไปจะเป็นของเด็ดคือ reset กับ reflog “git ไม่ลืม” เครื่องมือช่วยกู้คืนงานที่คิดว่าหายไปแล้ว