วิธีอ่านผลลัพธ์ Diff: ทำความเข้าใจไฟล์ Patch และการเปลี่ยนแปลง

วิธีอ่านผลลัพธ์ Diff: ทำความเข้าใจไฟล์ Patch และการเปลี่ยนแปลง

ผลลัพธ์ diff เป็นภาษาสากลของระบบควบคุมเวอร์ชัน นักพัฒนาทุกคนพบผลลัพธ์ diff เป็นประจำ — ระหว่างการตรวจสอบโค้ด เมื่อแก้ไข merge conflicts หรือเมื่อใช้ patch จากการมีส่วนร่วมของโอเพนซอร์ส แต่นักพัฒนาหลายคนไม่เคยเรียนรู้ที่จะอ่านผลลัพธ์ diff อย่างมีประสิทธิภาพ

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

ผลลัพธ์ Diff คืออะไร?

ผลลัพธ์ diff คือการแสดงความแตกต่างระหว่างสองไฟล์หรือชุดของไฟล์อย่างมีโครงสร้าง ยูทิลิตี diff ที่สร้างโดย Douglas McIlroy ที่ Bell Labs ในทศวรรษ 1970 ยังคงเป็นรากฐานของ Git, Mercurial และระบบควบคุมเวอร์ชันอื่นๆ ส่วนใหญ่

เมื่อคุณรัน git diff หรือคำสั่ง diff ใดๆ ผลลัพธ์จะแสดงอย่างแม่นยำว่าอะไรเปลี่ยนไป ที่ไหนที่เปลี่ยน และเปลี่ยนอย่างไร — ในรูปแบบที่ทั้งมนุษย์และเครื่องจักรสามารถอ่านได้

ทำความเข้าใจรูปแบบ Unified Diff

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

กายวิภาคของส่วนหัว Hunk

ทุก hunk เริ่มต้นด้วยส่วนหัวที่มีลักษณะดังนี้:

@@ -start,count +start,count @@

มาแยกส่วนนี้:

| ส่วน | ความหมาย | |------|---------| | @@ | ตัวคั่นที่ทำเครื่องหมายจุดเริ่มต้นของ hunk | | -3,7 | ในไฟล์ต้นฉบับ hunk นี้เริ่มที่บรรทัด 3 และครอบคลุม 7 บรรทัด | | +3,8 | ในไฟล์ใหม่ hunk นี้เริ่มที่บรรทัด 3 และครอบคลุม 8 บรรทัด | | @@ | ตัวคั่นปิด |

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

บรรทัดใน Hunk

แต่ละบรรทัดภายใน hunk นำหน้าด้วยอักขระเดี่ยว:

 บรรทัดบริบท (ไม่เปลี่ยนแปลง)
-บรรทัดที่ถูกลบ    (มีอยู่ในไฟล์เก่า ไม่อยู่ในไฟล์ใหม่)
+บรรทัดที่เพิ่ม    (มีอยู่ในไฟล์ใหม่ ไม่อยู่ในไฟล์เก่า)

• บรรทัดบริบท ขึ้นต้นด้วยช่องว่าง เหมือนกันในทั้งสองเวอร์ชันและให้จุดอ้างอิง
• บรรทัดที่ถูกลบ ขึ้นต้นด้วยเครื่องหมายลบ (-) มีอยู่ในไฟล์เก่าแต่ถูกลบออก
• บรรทัดที่เพิ่ม ขึ้นต้นด้วยเครื่องหมายบวก (+) เป็นของใหม่ในไฟล์ที่เปลี่ยนแปลง

ตัวอย่างเชิงปฏิบัติ

นี่คือ diff ที่แสดงฟังก์ชันที่ถูกแก้ไข:

@@ -5,7 +5,9 @@
 def greet(name):
-    print("Hello, " + name)
-    print("Welcome!")
+    message = f"Hello, {name}!"
+    print(message)
+    print("We are glad to see you.")
+
     if name == "admin":
         print("You have admin privileges.")

การอ่าน diff นี้:

