Pull request คืออะไร: วิธีสร้าง PR บน GitHub ทีละขั้นตอน

Pull request (PR) คือข้อเสนอให้รวมการเปลี่ยนแปลงจากสาขาหนึ่งเข้าสู่อีกสาขาหนึ่ง โดยทำผ่านแพลตฟอร์มอย่าง GitHub คุณส่งสาขาขึ้นเซิร์ฟเวอร์ เปิด PR ทีมจะเห็น diff แสดงความคิดเห็นทีละบรรทัด รันการตรวจสอบอัตโนมัติ แล้วจึงกดปุ่มรวม บน GitLab กลไกเดียวกันนี้เรียกว่า merge request (MR) หากตอบสั้น ๆ ว่า «git pull request คืออะไร» ก็คือจุดควบคุมระหว่าง «ฉันเขียนโค้ดเสร็จแล้ว» กับ «โค้ดเข้าสู่ main แล้ว»

Git pull request คืออะไร และชื่อนี้มาจากไหน

ชื่อนี้เกิดขึ้นตามประวัติ ผู้เขียนการเปลี่ยนแปลงขอให้เจ้าของรีโพ «ดึง» (pull) สาขาของเขาเข้าไป จึงเรียกว่า pull request ส่วน GitLab เลือกตั้งชื่อตามผลลัพธ์ คือ merge request หรือคำขอรวม Bitbucket และ Azure DevOps ใช้คำว่า pull request โดยสรุปแล้วทั้งหมดคือสิ่งเดียวกัน ได้แก่ สาขาต้นทาง สาขาปลายทาง คำอธิบาย การสนทนา การตรวจสอบ และปุ่มรวม

สิ่งสำคัญที่ควรเข้าใจคือ pull request ไม่ใช่ส่วนหนึ่งของ Git ใน Git ไม่มีวัตถุที่เรียกว่า «PR» คุณไม่สามารถสร้างมันด้วยการ commit หรือค้นหามันในโฟลเดอร์ .git ได้ มันเป็นแนวคิดของแพลตฟอร์ม GitHub เก็บคำอธิบาย ความคิดเห็น และสถานะการตรวจสอบไว้เอง ส่วน Git รับผิดชอบเพียงสาขาและ commit ที่อยู่ใน PR เท่านั้น

ในการสนทนาของนักพัฒนา คำว่า PR เกือบทุกครั้งหมายถึง pull request เช่น «ส่ง PR ให้หน่อย» «PR รอรีวิวอยู่» «merge PR นั้นแล้ว» ส่วน GitLab มักพูดว่า MR

Pull request กับ git pull ต่างกันอย่างไร

สองสิ่งนี้มักสับสนกันเพราะชื่อคล้ายกัน คำสั่ง git pull ดาวน์โหลด commit ใหม่จากรีโมตรีโพ และรวมเข้าสู่สาขาปัจจุบันของคุณทันที เป็นการทำงานในเครื่องผ่านเทอร์มินัล ส่วน pull request คือหน้าเว็บบน GitHub ที่เสนอให้รวมสาขาหนึ่งเข้าอีกสาขาหนึ่ง

ไม่มีคำสั่ง «git pull request» แยกต่างหากใน Git มีเครื่องมือเก่าชื่อ git request-pull แต่มันเพียงสร้างข้อความอีเมลที่สรุปการเปลี่ยนแปลงไว้สำหรับส่งต่อ ไม่เกี่ยวข้องกับ PR บน GitHub

ทำไมจึงต้องใช้ pull request

เมื่อโปรเจกต์มีคนทำคนเดียว คุณสามารถ commit ลง main ได้โดยตรง แต่เมื่อรีโพมีสองคนขึ้นไป การ push เข้าสาขาหลักโดยตรงจะก่อให้เกิดบิลด์ที่พังและงานที่หายไป Pull request แก้ปัญหาหลายอย่างพร้อมกัน:

