git revert คือ | SiamCafe Blog

git revert คืออะไร — ทำความเข้าใจคำสั่งย้อนกลับใน Git อย่างถูกวิธี

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

ฟังดูเรียบง่าย แต่เป็นหัวใจของการทำงานกับทีมที่ต้องความปลอดภัยในระดับสูง เพราะเมื่อเราย้อนการเปลี่ยนแปลงด้วยการเพิ่มประวัติใหม่เข้าไป แทนที่จะลบประวัติเก่าทิ้ง ทุกคนในทีมจะยังเห็นประวัติที่ตรงกัน ไม่มีความขัดแย้งในภายหลัง ผมทำงานด้านระบบและเขียนโค้ดมากว่าสิบสามปี ใช้ Git ในทุกโปรเจกต์ ทั้งงานเว็บ งานระบบซิกแนล และเครื่องมือภายในทีม และสิ่งที่ผมเรียนรู้คือ คนส่วนใหญ่รู้จักคำสั่งย้อนกลับแบบผิวเผิน เช่น รู้ว่ามี reset กับ revert อยู่ แต่ไม่เข้าใจว่าอะไรควรใช้เมื่อไร ซึ่งความไม่ชัดเจนนี้เองที่นำไปสู่ปัญหาใหญ่ในระบบที่ใช้งานจริง

หลักการทำงานของ revert คือการคำนวณความต่างระหว่างคอมมิตที่เราต้องการยกเลิกกับคอมมิตก่อนหน้า จากนั้นนำความต่างนั้นมากลับด้าน แล้วสร้างเป็นคอมมิตใหม่ที่มีเนื้อหาตรงข้าม ตัวอย่างเช่น ถ้าคอมมิตเดิมเพิ่มสามบรรทัดลงในไฟล์ คอมมิตที่เกิดจากการย้อนกลับจะลบสามบรรทัดนั้นออก แต่ถ้าคอมมิตเดิมลบบรรทัดไป ผลลัพธ์ก็คือบรรทัดเหล่านั้นกลับมา ด้วยกลไกนี้ การย้อนกลับจึงเป็นการกระทำที่บันทึกไว้ในประวัติอย่างชัดเจน ตรวจสอบได้ และย้อนกลับอีกครั้งได้เสมอ

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

การที่จะใช้คำสั่งนี้ได้อย่างมั่นใจ ต้องเข้าใจก่อนว่า Git จัดเก็บประวัติอย่างไร ทุกคอมมิตใน Git คือข้อมูลบล็อกที่มีตัวระบุเฉพาะ

คือชุดตัวอักษรยาวที่เกิดจากการคำนวณเนื้อหาทั้งหมดของคอมมิตนั้น พร้อมชี้ไปยังคอมมิตก่อนหน้า เมื่อเราใช้คำสั่งย้อนกลับ Git จะอ่านคอมมิตที่เราระบุ คำนวณความต่างระหว่างคอมมิตนั้นกับคอมมิตแม่ของมัน แล้วสร้างคอมมิตใหม่ที่มีความต่างกลับด้าน เช่น เดิมเพิ่มไฟล์ คอมมิตใหม่จะลบไฟล์ เดิมแก้ข้อความจากสิบเป็นยี่สิบ คอมมิตใหม่จะแก้จากยี่สิบกลับเป็นสิบ

การที่จะใช้คำสั่งนี้ได้อย่างมั่นใจ ต้องเข้าใจก่อนว่า Git จัดเก็บประวัติอย่างไร ทุกคอมมิตใน Git คือข้อมูลบล็อกที่มีตัวระบุเฉพาะ คือชุดตัวอักษรยาวที่เกิดจากการคำนวณเนื้อหาทั้งหมดของคอมมิตนั้น พร้อมชี้ไปยังคอมมิตก่อนหน้า เมื่อเราใช้คำสั่งย้อนกลับ Git จะอ่านคอมมิตที่เราระบุ คำนวณความต่างระหว่างคอมมิตนั้นกับคอมมิตแม่ของมัน แล้วสร้างคอมมิตใหม่ที่มีความต่างกลับด้าน เช่น เดิมเพิ่มไฟล์ คอมมิตใหม่จะลบไฟล์ เดิมแก้ข้อความจากสิบเป็นยี่สิบ คอมมิตใหม่จะแก้จากยี่สิบกลับเป็นสิบ

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

ในทางปฏิบัติ กลไกนี้ยังช่วยให้เราตรวจสอบย้อนหลังได้ เมื่อดูประวัติจะเห็นชัดว่ามีคอมมิตแนะนำฟีเจอร์บางอย่าง แล้วมีคอมมิตอีกตัวที่ยกเลิกมัน พร้อมข้อความอธิบายว่าทำไมจึงยกเลิก ข้อมูลชุดนี้มีค่ามากเวลาทีมต้องวิเคราะห์ว่าเกิดอะไรขึ้นในระบบ ผมเคยเจอกรณีที่ทีมพยายามแก้บั๊กวนไม่จบ เพราะไม่มีใครจำได้ว่าเคยยกเลิกการเปลี่ยนแปลงอะไรไปแล้ว เมื่อดูประวัติที่สะอาดพร้อมข้อความคอมมิตที่ดี ปัญหาประเภทนี้หายไปเกือบทั้งหมด

