weave เป็นเครื่องมือโอเพนซอร์สที่ช่วยให้ระบบจัดการเวอร์ชันโค้ดอย่าง Git รวมโค้ดทีละฟังก์ชัน แทนที่จะเทียบทีละบรรทัดแบบเดิม

ความต่างนี้อาจฟังดูเล็กน้อย จนกว่าคุณจะเริ่มให้ AI coding agent อย่าง Claude Code หรือ Codex ทำงานพร้อมกันหลายตัว โดยแต่ละตัวทำงานบน branch ของตัวเอง

สมมติว่า agent ตัวหนึ่งเพิ่มฟังก์ชัน validateToken อีกตัวเพิ่ม formatDate ทั้งคู่เขียนลงไฟล์เดียวกันโดยไม่ได้แตะโค้ดของกันและกันเลย แต่พอสั่งรวมสอง branch เข้าด้วยกัน Git กลับแจ้งว่าเกิด conflict จนระบบหยุดรวมงานกลางคัน เพื่อรอให้คนมาเลือกเองว่าจะเก็บโค้ดฝั่งไหน

ตัวอย่างนี้มาจากเอกสาร README ของ weave เอง โดยทีมพัฒนาจาก Ataraxy Labs ระบุว่า ปัญหานี้เกิดขึ้นตลอดเวลาเมื่อเราให้ AI agent หลายตัวทำงานร่วมกันในโปรเจกต์เดียว

แม้คุณจะแยกโฟลเดอร์ให้ agent แต่ละตัวด้วย git worktree หรือจัดคิวรวมโค้ดทีละตัวด้วย Claude Code Merge Queue ปัญหานี้ก็ยังไม่หายไป เพราะสุดท้ายแล้วขั้นตอนการรวมโค้ดยังเป็นหน้าที่ของ Git ที่คอยเทียบโค้ดแบบบรรทัดต่อบรรทัดอยู่ดี

weave เข้ามาแก้ปัญหานี้โดยรวมฟังก์ชันที่ไม่เกี่ยวข้องกันให้อัตโนมัติ และจะหยุดให้เราตัดสินใจเฉพาะจุดที่โค้ดขัดแย้งกันจริงๆ พร้อมบอกชัดเจนว่าชนกันที่ฟังก์ชันไหนและเพราะอะไร

Git เทียบทีละบรรทัด จึงมองไม่เห็นว่าเป็นคนละฟังก์ชัน

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

เมื่อทั้งสอง branch ต่างเพิ่มโค้ดลงในตำแหน่งใกล้กันของไฟล์เดียวกัน Git จะมองว่าช่วงบรรทัดนั้นทับซ้อนกันทันที จึงหยุดทำงานแล้วแทรก conflict marker สัญลักษณ์แจ้งจุดขัดแย้งลงในไฟล์:

<<<<<<< HEAD
export function validateToken(token: string): boolean {
  return token.length > 0 && token.startsWith("sk-");
}
=======
export function formatDate(date: Date): string {
  return date.toISOString().split('T')[0];
}
>>>>>>> feature-branch

โค้ดเหนือเส้น ======= คือโค้ดของ branch ที่เราอยู่ตอนนี้ (HEAD) ส่วนโค้ดใต้เส้นมาจาก feature-branch

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

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

weave รวมโค้ดทีละฟังก์ชัน ทีละคลาส และทีละ key

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

กระบวนการเริ่มต้นเหมือนกับ Git ปกติ คือนำโค้ด 3 เวอร์ชันมาเทียบกัน ได้แก่ จุดร่วมก่อนแตก branch (base), โค้ดฝั่งเรา (ours) และโค้ดฝั่งที่จะรวมเข้ามา (theirs)

แต่จุดที่ weave ต่างออกไปคือใช้ Tree-sitter ซึ่งเป็นเครื่องมือแยกโครงสร้างโค้ด มาแตกไฟล์ทั้ง 3 เวอร์ชันออกเป็นโครงสร้างตามไวยากรณ์ แทนที่จะมองเป็นแค่ข้อความธรรมดา