• รีวิวโค้ด: คนที่สองเห็นการเปลี่ยนแปลงก่อนเข้า main และจับข้อผิดพลาดที่ผู้เขียนมองข้ามไป
• การตรวจสอบอัตโนมัติ: GitHub Actions หรือ CI อื่นจะรันการทดสอบและ linter ทุกครั้งที่มี PR และสถานะสีแดงจะป้องกันไม่ให้โค้ดที่มีปัญหาถูกรวม
• ประวัติการตัดสินใจ: อีกหนึ่งปีต่อมา จาก PR คุณจะรู้ไม่เพียงว่ามีการเปลี่ยนอะไร แต่รู้ว่าทำไม พร้อมการสนทนาที่เกิดขึ้น
• การมีส่วนร่วมในโปรเจกต์ของผู้อื่น: ในโอเพนซอร์ส คุณไม่มีสิทธิ์เขียน และ PR จาก fork คือวิธีเดียวที่จะเสนอการแก้ไข
• การป้องกันสาขา: กฎการป้องกันสาขาบน GitHub สามารถห้ามการ push ตรงเข้า main และกำหนดให้ต้องมี PR ที่ได้รับการอนุมัติ

วิธีสร้าง pull request บน GitHub จากสาขา

นี่คือสถานการณ์หลักสำหรับทีมที่สมาชิกทุกคนมีสิทธิ์เขียนในรีโพ งานจะทำในสาขาฟีเจอร์ และ main จะถูกเปลี่ยนแปลงผ่าน PR เท่านั้น

ขั้นตอนที่ 1: สร้างสาขาจาก main ล่าสุด

git switch main
git pull
git switch -c feature/login-form

ควรตั้งชื่อสาขาให้สื่อความหมาย เช่น feature/…, fix/… หรือหมายเลขงาน ผู้รีวิวจะเข้าใจทันทีว่าเกี่ยวกับอะไร

ขั้นตอนที่ 2: ทำ commit

git add src/login.js
git commit -m "เพิ่มฟอร์มเข้าสู่ระบบ"

หนึ่ง PR ควรทำงานเดียว PR ขนาดเล็กประมาณ 100–300 บรรทัดจะถูกรีวิวได้เร็วและละเอียด ส่วน PR ขนาด 3000 บรรทัด ผู้รีวิวมักอนุมัติโดยไม่ได้ดูอย่างจริงจัง

ขั้นตอนที่ 3: ส่งสาขาขึ้นเซิร์ฟเวอร์ (git push สำหรับ pull request)

git push -u origin feature/login-form

แฟล็ก -u เชื่อมสาขาในเครื่องกับสาขาระยะไกล หลังจากนั้นใช้ git push เฉย ๆ ก็พอ ผลตอบกลับจาก GitHub จะแนบลิงก์สำหรับสร้าง PR มาให้:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

ขั้นตอนที่ 4: เปิด PR บนหน้าเว็บ

คลิกลิงก์จากเทอร์มินัล หรือเปิดรีโพบน GitHub หลังจาก push ล่าสุดจะมีกล่องแจ้งเตือนพร้อมปุ่ม «Compare & pull request» อีกวิธีหนึ่งคือเข้าแท็บ «Pull requests» แล้วกดปุ่ม «New pull request»

1. ตรวจสอบคู่สาขา: base คือปลายทางที่จะรวมเข้า (มักเป็น main) และ compare คือสาขาของคุณ
2. เขียนหัวข้อ: อธิบายว่าทำอะไรไปแล้ว โดยใช้รูปประโยคคำสั่งหรือคำอธิบายสั้น ๆ
3. ในคำอธิบาย ให้บอกว่าทำไมต้องทำ จะตรวจสอบอย่างไร และอะไรอยู่นอกขอบเขต หากรีโพมีเทมเพลต PR ช่องต่าง ๆ จะถูกกรอกให้อัตโนมัติ
4. ทางขวาให้กำหนดผู้รีวิว (Reviewers) ผู้รับผิดชอบ และป้ายกำกับ หากทีมใช้งาน
5. กด «Create pull request» หรือเลือกเป็นฉบับร่าง (ดูด้านล่าง)

สร้าง PR จากเทอร์มินัล: GitHub CLI

หากไม่อยากสลับไปที่เบราว์เซอร์ มีเครื่องมือทางการชื่อ gh ซึ่งไม่ใช่คำสั่งของ Git แต่เป็นโปรแกรมของ GitHub โดยตรง และใช้จัดการ PR ได้สะดวก:

gh pr create --base main --title "เพิ่มฟอร์มเข้าสู่ระบบ" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

สำหรับคำถามว่า «คำสั่ง pull request ใน git มีอะไรบ้าง» คำตอบที่ตรงที่สุดคือ Git จัดการสาขา commit และการ push ส่วน PR ถูกสร้างบนแพลตฟอร์ม ผ่านเบราว์เซอร์ gh หรือ API