• เวอร์ชันเก่าพิมพ์ "Hello, " บวกกับชื่อ แล้วตามด้วย "Welcome!"
• เวอร์ชันใหม่สร้างสตริงข้อความที่จัดรูปแบบ พิมพ์มัน เพิ่มบรรทัดทักทายพิเศษ และคงการตรวจสอบ admin ไว้ไม่เปลี่ยนแปลง
• สองบรรทัดถูกลบ (บรรทัด -) สามบรรทัดถูกเพิ่ม (บรรทัด +) และบรรทัด + ว่างรักษาบรรทัดว่างไว้เพื่อความสามารถในการอ่าน

ไฟล์ Patch: Diff ที่คุณสามารถนำไปใช้ได้

ไฟล์ patch เป็นเพียง diff ที่บันทึกลงในไฟล์ — โดยทั่วไปมีนามสกุล .patch หรือ .diff ไฟล์ patch ทำหน้าที่เป็นวิธีพกพาในการแบ่งปันการเปลี่ยนแปลงโดยไม่ต้องแบ่งปันโค้ดเบสทั้งหมด

การสร้าง Patch

ใช้ Git สร้าง patch จากคอมมิตล่าสุดของคุณ:

git format-patch HEAD~1

หรือสร้าง patch จากการเปลี่ยนแปลงที่ยังไม่ได้คอมมิต:

git diff > my-changes.patch

การใช้ Patch

ใช้ patch กับที่เก็บเป้าหมาย:

git apply my-changes.patch

หรือใช้คำสั่ง patch แบบคลาสสิก:

patch -p1 < my-changes.patch

แฟล็ก -p1 ตัดส่วนประกอบไดเรกทอรีแรกออกจากพาธไฟล์ ซึ่งรองรับความแตกต่างในโครงสร้างไดเรกทอรีระหว่างผู้สร้าง patch และผู้นำไปใช้

รูปแบบผลลัพธ์ Diff ทั่วไป

นอกเหนือจาก unified diff คุณอาจพบรูปแบบเหล่านี้:

Normal Diff

ผลลัพธ์เริ่มต้นของคำสั่ง diff ดั้งเดิม การเปลี่ยนแปลงแสดงเป็นคำสั่งให้เปลี่ยนแปลง เพิ่ม หรือลบบรรทัดโดยใช้คำสั่งเช่น a (append), c (change) และ d (delete)

3c3
< Hello world
---
> Hello beautiful world

Context Diff

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

Side-by-Side Diff

ไม่ใช่รูปแบบไฟล์เดี่ยว — แต่แสดงสองคอลัมน์เคียงข้างกันแทน พบบ่อยในเครื่องมือ diff แบบกราฟิกและ diff checker ออนไลน์

การอ่านผลลัพธ์ Diff ในการตรวจสอบโค้ด

เมื่อตรวจสอบ pull request ให้โฟกัสที่องค์ประกอบเหล่านี้:

1. ส่วนหัว hunk: มันบอกคุณว่าไฟล์และฟังก์ชันใดได้รับผลกระทบ
2. อัตราส่วนของบรรทัดที่เพิ่มต่อบรรทัดที่ลบ: การเปลี่ยนแปลงจำนวนมากในไฟล์สำคัญสมควรได้รับการใส่ใจมากขึ้น
3. บรรทัดบริบท: มันแสดงตรรกะโดยรอบ ช่วยให้คุณประเมินว่าการเปลี่ยนแปลงถูกต้องหรือไม่
4. การเปลี่ยนแปลงเฉพาะช่องว่าง: เครื่องมือ diff หลายตัวเน้นสิ่งเหล่านี้แตกต่างกัน เพราะมันอาจทำให้การตรวจสอบรกได้

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตีความ Diff

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

การเข้าใจผลลัพธ์ diff เป็นทักษะพื้นฐานสำหรับการพัฒนาร่วมกัน เมื่อคุณคุ้นเคยกับการอ่าน diff คุณจะนำทางการตรวจสอบโค้ด merge conflicts และไฟล์ patch ด้วยความมั่นใจที่มากขึ้น