git worktree คือคำสั่งของ Git ซึ่งเป็นระบบควบคุมเวอร์ชันของโค้ดที่นักพัฒนาใช้กันทั่วโลก คำสั่งนี้ช่วยให้เราทำงานหลาย branch (สาขาของโค้ดที่แยกออกไปทำคนละเรื่อง) พร้อมกันได้ โดยแยกแต่ละ branch จาก repo (ที่เก็บโค้ดทั้งโปรเจกต์) เดียวไปไว้คนละโฟลเดอร์ ที่น่าสนใจคือมันเป็นเทคนิคเก่าตั้งแต่ปี 2015 ที่แทบไม่มีใครพูดถึงมาหลายปี แล้วจู่ ๆ ก็กลับมาแรงในยุค AI

แปลง่าย ๆ คืองานหนึ่งค้างอยู่ในโฟลเดอร์เดิมได้ ส่วนอีกงานก็เปิดอีกโฟลเดอร์ทำต่อได้ทันที ไม่ต้องสลับ branch และไม่ต้อง stash (พักงานที่ยังไม่ได้บันทึกไว้ชั่วคราว) เพราะยุคนี้หลายคนเริ่มรัน AI coding agent (โปรแกรม AI ที่ช่วยเขียนโค้ดให้อัตโนมัติ) หลายตัวพร้อมกันในโปรเจกต์เดียว และถ้าไม่มีอะไรกั้น โค้ดที่แต่ละตัวแก้ก็ชนกันเละแน่นอน worktree เลยกลับมาเป็นคำตอบที่พอดีกับปัญหานี้

แก้บั๊กด่วนทีนึง ต้องรื้อทั้งโต๊ะ

ลองนึกภาพสถานการณ์ที่คนเขียนโค้ดเจอบ่อย กำลังทำฟีเจอร์ใหม่ค้างไว้ครึ่งทาง เปิดไฟล์ไว้เต็มจอ editor (โปรแกรมที่ใช้เขียนโค้ด) แล้วพอดีมีบั๊กด่วนโผล่มาที่ branch หลัก ต้องรีบไปแก้ก่อน

แบบเดิมที่ยังไม่มี worktree ขั้นตอนยาวเป็นหางว่าว:

• git stash เก็บงานที่ทำค้างไว้ก่อน
• git checkout main สลับไป branch หลัก แล้ว git pull ดึงโค้ดล่าสุดลงมา
• git checkout -b hotfix-bug แตก branch ใหม่ขึ้นมาไว้แก้บั๊ก
• แก้บั๊กเสร็จก็ commit (บันทึกการแก้) แล้ว push (ส่งโค้ดขึ้นส่วนกลาง) จากนั้นเปิด PR (pull request คำขอรวมโค้ด) รอ merge (รวมเข้ากับ branch หลัก)
• สลับกลับมา branch เดิม แล้ว git stash pop เอางานที่ค้างไว้กลับคืนมา

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

ยิ่งมาถึงยุคนี้ ปัญหายิ่งหนักขึ้น เพราะหลายคนเริ่มอยากรัน AI coding agent หลายตัวพร้อมกัน ให้แต่ละตัวรับงานคนละอย่าง แต่ถ้าปล่อยให้ agent สองตัวแก้ไฟล์อยู่ในโฟลเดอร์เดียวกัน โค้ดก็ทับกันจนพังแน่นอน

worktree แยกแต่ละงานไปคนละโฟลเดอร์

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

ทุกโฟลเดอร์ยังใช้ข้อมูลใน .git ชุดเดียวกันจาก repo เดิม จึงไม่ต้องดาวน์โหลดโปรเจกต์ใหม่ทั้งก้อน เราเปิดแต่ละโฟลเดอร์เป็นหน้าต่าง editor แยกกันได้ และรัน agent แยกกันได้ โดยไม่ไปแตะงานในโฟลเดอร์อื่นเลย

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