โครงสร้างนี้แบ่งออกเป็นส่วนย่อยๆ เช่น ฟังก์ชันแต่ละตัว คลาส หรือ key แต่ละตัวในไฟล์ JSON ส่วนโค้ดระหว่างนั้น เช่น บรรทัด import หรือบรรทัดว่าง weave ก็จะแยกเก็บไว้อีกส่วนหนึ่ง

จากนั้น weave จะนำส่วนย่อยเดียวกันจากทั้ง 3 เวอร์ชันมาจับคู่กัน โดยดูว่าอยู่ไฟล์ไหน เป็นประเภทอะไร ชื่ออะไร และอยู่ภายใต้อะไร (เช่น เมธอดนี้อยู่ในคลาสใด) ส่วนที่เปลี่ยนชื่อไปแล้ว weave ก็ยังตามเจอ

เมื่อจับคู่โครงสร้างเรียบร้อยแล้ว weave จะตัดสินใจรวมโค้ดทีละส่วนตามกฎต่อไปนี้:

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

สุดท้าย weave จะประกอบไฟล์กลับคืนมาจากชิ้นส่วนที่รวมเรียบร้อยแล้ว โดยเรียงลำดับเนื้อหาตามฝั่ง ours ของเรา

เมื่อย้อนกลับมาดูตัวอย่างข้างต้น validateToken และ formatDate เป็นคนละฟังก์ชันกัน weave จึงรวมโค้ดเข้าด้วยกันได้ทันทีโดยไม่ติด conflict และได้โค้ดทั้งสองฟังก์ชันครบถ้วนในไฟล์

การทำงานของ weave เสถียรและให้ผลลัพธ์แน่นอน ไม่ว่าจะรันกี่ครั้งด้วยไฟล์ชุดเดิมก็ได้ผลเหมือนเดิมเสมอ โดยอ่านโค้ดทั้ง 3 เวอร์ชันแล้วเขียนผลลัพธ์ออกมาเป็นไฟล์เดียว เช่นเดียวกับคำสั่ง git merge-file ของ Git

ด้านล่างนี้คือ 4 สถานการณ์ที่เลือกมาจากตารางเทียบผลใน README ของ weave:

สามกรณีแรกคือ conflict หลอกที่ weave จัดการให้เองโดยอัตโนมัติ ส่วนกรณีสุดท้ายที่แก้ไขชนกันจริงๆ weave ก็ยังหยุดเตือนให้เราตรวจสอบเหมือนเดิม

เมื่อเจอ conflict จริง weave บอกตำแหน่งและสาเหตุชัดเจน

เมื่อเกิด conflict ขึ้นจริงๆ ข้อมูลที่ weave แทรกลงในไฟล์จะให้รายละเอียดมากกว่า marker ของ Git มาก

README ยกตัวอย่างกรณีที่ทั้งสองฝั่งแก้ไขฟังก์ชัน process ไปคนละแบบ ส่วนหัวของ conflict marker จะออกมาแบบนี้:

<<<<<<< ours — function `process` (T, confidence: high)
// refused_by: statement_fold · collision: `    return data.upper()` +1 more

• บรรทัดแรกระบุชัดเจนว่าเป็น function ชื่อ process พร้อมระดับความมั่นใจ (confidence: high)
• บรรทัด refused_by ระบุชื่อกลไกตรวจสอบของ weave ที่ปฏิเสธการรวมโค้ด (ในตัวอย่างคือ statement_fold) พร้อมแสดงบรรทัดโค้ดที่ทั้งสองฝั่งเขียนไม่ตรงกัน

ส่วนกรณีที่ฝั่งหนึ่งแก้ไขแต่อีกฝั่งลบทิ้ง weave ก็จะบอกเหตุผลตรงๆ เช่น function 'validateToken' (modified in ours, deleted in theirs) ทำให้เข้าใจได้ทันที ต่างจาก Git ที่แสดงเป็นข้อความเปรียบเทียบจุดต่างหรือ diff ที่อ่านยาก