วิธีส่ง pull request ไปยังรีโพของคนอื่นผ่าน fork

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

1. ที่หน้าโปรเจกต์ กด «Fork» คุณจะได้ github.com/you/project
2. โคลน fork ของคุณ และเพิ่มต้นฉบับเป็น remote ตัวที่สอง มักตั้งชื่อว่า upstream
3. สร้างสาขา ทำ commit และส่งสาขาไปยัง fork ของคุณ
4. บน GitHub เปิด PR: base repository คือโปรเจกต์ต้นฉบับ และ head repository คือ fork ของคุณพร้อมสาขาที่ทำไว้

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "แก้คำผิดใน README"
git push -u origin fix/typo-readme

ก่อนเริ่มทำงาน ควรอ่านไฟล์ CONTRIBUTING.md ซึ่งมักระบุรูปแบบข้อความ commit ข้อกำหนดการทดสอบ และว่าต้องสร้าง issue ก่อนหรือไม่ ควรให้ fork อัปเดตอยู่เสมอ โดยรัน git fetch upstream และ git rebase upstream/main ในสาขาของคุณ เพื่อให้ PR ไม่ตามหลังต้นฉบับ

Merge request บน GitLab: คืออะไร และสร้างอย่างไร

Merge request ของ GitLab เทียบเท่ากับ pull request บน GitHub อย่างสมบูรณ์ ต่างกันที่ชื่อและรายละเอียดของอินเทอร์เฟซ แต่ขั้นตอนเหมือนกัน: สาขา push คำขอรวม รีวิว และ merge

สร้าง MR ได้หลายวิธี:

• ผ่านลิงก์ที่ GitLab พิมพ์ในเทอร์มินัลหลังจาก git push สาขาใหม่
• ในส่วน Merge requests ของโปรเจกต์ กด «New merge request» แล้วเลือกสาขาต้นทางและปลายทาง
• ระหว่าง push โดยใช้ push options ของ GitLab โดยไม่ต้องเข้าเบราว์เซอร์

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

คำศัพท์ของ GitLab แตกต่างเล็กน้อย การอนุมัติเรียกว่า approve ผู้รับผิดชอบการรวมเรียกว่า assignee และระบบอัตโนมัติคือ GitLab CI/CD ที่ใช้ไฟล์ .gitlab-ci.yml แทน GitHub Actions MR แบบร่างก็มีเช่นกัน เรียกว่า Draft

การรีวิว pull request

ผู้รีวิวเปิดแท็บ «Files changed» และเห็น diff เขาสามารถแสดงความคิดเห็นที่บรรทัดใดก็ได้ หรือเสนอการแก้ไขสำเร็จรูป (suggestion) ซึ่งผู้เขียนกดปุ่มเดียวเพื่อนำไปใช้ ความคิดเห็นทั้งหมดจะถูกรวบรวมเป็นหนึ่งรีวิว และส่งพร้อมคำตัดสินหนึ่งในสามแบบ:

• Comment: ให้ข้อเสนอแนะโดยไม่ตัดสินใจ
• Approve: อนุมัติการเปลี่ยนแปลง
• Request changes: ต้องแก้ไขเพิ่มเติม ยังไม่ควรรวม

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

วิธีตรวจสอบ PR ของคนอื่นในเครื่อง (git checkout pull request)

บางครั้งคุณต้องรันโค้ดบนเครื่องของตัวเอง หากสาขาอยู่ในรีโพเดียวกัน ใช้ git fetch และ git switch ก็พอ สำหรับ PR จาก fork GitHub มีการอ้างอิงพิเศษ pull/<หมายเลข>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

ใน GitLab การอ้างอิงที่เทียบเท่าเรียกว่า merge-requests/<หมายเลข>/head หรือใช้ gh pr checkout 57 หากติดตั้ง GitHub CLI

วิธีอัปเดต pull request หลังได้รับความเห็น

PR ผูกกับสาขา ไม่ได้ผูกกับ commit ใด ๆ โดยเฉพาะ เพียงสร้าง commit ใหม่ในสาขาเดิมแล้วส่งขึ้นไป PR จะอัปเดตเองโดยอัตโนมัติ ไม่ต้องสร้างคำขอใหม่

