Jujutsu Internals vs Git Architecture (เปรียบเทียบการเก็บ Commit-Graph/First-class Conflicts กับ Blob/Tree/Commit/Tag)

ระบบควบคุมเวอร์ชัน (Version Control Systems – VCS) ไม่ได้เป็นเพียงแค่เครื่องมือบันทึกการเปลี่ยนแปลง แต่เป็นโครงสร้างทางสถาปัตยกรรมที่กำหนดวิธีการจัดการเวลาและสถานะของโค้ด การทำความเข้าใจความแตกต่างทางปรัชญาระหว่าง Git และ Jujutsu จึงเป็นสิ่งสำคัญอย่างยิ่งสำหรับสถาปนิกซอฟต์แวร์

ในบทความนี้ เราจะเจาะลึกการเปรียบเทียบเชิงสถาปัตยกรรม โดยเน้นที่การจัดการ Commit Graph และ Conflict Resolution โดยใช้แนวคิดการจำลองโครงสร้างข้อมูลใน PostgreSQL เพื่อให้เห็นภาพความแตกต่างทางเทคนิคอย่างชัดเจน

สถาปัตยกรรมของ Git: Object-Based Snapshot

Git ใช้โมเดลแบบ Object-based ซึ่งมีประสิทธิภาพสูงในการสร้าง Snapshot ของสถานะโปรเจกต์ ณ เวลาใดเวลาหนึ่ง โครงสร้างหลักประกอบด้วย Blob (เนื้อหาไฟล์), Tree (ไดเรกทอรีที่เก็บ Blob ID) และ Commit (Pointer ที่ชี้ไปยัง Tree ID และ Metadata) การจัดการ Conflict ใน Git จึงมักจะเกิดขึ้นในระดับไฟล์ (File-level) ในขั้นตอน Merge หรือ Rebase

หากเราจำลองโครงสร้างนี้ใน PostgreSQL เราจะเห็นการเชื่อมโยงที่เน้นการจับภาพสถานะ (Snapshot) ณ จุดเวลาหนึ่ง:

SQL

-- Git Snapshot Model: Linking Blobs to a single Tree ID
SELECT
    t.tree_id,
    b.blob_id,
    b.filename
FROM
    commits c
JOIN
    trees t ON c.tree_id = t.id
JOIN
    blobs b ON t.blob_id = b.id
WHERE
    c.commit_hash = 'abcdef123456';

สถาปัตยกรรมของ Jujutsu: First-Class Commit Graph

Jujutsu นำเสนอแนวคิดที่ปฏิวัติวงการโดยการมองว่า Commit เป็น &#201CNพลเมืองชั้นหนึ่ง&#201C (First-class citizens) ในกราฟประวัติศาสตร์ (Graph) ไม่ใช่แค่การเป็นจุดสิ้นสุดของสายงาน (Head) การจัดการ Conflict จึงสามารถเกิดขึ้นได้ตั้งแต่ระดับโครงสร้างของ Commit Graph เลย ทำให้การติดตามเส้นทางที่แท้จริงของโค้ดมีความชัดเจนกว่า

ในเชิงสถาปัตยกรรม Jujutsu เน้นการเชื่อมโยงความสัมพันธ์ระหว่าง Commit โดยตรง ซึ่งสามารถจำลองการเดินทางของประวัติศาสตร์ด้วย Recursive CTE ใน PostgreSQL:

SQL

-- Jujutsu Graph Model: Traversing the history path
WITH RECURSIVE history_path AS (
    SELECT commit_id, parent_id, 'Start' AS path_step
    FROM commits WHERE commit_id = 'start_commit'
    UNION ALL
    SELECT c.commit_id, c.parent_id, h.path_step || ' -> ' || c.commit_id
    FROM commits c
JOIN history_path h ON c.parent_id = h.commit_id
) 
SELECT * FROM history_path;

การเปรียบเทียบ Conflict Resolution

ความแตกต่างที่สำคัญที่สุดคือการจัดการ Conflict Jujutsu สามารถระบุ Conflict ได้ในระดับโครงสร้างของ Commit Graph (Structural Conflict) ซึ่งเป็นสิ่งที่ Git ทำได้ยากกว่า เพราะ Git มักจะรอให้ Conflict เกิดขึ้นในระดับไฟล์ (File-level) ในขั้นตอน Merge เท่านั้น

การใช้ PostgreSQL ในการจำลองความซับซ้อนนี้ ทำให้เราเห็นว่า Jujutsu ต้องจัดการกับความสัมพันธ์ (Relationships) มากกว่าแค่การจับภาพ (Snapshots) ซึ่งเป็นข้อได้เปรียบเชิงสถาปัตยกรรมที่สำคัญในการรักษาความสมบูรณ์ของประวัติศาสตร์โค้ดอย่างแท้จริง

บทสรุปสำหรับสถาปนิก

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