นอกจากนี้ weave ยังมี 2 คำสั่งที่ช่วยได้เมื่อเกิด conflict:

• weave explain <file> แสดงรายละเอียดของทุกจุดที่โค้ดชนกันในไฟล์นั้น
• weave check ตรวจสอบความถูกต้องหลังจากเราแก้ conflict เสร็จ โดยเทียบผลลัพธ์กับโค้ดทั้ง 3 เวอร์ชัน ถ้ายังมีข้อผิดพลาดตกค้าง คำสั่งจะแจ้ง error ทันที

สถิติการทดสอบของ weave ที่ต้องดูควบคู่กัน

ผลทดสอบของ weave มีตัวเลข 2 ชุดที่ควรดูควบคู่กัน:

ชุดแรก: การทดสอบจำลองจากทีมผู้พัฒนา ทีมผู้สร้างออกแบบชุดทดสอบไว้ 31 สถานการณ์ ครอบคลุม 7 ภาษาโปรแกรม แบ่งเป็น:

• 29 เคสที่ควรจะรวมโค้ดได้: weave รวมผ่านได้ครบทั้ง 29 เคส ขณะที่ Git รวมผ่านเพียง 15 เคส
• 2 เคสที่โค้ดขัดแย้งกันและไม่ควรผ่าน: ทั้ง weave และ Git หยุดเตือนได้อย่างถูกต้อง (สามารถทดสอบซ้ำเองได้ด้วยคำสั่ง weave bench)

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

ชุดที่สอง: การทดสอบกับประวัติการ merge จาก 5 โปรเจกต์โอเพนซอร์สชื่อดัง ทีมงานนำประวัติการ merge จริงจาก Git, Flask, CPython, Go และ TypeScript มาทดสอบ โดยเลือกมาโปรเจกต์ละ 500 merge คิดเป็นการรวมไฟล์ทั้งหมด 4,971 ครั้ง ผลลัพธ์ที่ได้คือ:

• มี 344 ครั้งที่ weave รวมผ่านได้สำเร็จ ในจุดที่ Git แจ้ง conflict
• แต่ก็มี 86 ครั้งที่ weave กลับหยุดและแจ้งเตือน conflict ทั้งที่ Git รวมผ่านได้

README อธิบายว่า ตัวเลข 86 ครั้งนี้เพิ่มขึ้นจากรุ่นก่อนหน้า ส่วนใหญ่เป็นเพราะในเวอร์ชัน 0.5.3 ทีมงานตั้งใจปรับกฎการตรวจสอบให้รัดกุมขึ้น โดยเลือกหยุดเตือนเมื่อพบว่าทั้งสองฝั่งเพิ่มโค้ดที่ต่างกันจริงพร้อมๆ กัน ซึ่งเวอร์ชันก่อนหน้าอาจรวมให้เงียบๆ นอกจากนี้ยังหยุดรวมในเคสที่อาจทำให้ key ใน JSON ที่เคยลบไปแล้วกลับมาปรากฏใหม่อีกครั้ง

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

สิ่งที่ weave ไม่ได้แก้ให้

แม้ weave จะช่วยลด conflict หลอกได้มาก แต่ก็ยังมีข้อจำกัดสำคัญที่ต้องเข้าใจ:

1. ดูเฉพาะระดับไฟล์ รวมผ่านไม่ได้แปลว่าโค้ดจะทำงานถูกต้อง ตอนรวมโค้ด weave ดูทีละไฟล์ จึงมองไม่เห็นจุดที่โค้ดต่างไฟล์ผูกกันอยู่ ตัวอย่างใน README ระบุว่า ถ้าฝั่งหนึ่งเปลี่ยนชื่อฟังก์ชันใน a.py แต่อีกฝั่งยังเรียกใช้ชื่อฟังก์ชันเดิมใน b.py ทั้งสองไฟล์จะ merge ผ่านฉลุยโดยไม่มี conflict เลย แต่เมื่อนำโปรเจกต์มารันจริง b.py จะทำงานผิดพลาดทันทีเพราะเรียกหาฟังก์ชันที่ไม่มีอยู่แล้ว ปัญหาประเภทนี้จะตรวจพบได้ก็ต่อเมื่อมองภาพรวมทั้งโปรเจกต์ ดังนั้นหลังจากรวมโค้ดเสร็จ การรัน automated test จึงยังเป็นขั้นตอนที่จำเป็นเสมอ