สามคำสั่งที่ได้ใช้จริง

สมมติกำลังทำ branch feature-login ค้างอยู่ แล้วมีบั๊กด่วนต้องแก้บน main เริ่มจากคำสั่งเดียว:

git worktree add ../hotfix-workspace -b hotfix-bug main

คำสั่งนี้สร้างโฟลเดอร์ใหม่ชื่อ hotfix-workspace ขึ้นมาวางไว้ข้าง ๆ โปรเจกต์เดิม อิงจาก branch main แล้วสร้าง branch ใหม่ชื่อ hotfix-bug เช็กเอาต์รอไว้ในโฟลเดอร์นั้นให้เสร็จในทีเดียว

จากนั้นเปิดโฟลเดอร์ hotfix-workspace ในหน้าต่าง editor ใหม่ แล้วแก้บั๊กได้เลย หน้าต่าง editor เดิมกับ branch feature-login ยังอยู่เหมือนเดิม ไม่ถูกแตะแม้แต่นิดเดียว พอแก้เสร็จก็ git add . แล้ว git commit กับ git push origin hotfix-bug ตามปกติจากในโฟลเดอร์ใหม่ จากนั้นเปิด PR ไป merge บนเว็บเหมือนที่เคยทำ

พอ merge เสร็จ งานในโฟลเดอร์นั้นก็หมดหน้าที่ กลับมาที่โฟลเดอร์โปรเจกต์หลัก แล้วลบทิ้งด้วยคำสั่งเดียว:

git worktree remove ../hotfix-workspace

worktree ไม่ได้จำกัดอยู่แค่บรรทัดคำสั่ง โปรแกรมเขียนโค้ดยอดนิยมอย่าง Visual Studio Code ก็รองรับ worktree มาในตัวอยู่แล้ว เปิดสลับไปมาระหว่างโฟลเดอร์ worktree ได้จากในโปรแกรมเลย ไม่ต้องพิมพ์คำสั่งเองทุกครั้ง

ทำไมเทคนิคปี 2015 เพิ่งมาแรงตอนนี้

คำถามที่ตามมาคือ ถ้า worktree มีมาตั้งแต่ปี 2015 ทำไมเพิ่งมาฮิตเอาตอนนี้

เหตุผลที่ Cassidy Williams เขียนอธิบายไว้บน GitHub Blog น่าคิดตาม ที่ผ่านมา worktree แทบไม่มีคนรู้จัก เพราะโปรแกรม Git แบบมีหน้าต่างกดปุ่ม (GUI) ส่วนใหญ่ไม่ค่อยรองรับ และคนเขียนโค้ดส่วนใหญ่ก็ทำงานแบบเดิม ๆ คือแตก branch แล้วลงมือทำ จากนั้นเปิด PR เพื่อ merge แล้ววนแบบนี้ไปเรื่อย ๆ

สิ่งที่เปลี่ยนไปคือ AI ทำให้การเขียนโค้ดหลายงานพร้อมกันเกิดขึ้นได้มากกว่ายุคไหน ๆ ทุกวันนี้คนเขียนโค้ดรันหลาย session (รอบการทำงานของ agent หรือ editor) พร้อมกันเป็นเรื่องปกติ และวัฒนธรรมการ "รีวิวโค้ด" ก็สำคัญขึ้นเรื่อย ๆ ไม่แพ้การ "เขียนโค้ด" worktree เข้ามาตอบโจทย์ตรงนี้พอดี เพราะทั้งคนและ agent ทำงานหลายอย่างขนานกันได้โดยไม่ชนกัน