git commit -am "แก้ตามความเห็นจากการรีวิว"
git push

Git rebase pull request: ดึง main ล่าสุดมาใช้

ระหว่างที่ PR รอรีวิว main อาจก้าวหน้าไปแล้ว หาก GitHub แจ้งว่าสาขาเก่าหรือมีคอนฟลิกต์ ให้อัปเดตสาขา การใช้ rebase จะได้ประวัติเป็นเส้นตรง:

git fetch origin
git rebase origin/main
# แก้คอนฟลิกต์ แล้ว git add แล้ว git rebase --continue
git push --force-with-lease

หลัง rebase แฮชของ commit จะเปลี่ยน ดังนั้น push ธรรมดาจะถูกปฏิเสธและต้องใช้การ push แบบบังคับ ให้ใช้ --force-with-lease ซึ่งจะปฏิเสธการเขียนทับ หากมี commit ของคนอื่นปรากฏบนสาขานั้น หากสาขาถูกใช้ร่วมกันมากกว่าหนึ่งคน ควรใช้ git merge origin/main เพื่อรวม main แทน ซึ่งไม่เขียนประวัติทับ

การรวม pull request: merge, squash และ rebase

เมื่อรีวิวผ่านและการตรวจสอบเป็นสีเขียวทั้งหมด PR ก็พร้อมรวม GitHub มีวิธีให้เลือกสามแบบ และผู้ดูแลรีโพอาจเปิดให้ใช้เพียงบางแบบ

การ merge pull request ผ่านหน้าเว็บ โดยพื้นฐานคือ git merge ที่ทำงานบนเซิร์ฟเวอร์ หลังรวมแล้ว GitHub จะถามว่าต้องการลบสาขาหรือไม่ ให้ยืนยัน เพราะสาขานั้นไม่จำเป็นอีกต่อไป จากนั้นทำความสะอาดในเครื่อง:

git switch main
git pull
git branch -d feature/login-form

คุณยังรวม PR ด้วยตนเองจากเทอร์มินัลได้ คือ merge สาขาเข้า main ในเครื่องแล้ว push GitHub จะตรวจพบว่า commit ของสาขาเข้าไปอยู่ในปลายทางแล้ว และทำเครื่องหมาย PR เป็น merged โดยอัตโนมัติ แต่วิธีนี้จะข้ามการตรวจสอบและกฎการป้องกันสาขา ทีมส่วนใหญ่จึงรวมด้วยปุ่มเสมอ

Auto-merge และ merge queue

หากการตรวจสอบใช้เวลานาน คุณเปิด auto-merge ได้ PR จะถูกรวมเองเมื่อทุกเงื่อนไขครบ ในรีโพขนาดใหญ่ ทีมมักใช้คิวการรวม (merge queue) ซึ่งตรวจสอบ PR ซ้อนบน PR ที่อยู่ในคิวแล้ว เพื่อไม่ให้ main เสียหายจากการเปลี่ยนแปลงที่ขัดแย้งกัน

Pull request แบบร่าง (Draft)

ฉบับร่างคือ PR ที่ยังไม่พร้อมรีวิว จะรวมไม่ได้ และผู้รีวิวจะไม่ได้รับคำขอให้ตรวจสอบ ฉบับร่างมีประโยชน์เมื่อต้องการแสดงทิศทางงานแต่เนิ่น ๆ รัน CI หรือรวบรวมความเห็นเรื่องสถาปัตยกรรม บน GitHub เลือกฉบับร่างได้จากเมนูดรอปดาวน์ของปุ่มสร้าง หรือรัน gh pr create --draft เมื่องานเสร็จแล้ว กด «Ready for review» บน GitLab ฉบับร่างจะถูกระบุด้วยคำนำหน้า Draft: ในหัวข้อของ MR

การเชื่อม pull request กับ issue

หากเขียนคำสำคัญพร้อมหมายเลข issue ในคำอธิบาย PR เมื่อรวมเข้าสาขาหลัก GitHub จะปิด issue นั้นให้อัตโนมัติ:

Closes #42
Fixes #17
Resolves #8

คำอย่าง close, fix, resolve ในรูปแบบต่าง ๆ (closes, fixed, resolves) ใช้ได้ทั้งหมด หากเขียนเพียง #42 โดยไม่มีคำสำคัญ จะเกิดเพียงลิงก์ แต่จะไม่ปิดงาน บน GitLab Closes #42 และวลีที่คล้ายกันก็ทำงานเหมือนกัน