2. ไฟล์บางประเภทที่ weave ตั้งใจข้ามไป ไฟล์ประเภท Vue, Svelte, ERB และ Haskell นั้น weave สามารถอ่านไวยากรณ์ได้ แต่เลือกไม่รวมให้ และจะส่งกลับไปให้ Git รวมด้วยวิธีเดิมเสมอ เนื่องจาก weave มองบล็อก <script> หรือ template ทั้งหมดเป็นก้อนโครงสร้างเดียว ถ้าสองฝั่งเพิ่มฟังก์ชันลงในบล็อกเดียวกัน weave จะแจ้ง conflict โดยไม่จำเป็น หรืออาจแทรก conflict marker ลงไปกลางฟังก์ชันได้

ถ้าคุณพัฒนาเว็บด้วย Vue หรือ Svelte ไฟล์ .vue และ .svelte จะยังคงรวมด้วย Git แบบเดิมเสมอ ส่วนไฟล์ภาษาอื่นๆ ที่รองรับในโปรเจกต์เดียวกัน เช่น .ts หรือ .js ก็ยังใช้ weave ได้ตามปกติโดยไม่ต้องตั้งค่าเพิ่มเติม เพราะคำสั่ง weave setup จะยกเว้นไฟล์ 4 ประเภทนี้ให้อัตโนมัติ

นอกจากนี้ weave ยังส่งไฟล์เหล่านี้กลับไปให้ Git จัดการตามวิธีเดิมเช่นกัน ได้แก่ ไฟล์ที่ใหญ่เกิน 1MB, ไฟล์ binary (เช่น รูปภาพ) และไฟล์ประเภทที่ไม่อยู่ในรายการ 38 ภาษาที่รองรับ (ครอบคลุมตั้งแต่ TypeScript, Python, Go, Rust ไปจนถึง JSON, YAML และ Markdown)

ติดตั้ง weave แล้วใช้งาน Git ได้ตามปกติ

weave เป็นโครงการโอเพนซอร์สภายใต้สัญญาอนุญาตแบบ MIT หรือ Apache 2.0 (เลือกใช้เงื่อนไขใดก็ได้)

วิธีติดตั้งที่สะดวกที่สุดคือติดตั้งผ่าน Homebrew เครื่องมือจัดการแพ็กเกจ:

brew install weave

หรือถ้าต้องการสร้างโปรแกรมขึ้นเองจากซอร์สโค้ด จะต้องมีภาษา Rust ติดตั้งอยู่ในเครื่องก่อน โดยต้องติดตั้งโปรแกรมทั้ง 2 ตัว ได้แก่ weave ที่เป็นเครื่องมือสั่งงานผ่านคอมมานด์ไลน์ และ weave-driver ที่เป็นกลไกหลักที่ Git เรียกใช้ตอนรวมโค้ด ถ้าขาดตัวนี้ไป คำสั่ง weave setup จะทำงานไม่สำเร็จ:

git clone https://github.com/Ataraxy-Labs/weave
cd weave
cargo install --path crates/weave-cli
cargo install --path crates/weave-driver

จากนั้นเข้าไปที่โฟลเดอร์โปรเจกต์หรือ repository ที่จะใช้ weave แล้วเลือกระดับการตั้งค่าที่ต้องการ:

• weave setup เปิดใช้งานกับทั้ง repository โดยจะบันทึกการตั้งค่าลงในไฟล์ .gitattributes ของโปรเจกต์ (แชร์ให้ทั้งทีมใช้งานร่วมกัน)
• weave setup --local ทดลองใช้เฉพาะบนเครื่องของคุณเอง โดยจะบันทึกไว้ใน .git/info/attributes และไม่กระทบกับไฟล์ .gitattributes ของทีม
• weave setup --global ตั้งค่าให้ทุก repository ในเครื่องของคุณใช้ weave เป็นค่าเริ่มต้น

เมื่อตั้งค่าเสร็จแล้ว คุณสามารถใช้คำสั่ง git merge, git rebase และ git cherry-pick ได้ตามปกติ โดย Git จะส่งไฟล์ประเภทที่ weave รองรับไปให้ weave ช่วยรวมโค้ดโดยอัตโนมัติ

การใช้งานร่วมกับ Jujutsu (jj) และ Claude Code

สำหรับคนที่ใช้ Jujutsu (jj) ใน README ของ weave มีตัวอย่างการตั้งค่าให้ jj เรียกใช้ weave-driver มารวมโค้ด และสั่งแก้ conflict ได้ด้วยคำสั่ง jj resolve --tool weave

ส่วนฝั่ง Claude Code สามารถติดตั้ง weave เป็นช่องทางเชื่อมต่อเครื่องมืออย่าง MCP server เพื่อให้ AI agent เรียกใช้เครื่องมือของ weave ได้โดยตรง ด้วยคำสั่ง:

claude mcp add --scope user weave -- weave-mcp

เมื่อเชื่อมต่อแล้ว agent จะสามารถเรียกใช้ weave เพื่อตรวจสอบผลกระทบก่อนรวมโค้ดได้ โดย README แนะนำให้เริ่มจาก:

• weave_findings ใช้ตรวจสอบความเสี่ยงก่อนหรือหลังการรวมโค้ดระหว่างสอง branch
• weave_check ใช้ตรวจสอบความเสี่ยงข้ามไฟล์ (เช่น กรณี a.py และ b.py ที่กล่าวไปข้างต้น) ซึ่ง merge driver ระดับไฟล์ทั่วไปมองไม่เห็น

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

เริ่มทดลองจาก repository เดียวแบบย้อนกลับได้ง่ายๆ

ถ้าคุณมีโปรเจกต์ที่กำลังใช้ AI agent หลายตัวทำงานอยู่ แนะนำให้เริ่มทดลองกับ repository นั้นเฉพาะบนเครื่องของตัวเองก่อน ด้วย 2 คำสั่งนี้:

weave setup --local
weave preview <branch>

(ใส่ชื่อ branch ที่ agent ทำงานเสร็จแล้วแทน <branch>)

คำสั่ง weave preview จะจำลองการ merge ให้ดูโดยยังไม่รวมไฟล์จริง ระบบจะสรุปให้เห็นทีละไฟล์ว่ารวมเองได้กี่ส่วน หรือเกิด conflict กี่จุด พร้อมบอกผลลัพธ์ล่วงหน้าว่าถ้าสั่ง merge จริงจะผ่านหรือไม่

ผลลัพธ์อย่าง unchanged: 2, added-ours: 1, added-theirs: 1 หมายถึง มี 2 ส่วนที่ไม่มีใครแก้ ฝั่งเราเพิ่ม 1 ส่วน และฝั่งที่รวมเข้ามาเพิ่มอีก 1 ส่วน

ถ้าผลการจำลองออกมาเรียบร้อยดี คุณก็สั่ง merge ได้ตามปกติ แต่ถ้าลองแล้วรู้สึกไม่ถูกใจ ก็แค่สั่ง weave unsetup แล้ว repository จะกลับไปใช้วิธีรวมโค้ดแบบเดิมของ Git

เวลาของนักพัฒนาควรหมดไปกับการตัดสินใจในจุดที่ตรรกะของโค้ดขัดแย้งกันจริงๆ ไม่ใช่มานั่งแก้ conflict หลอกๆ เพียงเพราะโค้ดสองส่วนบังเอิญเขียนอยู่บรรทัดติดกัน

ที่มา: โปรเจกต์ weave บน GitHub