ตารางเปรียบเทียบวิธีย้อนกลับโค้ดใน Git

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

การใช้งานจริงเริ่มจากรู้จักเลขประจำตัวของคอมมิตที่เราต้องการยกเลิก ใช้คำสั่งแสดงประวัติเพื่อดูรายการคอมมิตล่าสุด แต่ละบรรทัดจะแสดงตัวระบุย่อ

เจ็ดตัวอักษรแรก พร้อมข้อความคอมมิต ถ้าเราต้องการยกเลิกคอมมิตใด เพียงเรียกคำสั่งย้อนกลับตามด้วยตัวระบุนั้น Git จะเปิดโปรแกรมแก้ข้อความให้เราเขียนหมายเหตุ ปกติจะมีข้อความอัตโนมัติว่า "ย้อนกลับคอมมิตเดิม" ต่อท้ายด้วยรายละเอียดของคอมมิตต้นฉบับ แนะนำให้เพิ่มคำอธิบายว่าทำไมจึงยกเลิก เพราะคนในทีมจะขอบคุณคุณภายหลัง

วิธีใช้ git revert ทีละขั้น — ตั้งแต่คอมมิตเดียวจนถึงหลายคอมมิต

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

คำถามที่ผมได้รับบ่อยที่สุดคือ ทำไมต้องมีสองคำสั่ง ทั้งที่ทั้งคู่ทำหน้าที่ย้อนกลับเหมือนกัน ความต่างอยู่ที่วิธีจัดการประวัติ

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

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

git revert กับ git reset ต่างกันอย่างไร — เลือกใช้ให้ถูกสถานการณ์

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

แม้การย้อนกลับด้วยคอมมิตใหม่จะปลอดภัย แต่มีกับดักที่ผมเห็นคนพลาดบ่อย กับดักแรกคือการย้อนกลับคอมมิตที่รวมสาขา ถ้าย้อนกลับคอมมิตรวม

แล้วภายหลังดึงสาขาฟีเจอร์นั้นมารวมใหม่ Git จะคิดว่าคอมมิตเหล่านั้นถูกประมวลผลแล้ว ทำให้การเปลี่ยนแปลงไม่กลับมาตามที่คาด นี่คือปัญหาที่มีชื่อเสียงมากในหมู่นักพัฒนา วิธีแก้ที่ถูกต้องคือหลังย้อนกลับคอมมิตรวม ถ้าต้องการนำฟีเจอร์กลับมาจริง ต้องย้อนกลับคอมมิตที่ย้อนกลับไว้ก่อน หรือสร้างสาขาใหม่จากคอมมิตเดิมแล้วแก้ไขปัญหาที่ทำให้ต้องยกเลิก แล้วจึงรวมเข้ามาใหม่

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

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

ข้อควรระวังและกับดักที่พบบ่อยเวลาย้อนกลับโค้ด

แม้การย้อนกลับด้วยคอมมิตใหม่จะปลอดภัย แต่มีกับดักที่ผมเห็นคนพลาดบ่อย กับดักแรกคือการย้อนกลับคอมมิตที่รวมสาขา ถ้าย้อนกลับคอมมิตรวม แล้วภายหลังดึงสาขาฟีเจอร์นั้นมารวมใหม่ Git จะคิดว่าคอมมิตเหล่านั้นถูกประมวลผลแล้ว ทำให้การเปลี่ยนแปลงไม่กลับมาตามที่คาด นี่คือปัญหาที่มีชื่อเสียงมากในหมู่นักพัฒนา วิธีแก้ที่ถูกต้องคือหลังย้อนกลับคอมมิตรวม ถ้าต้องการนำฟีเจอร์กลับมาจริง ต้องย้อนกลับคอมมิตที่ย้อนกลับไว้ก่อน หรือสร้างสาขาใหม่จากคอมมิตเดิมแล้วแก้ไขปัญหาที่ทำให้ต้องยกเลิก แล้วจึงรวมเข้ามาใหม่

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

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

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

คำถามที่พบบ่อย

git revert คืออะไร และแตกต่างจากการลบประวัติคอมมิตอย่างไร?

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

เมื่อไรควรใช้ git revert และเมื่อไรควรใช้วิธีย้อนกลับแบบเขียนทับ?

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

กลไกภายในของ git revert ทำงานอย่างไร?

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

ทำไมการใช้ git revert จึงสำคัญกับการทำงานเป็นทีม?

เพราะเป็นหัวใจของการทำงานกับทีมที่ต้องการความปลอดภัยระดับสูง เมื่อย้อนการเปลี่ยนแปลงด้วยการเพิ่มประวัติใหม่เข้าไปแทนที่จะลบประวัติเก่าทิ้ง ทุกคนใน

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6