จนตอนนี้ worktree กลายเป็นโหมดเริ่มต้นของ GitHub Copilot app แอปผู้ช่วย AI เขียนโค้ดของ GitHub ไปแล้ว พอเปิดแอปขึ้นมา จะมีเมนูให้เลือกว่าจะรัน session ใหม่ที่ไหน โดยค่าเริ่มต้นคือสร้าง worktree ใหม่ให้เลย คลิกที่ชื่อ session ด้านบนก็เห็นชื่อ worktree ที่แอปสร้างให้ ตำแหน่งโฟลเดอร์ โปรเจกต์ต้นทาง และความเปลี่ยนแปลงที่เกิดขึ้น เครื่องมือ AI coding สมัยใหม่อีกหลายตัวก็ทำแบบเดียวกัน

ตรงนี้มีจุดที่ต้องเข้าใจให้ตรง worktree ไม่ใช่ของเฉพาะ GitHub Copilot และไม่ใช่ฟีเจอร์ที่เพิ่งเกิด มันคือคำสั่งกลางของ Git ที่ใช้กับ Claude Code หรือ AI agent ตัวไหนก็ได้ แค่บทความบน GitHub Blog ที่หยิบเรื่องนี้ขึ้นมาเล่าบังเอิญมาจากฝั่ง GitHub เท่านั้นเอง

worktree ก็มีของที่ต้องแลก

worktree ไม่ใช่ของฟรีที่ได้มาเปล่า ๆ มีอย่างน้อยสี่เรื่องที่ควรรู้ก่อนใช้จริง:

• แต่ละโฟลเดอร์ต้องลง dependency (ไลบรารีที่โปรเจกต์ต้องพึ่ง) ของตัวเอง worktree ใช้ .git ร่วมกันก็จริง แต่ node_modules หรือไลบรารีจาก pip ไม่ได้แชร์ตามไปด้วย ถ้าเปิดหลายโฟลเดอร์ ก็ต้องสั่ง npm install หรือ pip install แยกทุกโฟลเดอร์ พื้นที่ดิสก์เต็มไวกว่าที่คิด
• ต้องลบโฟลเดอร์ worktree เอง ถ้าไม่ลบทิ้งเมื่อเลิกใช้ โฟลเดอร์จะกองสะสมจนรก บางแอปอย่าง GitHub Copilot app จัดการลบให้อัตโนมัติ แต่ถ้าพิมพ์คำสั่งใช้เองผ่านเทอร์มินัล (หน้าต่างพิมพ์คำสั่ง) ก็ต้องลบเอง
• ถ้าสร้างในโฟลเดอร์ repo หลัก ต้องใส่ .gitignore เอง ไม่งั้น Git จะเผลอเก็บโฟลเดอร์ worktree เข้าไปเป็นส่วนหนึ่งของโปรเจกต์ ทางที่ง่ายกว่าคือวางโฟลเดอร์ worktree ไว้นอก repo หลักไปเลย ซึ่งหลายแอปก็ตั้งค่าแบบนั้นให้อยู่แล้ว
• branch เดียวกัน เปิดสอง worktree พร้อมกันไม่ได้ Git กันไว้ไม่ให้ดึง branch เดิมออกมาซ้ำในสองโฟลเดอร์ เพื่อกันข้อมูลพัง

แล้วต้องเปลี่ยนมาใช้ไหม

คำตอบตรงไปตรงมาคือ "แล้วแต่คน" บางคนถนัดวิธีทำงานแบบเดิมที่ใช้ branch กับ stash บางคนย้ายมาใช้ worktree เต็มตัว บางคนก็ใช้ผสมกันทั้งสองแบบตามลักษณะงาน ไม่มีแบบไหนผิด

ที่น่าคิดที่สุดของเรื่องนี้ คือ git worktree แทบไม่ได้เปลี่ยนไปเลยตั้งแต่ปี 2015 สิ่งที่เปลี่ยนคือวิธีที่เราทำงานต่างหาก พอ AI ทำให้เรารันหลายอย่างพร้อมกันได้จริง เครื่องมือที่เคยไม่มีใครเหลียวแลก็กลายเป็นของจำเป็นขึ้นมาเอง

ที่มา: บทความ What are git worktrees, and why should I use them? จาก GitHub Blog โดย Cassidy Williams