ลบ pull request หรือ merge request ได้หรือไม่

ผู้ใช้ทั่วไปไม่สามารถลบ PR บน GitHub ได้ สามารถทำได้เพียงปิดด้วยปุ่ม «Close pull request» PR ที่ปิดแล้วยังคงอยู่ในประวัติ และสามารถเปิดใหม่ได้ หลังจากปิดแล้วควรลบสาขาแยกต่างหาก การลบ PR ออกไปอย่างสมบูรณ์ทำได้เฉพาะโดยติดต่อฝ่ายสนับสนุนของ GitHub เช่น กรณีที่มีความลับรั่วไหลเข้าไปใน PR

บน GitLab ผู้เขียนหรือสมาชิกที่มีสิทธิ์สามารถปิด MR ได้ ส่วนการลบโดยทั่วไปทำได้เฉพาะเจ้าของโปรเจกต์หรือผู้ดูแลระบบ หากรหัสผ่านหรือโทเค็นหลุดเข้าไปใน PR การปิดอย่างเดียวไม่พอ ให้เพิกถอนความลับนั้นทันที เพราะ commit ได้ถูกส่งขึ้นเซิร์ฟเวอร์ไปแล้ว

ข้อผิดพลาดที่พบบ่อยกับ pull request

• PR จาก main: คุณ commit ลง main ของตัวเอง แล้วเปิด PR จากมัน PR ถัดไปจะมีการเปลี่ยนแปลงเก่ารวมอยู่ด้วย ให้ทำงานในสาขาแยกเสมอ
• base ผิด: PR ถูกเปิดไปยัง develop แทนที่จะเป็น main หรือกลับกัน สามารถเปลี่ยน base ได้ด้วยปุ่ม Edit ข้างหัวข้อ PR
• ไฟล์ที่ไม่เกี่ยวข้องอยู่ใน diff: ไฟล์บิลด์ node_modules หรือ .env ให้เพิ่มเข้า .gitignore และนำออกจากดัชนีด้วย git rm --cached
• PR ใหญ่เกินไป: แบ่งงานเป็น PR เล็ก ๆ ที่ทำต่อเนื่องกัน
• ใช้ push ธรรมดาหลัง rebase: จะเกิดข้อผิดพลาด rejected (non-fast-forward) ให้ใช้ git push --force-with-lease แทน --force
• แก้คอนฟลิกต์ผิดวิธี: อย่าแก้คอนฟลิกต์บนเว็บแบบหลับหูหลับตา ให้ดึง main มาในเครื่อง แก้ แล้วรันการทดสอบ

Pull request กับ git flow และกระบวนการอื่น

Pull request เข้ากับกระบวนการทำงานเป็นทีมได้ทุกแบบ ใน GitHub Flow เรียบง่ายที่สุด คือสร้างสาขาจาก main เปิด PR รีวิว รวม และ deploy ใน git flow PR จะเปิดไปยัง develop จากสาขาฟีเจอร์ และสาขา release กับ hotfix ก็ต้องผ่าน PR เข้า main ด้วย ส่วนการพัฒนาแบบ trunk-based PR จะสั้นและอยู่ได้เป็นชั่วโมง ไม่ใช่เป็นวัน กระบวนการใดก็ตาม กฎเดียวกันคือ การเปลี่ยนแปลงในสาขาที่ใช้ร่วมกันต้องผ่าน pull request เท่านั้น

สรุป

Pull request เป็นกลไกของแพลตฟอร์ม ไม่ใช่คำสั่งของ Git มันคือสาขาที่ส่งขึ้นเซิร์ฟเวอร์ รวมกับหน้าสำหรับการสนทนา การรีวิว และการตรวจสอบ บน GitLab เรียกว่า merge request ส่วนในภาษาพูดเรียกว่า PR และ MR สร้าง PR จากสาขาที่แยกต่างหาก ทำให้มันมีขนาดเล็ก อัปเดตด้วยการ push ไปยังสาขาเดิม และเลือกวิธีรวมให้เหมาะกับประวัติของโปรเจกต์ Fork สาขาฟีเจอร์ และ pull request มีการอธิบายโดยละเอียดพร้อมการลงมือทำจริงในคอร์ส Git