โอ้ชิท, Git? หนังสือออกแล้ว

 (ohshitgit.com)
4 คะแนน โดย GN⁺ 2025-01-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • วิธีแก้ปัญหา Git

    • เน้นว่า Git เป็นเครื่องมือที่ซับซ้อนและผิดพลาดได้ง่าย ทำให้การหาวิธีแก้ปัญหาเป็นเรื่องยาก
    • อธิบายสถานการณ์ปัญหาหลากหลายแบบและวิธีแก้ด้วยภาษาอังกฤษที่เรียบง่าย

  • สถานการณ์ปัญหาและวิธีแก้

    • เมื่ออยากย้อนงานที่ทำพลาด

      • ใช้ git reflog เพื่อตรวจดูรายการงานก่อนหน้า แล้วใช้ git reset HEAD@{index} เพื่อย้อนกลับไปยังจุดที่ต้องการ

    • เมื่อจำเป็นต้องแก้ไขเล็กน้อยหลัง commit

      • หลังแก้ไขแล้ว ใช้ git add . และ git commit --amend --no-edit เพื่อเพิ่มการเปลี่ยนแปลงเข้าไปใน commit ล่าสุด
      • ข้อควรระวัง: อย่าแก้ไข commit ที่เผยแพร่ไปแล้ว

    • เมื่ออยากเปลี่ยนข้อความของ commit ล่าสุด

      • ใช้ git commit --amend เพื่อเปลี่ยนข้อความ

    • เมื่อ commit ลง branch ผิด

      • สร้าง branch ใหม่ แล้วใช้ git reset HEAD~ --hard เพื่อลบ commit ออกจาก master branch จากนั้นย้ายไปยัง branch ใหม่เพื่อเก็บ commit ไว้

    • เมื่อคำสั่ง diff ไม่ทำงาน

      • ใช้ git diff --staged เพื่อตรวจสอบความแตกต่างของไฟล์ที่ถูก staged ไว้

    • เมื่ออยากย้อน commit ก่อนหน้า

      • หา commit ด้วย git log แล้วใช้ git revert [saved hash] เพื่อย้อน commit นั้น

    • เมื่ออยากย้อนการเปลี่ยนแปลงของไฟล์

      • หา commit ก่อนหน้าด้วย git log แล้วใช้ git checkout [saved hash] -- path/to/file เพื่อย้อนไฟล์กลับ

  • อื่น ๆ

    • เมื่ออยากรีเซ็ต repository กลับสู่สถานะเริ่มต้น
      • ใช้ git fetch origin, git checkout master, git reset --hard origin/master เพื่อซิงก์กับ remote repository
      • ใช้ git clean -d --force เพื่อลบไฟล์และไดเรกทอรีที่ไม่ได้ถูกติดตาม

  • ข้อควรระวัง

    • มีการระบุว่าเว็บไซต์นี้ไม่ใช่เอกสารอ้างอิงแบบครอบคลุม และอาจมีวิธีอื่นอีกหลายแบบ
    • กล่าวขอบคุณผู้คนหลายคนที่มีส่วนร่วมในการแปล

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-18
ความคิดเห็นจาก Hacker News
  • ควรใช้ git switch แทน git checkout
  • แนะนำวิธีหลีกเลี่ยง reset --hard และแก้ปัญหาเมื่อเผลอคอมมิตลงผิดบรานช์ด้วยการสร้างบรานช์ใหม่
    • สร้างบรานช์ใหม่จากสถานะปัจจุบัน
    • ย้ายกลับไปยังคอมมิตก่อนหน้า
    • เขียนทับบรานช์ master ให้ชี้ไปที่คอมมิตนั้น
    • สลับกลับไปยังบรานช์งาน
  • แนะนำวิธีใช้ cherry-pick เพื่อแก้กรณีคอมมิตลงผิดบรานช์
    • สลับไปยังบรานช์ที่ถูกต้อง
    • ดึงคอมมิตล่าสุดของ master มา
    • ลบออกจาก master
  • แนะนำวิธีใช้ git ในสถานการณ์แบบ "ยอมแพ้แล้ว"
    • ดึงสถานะล่าสุดจาก origin
    • กู้คืนไฟล์ที่ถูกติดตาม
    • ลบไฟล์และไดเรกทอรีที่ไม่ได้ถูกติดตาม
    • รีเซ็ต master ให้ตรงกับเวอร์ชันบนรีโมต
  • การเริ่มเรียนรู้ Git โดยใช้ UI เป็นค่าเริ่มต้นน่าจะดีกว่า
    • ถ้าภายหลังรู้สึกว่า CLI เร็วกว่า ค่อยเปลี่ยนไปใช้ได้
    • ควรเข้าใจการโต้ตอบกับ tree ในเชิงภาพก่อน
  • ดีใจที่มีผลการค้นหาเกี่ยวกับ hg+mercurial
    • น่าเสียดายที่ hg แพ้ในสงคราม dvcs
  • จำอาร์กิวเมนต์ของคำสั่ง Git ได้ยาก
    • คำสั่งไม่ได้ออกแบบมาให้ค้นพบได้ง่ายหรือจำได้สะดวก
  • ตอนฉลองครบรอบ 20 ปีของ git ในเดือนเมษายน 2025 คงจะรู้สึกแปลก ๆ
    • ผลของ GitHub อาจทำให้ไม่จำเป็นต้องมี VCS ตัวใหม่แล้ว
  • ในสถานการณ์แบบ "Oh shit" มักใช้วิธีลบ local repository แล้ว clone ใหม่
    • ใช้ได้ผลดีใน 95% ของกรณี
  • จำ git reflog ได้ยาก เพราะเผลออ่านเป็น "re-flog"
  • แม้จะไม่ใช่ผู้ใช้ Git แต่รู้สึกว่า "git commit" ไม่มีความหมายอะไร
    • คอมมิตจะสำคัญก็ต่อเมื่อถูก push หรือ merge เท่านั้น
  • ข้อดีอย่างหนึ่งของ Git คือเมื่อสร้างอ็อบเจ็กต์แล้ว งานนั้นจะไม่หายไป
    • การคอมมิตบ่อย ๆ เป็นสิ่งสำคัญ