พุช — คืออะไร git push ทำงานอย่างไร และเมื่อใดที่จำเป็น

การพุชใน Git คืออะไร

Git push เป็นคำสั่งที่ถ่ายโอนคอมมิตจาก repository ในเครื่องไปยังรีโมท repository ซึ่งแตกต่างจาก commit ที่บันทึกการเปลี่ยนแปลงเฉพาะในเครื่องของนักพัฒนาเท่านั้น การพุชจะเผยแพร่การเปลี่ยนแปลงเหล่านั้นให้ทั้งทีม Push เป็นขั้นตอนบังคับก่อนการสร้าง Pull Request และการปรับใช้

สถาปัตยกรรมของ Git สันนิษฐานว่านักพัฒนาแต่ละคนทำงานใน repository ในเครื่องของตนเอง คอมมิตถูกสร้างขึ้นในเครื่องและสะสมจนกว่านักพัฒนาจะตัดสินใจพุช สิ่งนี้ให้อิสระ: คุณสามารถสร้างคอมมิตในเครื่องจำนวนมาก ทดลอง และเขียนประวัติใหม่โดยไม่กระทบต่อเพื่อนร่วมงาน

# พุชไปยังรีโมท origin, branch main
git push origin main

# พุช branch ปัจจุบันไปยังรีโมทด้วย upstream
git push -u origin feature/new-dashboard

# พุชทุก branch ที่มีชื่อตรงกัน
git push --all origin

# Force push พร้อม lease (force push ที่ปลอดภัย)
git push --force-with-lease

หลังจากการพุช รีโมท repository จะอัปเดต refs (การอ้างอิง branch) เพื่อชี้ไปยังคอมมิตใหม่ นักพัฒนาคนอื่นสามารถรับการเปลี่ยนแปลงเหล่านี้ผ่าน git pull หรือ git fetch การแลกเปลี่ยนคอมมิตนี้เป็นพื้นฐานของการพัฒนาแบบร่วมมือ

git push ทำงานอย่างไร

คำสั่ง git push เปรียบเทียบ branch ในเครื่องและรีโมท และถ่ายโอนเฉพาะคอมมิตที่ขาดหายไป Git ไม่ได้ส่งไฟล์ทั้งหมดอีกครั้ง — มันส่งเฉพาะ delta ซึ่งทำให้การพุชรวดเร็วแม้กับ repository ขนาดใหญ่ โปรโตคอล Git ใช้การส่งแบบอัจฉริยะซึ่งลดปริมาณข้อมูลที่ส่ง

หากรีโมท branch มีคอมมิตที่ไม่มีในเครื่อง การพุชจะถูกปฏิเสธ นี่เป็นกลไกป้องกันที่ป้องกันการสูญเสียการเปลี่ยนแปลง ในสถานการณ์นี้ นักพัฒนาต้องรัน git pull ก่อน รวมการเปลี่ยนแปลง จากนั้นจึงพุชอีกครั้ง ทางเลือกคือ force push ซึ่งเขียนทับรีโมท branch แต่ต้องใช้ด้วยความระมัดระวัง

การเข้าใจรีโมท repository เป็นกุญแจสำคัญในการพุชที่ถูกต้อง โดยทั่วไป origin เป็นชื่อเริ่มต้นของรีโมท repository คำสั่ง git remote -v แสดงรายการรีโมท repository และ URL ของคุณสามารถเพิ่มรีโมทหลายตัว (เช่น origin สำหรับ repository หลัก และ upstream สำหรับ fork)

เมื่อใดควรพุชการเปลี่ยนแปลง

กฎหลัก: พุชหลังจากแต่ละขั้นตอนของงานที่เสร็จสมบูรณ์ตามตรรกะ หากนักพัฒนาทำงานหรือส่วนหนึ่งเสร็จ — ถึงเวลาพุช อย่างไรก็ตาม ไม่แนะนำให้พุชงานที่ยังไม่เสร็จซึ่งทำให้ build เสียหาย Build ไม่เสียหาย เป็นข้อกำหนดขั้นต่ำสำหรับการพุชไปยัง branch ใดๆ

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

• หลังจากทำงานเสร็จ — commit และพุชโซลูชันสุดท้ายไปยัง feature branch
• ก่อนกลับบ้าน — พุชงานที่ยังไม่เสร็จไปยัง feature branch (ไม่ใช่ main!)
• ก่อนสร้าง PR — ตรวจสอบให้แน่ใจว่าคอมมิตทั้งหมดถูกพุชและพร้อมสำหรับการตรวจสอบ
• หลังจาก rebase — พุชด้วย --force-with-lease ไปยัง feature branch ของคุณ

กฎการพุชที่ปลอดภัย

การพุชที่ปลอดภัยคือชุดของกฎที่ป้องกันการสูญเสียข้อมูลและความขัดแย้งในทีม กฎข้อแรกและสำคัญที่สุด: อย่าพุชไปยัง main หรือ master branch โดยตรงหากโปรเจกต์ไม่ได้กำหนดค่าการปรับใช้โดยตรง ในทีมสมัยใหม่ การป้องกัน main branch ถูกกำหนดค่าระดับ การป้องกัน branch ของ GitHub

กฎข้อที่สอง: ซิงโครไนซ์กับรีโมท branch ก่อนพุช รัน git pull --rebase เพื่อหลีกเลี่ยงคอมมิตการรวมเมื่อรวม สิ่งนี้ทำให้ประวัติง่ายขึ้นและเป็นเส้นตรง หากการพุชถูกปฏิเสธ — อย่าใช้ force push เปล่า แต่ให้ค้นหาก่อนว่าคอมมิตใดปรากฏบนรีโมท branch

กฎข้อที่สาม: ตั้งค่า pre-push hooks ที่รันการทดสอบและ linter โดยอัตโนมัติก่อนส่ง หากการทดสอบล้มเหลว — การพุชจะถูกบล็อก hooks เหล่านี้ถูกกำหนดค่าผ่าน Husky หรือ Git hooks (ไฟล์ pre-push ใน .git/hooks)

กฎข้อที่สี่: อย่าพุชไฟล์ไบนารีขนาดใหญ่ Git ไม่ได้ออกแบบมาเพื่อจัดเก็บสิ่งประดิษฐ์แบบไบนารี — มันทำให้ repository ใหญ่ขึ้นและทำให้การดำเนินการช้าลง สำหรับไฟล์ขนาดใหญ่ ให้ใช้ Git LFS (Large File Storage) หากไฟล์ไบนารีถูกพุชไปแล้วและอยู่ในประวัติ จะต้องลบผ่าน git filter-branch

จะทำอย่างไรหากการพุชล้มเหลว

สาเหตุที่พบบ่อยที่สุดของการพุชล้มเหลวคือรีโมท branch มีคอมมิตที่ไม่มีในเครื่อง สิ่งนี้เกิดขึ้นเมื่อนักพัฒนาคนอื่นพุชการเปลี่ยนแปลงของตนไปยัง branch เดียวกัน วิธีแก้ไข: รัน git pull แก้ไขความขัดแย้งใดๆ และพุชอีกครั้ง

# การพุชถูกปฏิเสธ — ให้ fetch และ rebase ก่อน
git fetch origin
git rebase origin/main
# แก้ไขความขัดแย้ง จากนั้น:
git push --force-with-lease

# หรือเพียงรวมการเปลี่ยนแปลงรีโมท
git pull origin main
git push

สาเหตุที่สอง — ขาดสิทธิ์ในการเขียนไปยัง branch หาก main branch ได้รับการป้องกันโดยกฎการป้องกัน branch การพุชโดยตรงเป็นสิ่งต้องห้าม วิธีแก้ไข: พุชไปยัง feature branch และสร้าง Pull Request การตั้งค่าการป้องกันมักจะจัดการผ่าน การตั้งค่า GitHub หรือ branch ที่ได้รับการป้องกันของ GitLab

สาเหตุที่สาม — ปัญหาการตรวจสอบสิทธิ์ ข้อมูลประจำตัวที่ล้าสมัย การเปลี่ยนไปใช้ SSH หรือการเปลี่ยนแปลงโทเค็นการเข้าถึงส่วนบุคคล วิธีแก้ไข: ตรวจสอบ URL รีโมท (git remote -v) และอัปเดตข้อมูลประจำตัว ตั้งแต่ปี 2021 GitHub ได้ยกเลิกการตรวจสอบสิทธิ์ด้วยรหัสผ่านสำหรับ HTTPS — ใช้โทเค็นส่วนบุคคลหรือคีย์ SSH