Cherry-pick — คืออะไร กลไกและการใช้งานใน Git
Cherry-pick — คือคําสั่ง Git ที่ใช้“นํา”การเปลี่ยนแปลงจากหนึ่งคอมมิตหรือหลายคอมมิตที่มีอยู่ไปยังสาขาปัจจุบัน ต่างจาก Merge (ย้ายทั้งสาขา) และ Rebase (ย้ายลําดับของคอมมิต) cherry-pick จะเลือกเฉพาะคอมมิตที่ระบุเท่านั้น ตามข้อมูลจาก git-scm.com, 2025 cherry-pick ถูกใช้มากที่สุดในสถานการณ์“การย้าย”การแก้ไขระหว่างสาขา release
สาระสำคัญ
- Cherry-pick — “การย้าย”คอมมิตเฉพาะระหว่างสาขาโดยไม่ต้องรวมสาขาทั้งหมด
- “การย้าย”แบบเจาะจง — เลือกเฉพาะคอมมิตที่ต้องการ ไม่ใช่ทั้งสาขา
- SHA ใหม่ — ทุก cherry-pick สร้างคอมมิตใหม่ที่มีแฮชเปลี่ยนไป
- สถานการณ์ Hotfix — cherry-pick สะดวกสําหรับ“การย้าย”การแก้ไขไปยังสาขา release
- “ความเสี่ยง” — “การทํา”คอมมิตซ้ำและการสูญเสียบริบทเมื่อใช้งานมากเกินไป
Cherry-pick คืออะไร?
Cherry-pick — คือคําสั่ง Git ที่“คัดลอก”การเปลี่ยนแปลงจากคอมมิตที่ระบุและ“นํา”ไปใช้เป็นคอมมิตใหม่ในสาขาปัจจุบัน ชื่อมาจากคําอุปมาว่า “”เลือกเชอร์รี่””: นักพัฒนาจะเลือกเฉพาะคอมมิตที่ต้องการ โดยไม่สนใจส่วนที่เหลือ
ต่างจาก Merge ตรงที่ cherry-pick ไม่ได้สร้าง merge commit และไม่จําเป็นต้องรวมสาขาทั้งหมด ต่างจาก Rebase ตรงที่ cherry-pick ไม่ได้“ย้าย”ลําดับของคอมมิต — เฉพาะที่ระบุเท่านั้น “ทําให้”cherry-pick เป็นเครื่องมือที่เหมาะสําหรับ“การย้าย”การแก้ไขแบบเจาะจง
ตามข้อมูลจาก Atlassian, 2025 cherry-pick ถูกใช้ใน 47% ของทีมที่“ทํางาน”กับหลายสาขา release พร้อมกัน โดยเฉพาะอย่างยิ่ง cherry-pick เป็นที่ต้องการในการพัฒนาแอปพลิเคชันมือถือ ซึ่งต้องสนับสนุนหลายเวอร์ชันของแอป (LTS releases) พร้อมกัน และจําเป็นต้อง“ย้าย”การแก้ไขระหว่างเวอร์ชันเหล่านั้น
กลไก“การย้าย”
เมื่อ“ดําเนินการ”cherry-pick Git จะ“คํานวณ” diff ระหว่างคอมมิตที่ระบุกับคอมมิตต้นทาง จากนั้น“นํา”diff นี้ไปใช้กับสาขาปัจจุบัน หาก“การเปลี่ยนแปลง”ถูก“นํา”ไปใช้โดยไม่มีการขัดแย้ง — Git จะสร้างคอมมิตใหม่ที่มีข้อความเดียวกัน แต่ SHA ใหม่ หากมีการขัดแย้ง — cherry-pick จะหยุดชั่วคราวเพื่อให้แก้ไขด้วยตนเอง
Cherry-pick “ทํางาน”อย่างไร
ไวยากรณ์ ของ cherry-pick ง่าย: ระบุแฮชของคอมมิตที่ต้องการ“ย้าย” Git จะ“คัดลอก”“การเปลี่ยนแปลง”ไปยังสาขาปัจจุบันเป็นคอมมิตใหม่ รองรับ“การย้าย”หลายคอมมิตในครั้งเดียวและช่วงทั้งหมด
bash
# ย้ายคอมมิตเดียวไปยังสาขาปัจจุบัน
git cherry-pick a1b2c3d4
# ย้ายหลายคอมมิต
git cherry-pick a1b2c3d4 e5f6g7h8
# ย้ายช่วงของคอมมิต (จาก a1b2 ถึง f9e8, ไม่รวม a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6หลังจาก“ดําเนินการ”cherry-pick สาขาปัจจุบัน จะได้รับคอมมิตใหม่ที่มี“การเปลี่ยนแปลง”จากต้นฉบับ ข้อความของคอมมิตโดยค่าเริ่มต้นจะ“คัดลอก”จากต้นฉบับ แต่สามารถ“เปลี่ยนแปลง”ได้ด้วยแฟล็ก -n (ไม่สร้างคอมมิต) หรือ --edit (แก้ไขข้อความ)
ตัวอย่าง“การย้าย”“การแก้ไข”
ลอง“พิจารณา” สถานการณ์ทั่วไป: ใน develop พบและแก้ไขบั๊กที่ร้ายแรง ซึ่งมีอยู่ในสาขา release release/v2.0 เช่นกัน จําเป็นต้อง“ย้าย”เฉพาะ“การแก้ไข”นี้ โดยไม่ต้องรวมทั้ง develop ไปยังสาขา release
bash
# ค้นหาแฮชคอมมิตที่มีการแก้ไขใน develop
git log --oneline develop
# a1b2c3d fix: ตรวจสอบ null ในการประมวลผลการชำระเงิน
# สลับไปยังสาขา release
git checkout release/v2.0
# นำการแก้ไขไปใช้
git cherry-pick a1b2c3d4
# หากมีการขัดแย้ง — ให้แก้ไขและดำเนินการต่อ
git add src/payment/PaymentProcessor.kt
git cherry-pick --continueแฟล็ก -x จะเพิ่ม“การอ้างอิง”ถึง SHA ต้นฉบับในข้อความคอมมิต: “(cherry picked from commit a1b2c3d4)”d ซึ่งช่วยให้ติดตามได้ง่ายว่าคอมมิตถูก“ย้าย”มาจากที่ไหน แนะนําให้ใช้ -x ในทุกสถานการณ์ยกเว้นแบบร่างชั่วคราว
“การจัดการ”กับการขัดแย้ง
เมื่อเกิด “การขัดแย้ง” cherry-pick จะ“ทํางาน”เหมือน merge: Git จะหยุดและ“ทําเครื่องหมาย”ไฟล์ที่มี“การขัดแย้ง” นักพัฒนาแก้ไข“การขัดแย้ง” “ทํา”git add และ“ดําเนินการ”git cherry-pick --continue หากต้องการ“ยกเลิก” — ใช้ git cherry-pick --abort แฟล็ก --strategy อนุญาตให้ระบุกลยุทธ์“การรวม” (เช่น recursive พร้อมตัวเลือก)
bash
# การแก้ไขการขัดแย้งเมื่อใช้ cherry-pick
# Git แสดงไฟล์ที่มีการขัดแย้ง
git status
# แก้ไขด้วยตนเอง จากนั้น:
git เพิ่ม ไฟล์_ที่อนุญาต.kt
git cherry-pick --continue
# หรือยกเลิก cherry-pick:
git cherry-pick --abortเมื่อใดควรใช้ Cherry-pick
Cherry-pick เหมาะที่สุดในสถานการณ์ที่ต้องการ“การย้าย”“การเปลี่ยนแปลง”แบบเจาะจงโดยไม่ต้องรวมทั้งสาขา มาดูห้ากรณีหลักที่ cherry-pick เป็นตัวเลือกที่ดีที่สุด
- “การย้าย”Hotfix — พบ“การแก้ไข”ใน develop แต่จําเป็นต้อง“นํา”ไปใช้ในสาขา release (release/v2.0) Cherry-pick จะ“ย้าย”เฉพาะคอมมิท“การแก้ไข” โดยไม่กระทบต่อฟีเจอร์ที่ยังไม่เสร็จใน develop
- Backport ไปยังเวอร์ชันเก่า — “การแก้ไข”สําหรับเวอร์ชันปัจจุบันจําเป็นต้อง“ย้าย”ไปยัง LTS release แทนที่จะรวมฐานโค้ดปัจจุบันทั้งหมด cherry-pick จะเลือกเฉพาะคอมมิตที่ต้องการ
- “การยกเลิก”คอมมิตในสาขาอื่น — หากคอมมิตถูกสร้างในสาขาผิด cherry-pick จะ“ย้าย”ไปยังสาขาที่ถูกต้อง และคอมมิตต้นฉบับจะถูก“ยกเลิก”
- “การย้าย”เอกสาร — “การเปลี่ยนแปลง”ใน README หรือไฟล์คอนฟิกที่ควรมีในทุกสาขา สะดวกใน“การย้าย”ผ่าน cherry-pick
- “การนํา”ไปใช้แบบเลือก — จากสาขาต้นแบบต้องการ“นํา”เฉพาะคอมมิตที่ดีเพียงอันเดียว โดยไม่ต้อง“ย้าย”ทั้งต้นแบบไปยัง“การพัฒนา”หลัก
สําหรับ “การพัฒนา”แอปพลิเคชันมือถือ cherry-pick มี“ความสําคัญ”อย่างยิ่งเมื่อต้องสนับสนุนหลายเวอร์ชันของแอป ตัวอย่างเช่น หากพบข้อบกพร่องในเวอร์ชัน 3.2 ที่เผยแพร่ใน Google Play แล้ว ในขณะที่ develop มีโค้ดสําหรับเวอร์ชัน 4.0 — cherry-pick ช่วยให้“ย้าย”“การแก้ไข”ไปยังสาขา v3.x โดยไม่ต้องรวม“การเปลี่ยนแปลง”ที่“ทําลาย”“ความเข้ากันได้”ทั้งหมด โดยเฉพาะอย่างยิ่งสําหรับโปรเจกต์ที่ต้องสนับสนุนสองเวอร์ชันหลักขึ้นไปพร้อมกันที่มี API และ dependencies ต่างกัน
ตัวอย่างจากปฏิบัติจริง: ในแอปพลิเคชันมือถือพบ crash เมื่อเข้าสู่ระบบผ่าน Google Sign-In บน Android 12 “การแก้ไข”ถูก“นําเข้า”ใน develop และผ่าน“การตรวจสอบ”แล้ว อย่างไรก็ตาม สาขา release ปัจจุบัน v2.5 อยู่ในขั้นตอน beta-testing “การใช้”cherry-pick คอมมิต“การแก้ไข”จาก develop ไปยัง release/v2.5 ช่วยให้รวม“การแก้ไข”ใน release ถัดไป โดยไม่ต้อง“ย้าย”“การเปลี่ยนแปลง”อื่นที่ยังไม่พร้อมสําหรับ“การเผยแพร่”
เมื่อใช้ cherry-pick ใน โปรเจกต์มือถือ สิ่งสําคัญที่ต้อง“พิจารณา”คือ dependencies: หาก“การแก้ไข”กระทบไฟล์ที่ถูก“เปลี่ยนแปลง”ใน develop หลังจากจุดที่สาขา release แยกออกไป cherry-pick อาจ“นํา”ชุด“การเปลี่ยนแปลง”ที่ไม่สมบูรณ์มา ในกรณีเช่นนี้จําเป็นต้องตรวจสอบว่า“การเปลี่ยนแปลง”ที่เกี่ยวข้องทั้งหมดถูก“ย้าย”แล้ว มิฉะนั้นแอปพลิเคชันอาจไม่สามารถ build หรือ“ทํางาน”ไม่ถูกต้อง ควรตรวจสอบ build หลังจาก cherry-pick เสมอก่อนที่จะ push “การเปลี่ยนแปลง”ไปยังสาขาร่วม
Cherry-pick vs Merge vs Rebase
เครื่องมือหลักสามอย่าง สําหรับ“การรวม”“การเปลี่ยนแปลง”ใน Git — merge, rebase และ cherry-pick — แก้ปัญหาที่แตกต่างกัน “การเลือก”ขึ้นอยู่กับปริมาณ“การเปลี่ยนแปลง”ที่ต้องการ“ย้าย”และลักษณะของประวัติที่ต้องการ
| เกณฑ์ | Merge | Rebase | Cherry-pick |
|---|---|---|---|
| ปริมาณ | ทั้งสาขา | ชุดของคอมมิต | คอมมิตที่เลือก |
| ประวัติ | “คง”“การแตกกิ่ง” | เชิงเส้น | เชิงเส้น |
| Merge commit | ใช่ (ยกเว้น ff) | ไม่ | ไม่ |
| อัตโนมัติ | เต็มรูปแบบ | ตามลําดับ | เฉพาะที่ระบุ |
| สําหรับสาขาสาธารณะ | ปลอดภัย | อันตราย | ปลอดภัย |
Merge — เมื่อต้องการรวมสองสาขาทั้งหมดและเก็บข้อมูล“การแตกกิ่ง” Rebase — เมื่อต้องการอัปเดตสาขาส่วนตัวให้เป็นสถานะปัจจุบันด้วยประวัติที่สะอาด Cherry-pick — เมื่อต้องการเพียงคอมมิตเดียวหรือหลายคอมมิตที่เลือก
ในทางปฏิบัติ เครื่องมือเหล่านี้ ใช้ร่วมกัน: ฟีเจอร์ถูก“พัฒนา”ด้วย“การ”rebase บน develop เป็นระยะ จากนั้นรวมผ่าน --no-ff merge และเมื่อจําเป็นต้อง“ย้าย”“การแก้ไข”ไปยังสาขาอื่น จะใช้ cherry-pick แต่ละเครื่องมือแก้ปัญหาของตัวเองในแต่ละขั้นตอน
“ความเสี่ยง”และข้อจํากัดของ Cherry-pick
Cherry-pick เป็นเครื่องมือที่มีประโยชน์ แต่อาจเป็นอันตรายหากใช้ไม่ถูกต้องหรือมากเกินไป “ความเสี่ยง”หลักเกี่ยวข้องกับ“การทํา”คอมมิตซ้ำ “การสูญเสีย”บริบท และ“การขัดแย้ง”ใน“การรวม”ในภายหลัง
- “การทํา”คอมมิตซ้ำ — หากคอมมิตเดียวกันถูก“นําเข้า”สู่สาขาผ่าน merge ในภายหลัง Git จะสร้างคอมมิตที่สองที่เหมือนกัน “ทําให้”ประวัติสกปรกและ“ทําให้”git bisect ยากขึ้น
- “การสูญเสีย”บริบท — cherry-pick “ย้าย”diff แต่ไม่ได้“ย้าย”ข้อมูลเกี่ยวกับคอมมิตต้นทางและ dependencies หาก cherry-pick “นํา”คอมมิต A โดยไม่มีคอมมิต B ที่ A ขึ้นอยู่ อาจเกิดข้อผิดพลาดเชิงตรรกะ
- “การขัดแย้ง”เมื่อ merge — หลังจาก cherry-pick เมื่อรวมสาขาทั้งหมด Git อาจเห็น“การเปลี่ยนแปลง”เดียวกันสองครั้งและสร้าง“การขัดแย้ง”ที่สามารถหลีกเลี่ยงได้หากใช้ merge ปกติ
- ขาด“การเชื่อมโยง” — หากไม่มีแฟล็ก -x จะไม่สามารถรู้ได้ว่าคอมมิตถูก“ย้าย”มาจากสาขาอื่น เมื่อค้นหาต้นกําเนิดของ“การเปลี่ยนแปลง” นักพัฒนาอาจใช้เวลาหลายชั่วโมงใน“การหา”ที่มาของคอมมิต
คําแนะนําใน“การลด”“ความเสี่ยง”: ใช้แฟล็ก -x เสมอเพื่อระบุ SHA ต้นฉบับ บันทึกเหตุผลของ cherry-pick ในข้อความคอมมิต และหากเป็นไปได้ ใช้ merge แทน cherry-pick เมื่อบริบทเอื้ออํานวย หากมี cherry-pick มากเกินไป — ให้“พิจารณา”“การปรับ”โครงสร้างสาขา
“การตรวจสอบ”อัตโนมัติเมื่อใช้ Cherry-pick
CI pipelines ควร“พิจารณา”cherry-pick เป็นสถานการณ์แยกต่างหาก แนะนําให้ตั้งค่า“การตรวจสอบ”อัตโนมัติ: เมื่อสร้างคอมมิต cherry-pick CI จะตรวจสอบว่าไฟล์ที่“เปลี่ยนแปลง”ตรงกับชุดที่คาดหวัง และรันทดสอบสําหรับโมดูลที่เกี่ยวข้อง ซึ่งช่วยลด“ความเสี่ยง”ของ“การถดถอย”เมื่อ“ย้าย”“การเปลี่ยนแปลง”แบบเจาะจงระหว่างสาขา
คําถามที่พบบ่อย
Cherry-pick แตกต่างจาก git revert อย่างไร?
Cherry-pick “ย้าย”“การเปลี่ยนแปลง”จากคอมมิตไปยังสาขาอื่น Revert สร้างคอมมิตใหม่ที่“ยกเลิก”“การเปลี่ยนแปลง”ของคอมมิตที่ระบุในสาขาเดียวกัน Revert ไม่ได้ลบประวัติ — มันเพิ่ม“การเปลี่ยนแปลง”ย้อนกลับ
สามารถ cherry-pick หลายคอมมิตพร้อมกันได้ไหม?
ได้: git cherry-pick A B C — “ย้าย”คอมมิต A, B และ C ตามลําดับ หรือ git cherry-pick A..C — “ย้าย”คอมมิตทั้งหมดจาก A ถึง C (ไม่รวม A) ลําดับ“การย้าย”สอดคล้องกับลําดับในคําสั่ง
Cherry-pick “ทํางาน”กับ merge commit อย่างไร?
โดยค่าเริ่มต้น cherry-pick merge commit ไม่“ทํางาน” เพราะ merge commit มีสอง parents ให้ใช้แฟล็ก -m 1 เพื่อระบุว่าจะเปรียบเทียบกับ parent ใด -m 1 จะ“นํา”diff เทียบกับ parent แรก
จะ“ทํา”อย่างไรถ้า cherry-pick สร้างคอมมิตที่ไม่ถูกต้อง?
“ยกเลิก” cherry-pick ได้ผ่าน git reset --hard HEAD~1 หากเป็นคอมมิตล่าสุด หากคอมมิตถูก push แล้ว — ใช้ git revert <SHA> เพื่อสร้างคอมมิต“ยกเลิก”
Cherry-pick สามารถ“ย้าย”คอมมิตจากสาขาหนึ่งไปยังสาขาเดียวกันได้ไหม?
ไม่มีประโยชน์ แต่ทางเทคนิคสามารถ“ทํา”ได้ หากคอมมิตมีอยู่ในสาขานั้นแล้ว Git จะพบว่ามี“การเปลี่ยนแปลง”อยู่แล้ว และแจ้งว่า: “The previous cherry-pick is now empty, possibly due to conflict resolution.” คอมมิตจะไม่ถูกสร้างซ้ำ
สรุป
- Cherry-pick — “การย้าย”คอมมิตที่เลือกระหว่างสาขาโดยไม่ต้องรวมทั้งสาขา
- กลไก — Git “คํานวณ”diff ของคอมมิตและ“นํา”ไปใช้เป็นคอมมิตใหม่ใน target
- สถานการณ์ Hotfix — use case หลัก: “ย้าย”“การแก้ไข”ไปยังสาขา release
- แฟล็ก -x — จําเป็นสําหรับ“การบันทึก”SHA ต้นฉบับของคอมมิตที่ถูก“ย้าย”
- “ความเสี่ยง” — “การทํา”คอมมิตซ้ำ, “การสูญเสีย”บริบท, “การขัดแย้ง”เมื่อ merge ในอนาคต
- ข้อแตกต่างจาก Merge — cherry-pick แบบเจาะจง, merge รวมสาขาทั้งหมด
- ข้อแตกต่างจาก Rebase — cherry-pick เลือกคอมมิตด้วยตนเอง, rebase อัตโนมัติสําหรับลําดับ
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม