Worktrees นั้นสร้างง่ายและลืมง่าย คุณสร้างมันขึ้นมาเพื่อให้ agent ทำงานบน branch แบบแยกส่วน agent ทำงานเสร็จ คุณตรวจสอบ diff แล้วไดเรกทอรีก็แค่นั่งอยู่ตรงนั้น หนึ่งสัปดาห์ต่อมา git worktree list เลื่อนพ้นหน้าจอ du -sh บน repo อ่านค่าได้สิบสองกิกะไบต์ และสามในไดเรกทอรีเหล่านั้นชี้ไปที่ branch ที่ถูก merge และลบไปหลายวันแล้ว ไม่มีใครเลือกที่จะเก็บมันไว้ พวกมันสะสมเพราะการสร้างเป็นเพียงคำสั่ง แต่การล้างเป็นงานน่าเบื่อ
นี่คือส่วนหนึ่งของการทำงานแบบขนานของ agent ที่ไม่มีใครเตือนคุณ กลไกการแยกส่วนพื้นฐานมีเอกสารอธิบายไว้ดีแล้ว คู่มือของเราเกี่ยวกับ git worktrees สำหรับ AI coding agents ครอบคลุมกลไกการสร้างและการแตก branch อย่างละเอียด วงจรชีวิตหลังจาก “เสร็จ” คือจุดที่ความเจ็บปวดอยู่ และมันแย่ลงอย่างรวดเร็วเมื่อสิ่งที่สร้าง worktree คือ agent ที่สามารถเปิดได้ห้าอันในหนึ่งนาทีและไม่มีสัญชาตญาณในการจัดเก็บ บทความนี้เกี่ยวกับครึ่งหลังนั้น: วินัยในการล้าง คำสั่งที่แน่นอน โหมดความล้มเหลวที่รออยู่ในแต่ละขั้นตอน และจุดที่สคริปต์ที่เขียนเองเริ่มไม่เพียงพอ
Sharkly เป็นหนึ่งคำตอบสำหรับปัญหา “ใครจะล้าง” โดยมันรันทุก Task ใน worktree ของตัวเองและปฏิบัติต่อ worktree นั้นเป็นส่วนหนึ่งของวงจรชีวิตของ Task แทนที่จะเป็นไดเรกทอรีที่คุณต้องจำ เราจะไปถึงตรงนั้น ก่อนอื่น กลไก เพราะคุณควรเข้าใจเวอร์ชัน manual ก่อนที่คุณจะตัดสินใจเลิกทำด้วยมือ
สรุปสั้น ๆ (TL;DR)
git worktree คือไดเรกทอรีทำงานตัวที่สองที่เชื่อมโยงกับ repository หนึ่ง ๆ โดยมี branch, index และ HEAD ของตัวเอง Agent ทำให้พวกมันสะสมเพราะแต่ละรอบต้องการการแยกส่วนและไม่มีตัวไหนเก็บกวาดตามหลังตัวเอง ขั้นตอนการล้างมีสี่คำสั่ง: git worktree list เพื่อดูว่ามีอะไรอยู่ git worktree remove เพื่อลบอันที่เสร็จแล้ว git worktree prune เพื่อล้าง metadata ที่ค้างอยู่ และ git worktree lock เพื่อปกป้องอันที่คุณต้องการเก็บไว้ แต่ละคำสั่งมีโหมดความล้มเหลวที่ทิ้งไดเรกทอรีกำพร้า งานที่สูญหาย หรือ branch ที่ถูกล็อกไว้ หากคุณข้ามขั้นตอนใดขั้นตอนหนึ่ง เวอร์ชัน manual ใช้ได้กับ worktree ไม่กี่อัน เมื่อเกินกว่านั้น ให้ผูกแต่ละ worktree กับบันทึกงาน (task record) เพื่อให้การล้างมีเจ้าของ ซึ่งเป็นสิ่งที่ Sharkly ทำโดยอัตโนมัติ
ทำไม worktree ถึงสะสมเร็วขึ้นเมื่อใช้ agent
worktree มีวงจรชีวิตที่คนจัดการได้ตามธรรมชาติ: คุณสร้างมัน คุณทำงาน คุณ merge คุณลบมัน ขั้นตอนการลบพึ่งพาการจดจำของมนุษย์ Agent ทำลายสมมติฐานนั้นในสองทิศทางพร้อมกัน
อย่างแรก ปริมาณ นักพัฒนาหนึ่งคนที่รัน agent สี่ตัวพร้อมกันกำลังสร้าง worktree สี่อันต่อชั่วโมง ไม่ใช่วันละหนึ่งอัน โพสต์ของเราเกี่ยวกับ การรัน Claude Code agents หลายตัวพร้อมกัน อธิบายว่าทำไมจำนวนนั้นถึงเพิ่มขึ้นอย่างรวดเร็ว อย่างที่สอง ไม่มีสัญชาตญาณในการล้าง Agent อ่านงาน ทำงาน เขียนผลลัพธ์ แล้วหยุด มันไม่คิดว่า “branch ถูก merge แล้ว ดังนั้นไดเรกทอรีนี้ไม่มีประโยชน์แล้ว” ดังนั้นไดเรกทอรีจึงอยู่รอดเกินประโยชน์ของตัวเอง และผู้รอดชีวิตคือปัญหา: checkout ที่ค้างบน branch ที่ถูกลบ การทดลองที่ทำค้างไว้ที่ agent ทิ้งไว้ และ node_modules ซ้ำ ๆ ที่กินดิสก์ในทุกอัน
ค่าใช้จ่ายไม่ใช่เรื่องนามธรรม worktree แต่ละอันคือ checkout เต็มรูปแบบบวกกับสิ่งที่ agent ติดตั้งเข้าไป สิบ worktree บน repo JavaScript ขนาดกลางคือ node_modules สิบไดเรกทอรี ดิสก์เต็ม git status ช้าลงทั่วทั้งชุด และคนถัดไปที่รัน git worktree list ไม่สามารถบอกได้ว่าไดเรกทอรีไหนใช้งานอยู่และไดเรกทอรีไหนเป็นเศษซาก
ขั้นตอนการล้าง ทีละขั้น
นี่คือวงจรชีวิตทั้งหมดในสี่คำสั่ง รันตามลำดับนี้แล้วโหมดความล้มเหลวจะปิดอยู่
ดูว่ามีอะไรอยู่ เริ่มการล้างทุกครั้งที่นี่:
git worktree list
# /repo a1b2c3d [main]
# /repo-auth-refactor 4d5e6f7 [auth-refactor]
# /repo-fix-logging 8g9h0i1 [fix-logging]
โหมดความล้มเหลวถ้าคุณข้ามมัน: คุณลบไดเรกทอรีผิด Agent สองตัวบน branch ที่ตั้งชื่อคล้ายกันสร้าง path worktree ที่ตั้งชื่อคล้ายกัน และการลบอันที่ใช้งานอยู่ทำให้คุณเสียงานที่ยังไม่ commit อ่านรายการก่อนที่คุณจะแตะต้องอะไร
ลบอันที่เสร็จแล้ว เมื่อ branch ของ worktree ถูก merge และคุณยืนยันว่าไม่มีอะไรค้างอยู่ในนั้น:
git worktree remove /repo-fix-logging
โหมดความล้มเหลว: remove จะปฏิเสธถ้า worktree มีการเปลี่ยนแปลงที่ยังไม่ commit หรือไฟล์ที่ยังไม่ track ซึ่งเป็นค่าเริ่มต้นที่ปลอดภัย การเคลื่อนไหวที่ไม่ปลอดภัยคือการเอื้อมไปหยิบ --force เพื่อให้ error หายไป การ force บน worktree ที่สกปรกจะลบงานจริงที่ agent ผลิตแต่ไม่เคย commit ถ้า remove บ่น ให้ไปดูไดเรกทอรีก่อน คำบ่นมักถูกต้อง
ล้าง metadata ที่ค้างอยู่ ถ้าไดเรกทอรี worktree ถูกลบด้วย rm -rf แทนที่จะเป็น git worktree remove git ยังคงเก็บบันทึกการดูแลไว้ นั่นคือ orphan แบบคลาสสิก:
git worktree prune
git worktree prune --dry-run # preview first
โหมดความล้มเหลว: การข้าม prune จะทิ้งรายการผีใน git worktree list และที่แย่กว่านั้น git อาจปฏิเสธที่จะใช้ branch ซ้ำที่มันคิดว่ายังถูก checkout อยู่ที่ไหนสักแห่ง prune ล้างการบันทึกบัญชี รัน --dry-run ก่อนเพื่อให้คุณเห็นว่ามันจะทิ้งอะไรก่อนที่มันจะทิ้ง เอกสาร git worktree อธิบายอย่างชัดเจนว่า prune ถือว่าอะไรค้างอยู่
ล็อกอันที่คุณต้องการเก็บไว้ worktree บนไดรฟ์ภายนอกที่ช้า หรืออันที่ถือการทดลองระยะยาว ไม่ควรถูก prune โดยสคริปต์ล้างที่ก้าวร้าว:
git worktree lock /repo-experiment --reason "release repro, keep until 2.0 ships"
โหมดความล้มเหลว: หากไม่มี lock งานล้างตอนกลางคืนที่ prune อะไรก็ตามที่ “ค้าง” อาจลบ worktree ที่คุณจงใจพักไว้ lock บวกกับสตริงเหตุผลคือความแตกต่างระหว่างสคริปต์ล้างที่คุณไว้วางใจและอันที่คุณปิดใช้หลังจากมันกินอะไรสำคัญเข้าไป
จุดที่สคริปต์ล้างเริ่มขยายไม่ได้
คุณสามารถทำให้ทั้งสี่ขั้นตอนเป็นอัตโนมัติได้ cron job ที่แสดงรายการ worktree ตรวจสอบแต่ละ branch เทียบกับประวัติที่ merge แล้ว และลบอันที่ merge แล้วคือ shell สามสิบบรรทัด มันได้ผล และสำหรับนักพัฒนาคนเดียวที่รัน agent ไม่กี่ตัวก็เพียงพอ ใช้สคริปต์เมื่อจำนวน worktree มีน้อยและมีคนเดียวที่เป็นเจ้าของ repository
มันหยุดขยายที่การตัดสินใจ ไม่ใช่ปริมาณงาน สคริปต์สามารถบอกได้ว่า branch ถูก merge แล้ว มันไม่สามารถบอกได้ว่า worktree ถืองานที่ยังไม่ commit ของ agent ที่คุณยังไม่ได้ตรวจสอบ หรือว่า branch ที่ “ค้าง” จริง ๆ แล้วเป็นงานที่หยุดชั่วคราวซึ่งมีคนตั้งใจจะกลับมาทำต่อ ในวินาทีที่การล้างต้องรู้เจตนาของ worktree กฎที่เห็นแค่สถานะ git จะลบอะไรที่สำคัญไปในที่สุด เพดานอีกอย่างคือการประสานงาน: บนเครื่องที่ใช้ร่วมกัน สคริปต์ล้างของคนหนึ่งไม่รู้ว่า agent ของอีกคนกำลังทำอะไร และ “อันนี้ปลอดภัยที่จะลบไหม” จะไม่สามารถตอบได้จาก git worktree list เพียงอย่างเดียว สำหรับเพิ่มเติมเกี่ยวกับปัญหาการใช้เครื่องร่วมกัน ดูบทสรุปของเราเกี่ยวกับ เครื่องมือสำหรับจัดการ AI coding agents แบบขนาน
สิ่งที่ task board เพิ่มเข้ามา
วิธีแก้คือให้ worktree ทุกอันมีเจ้าของที่อยู่ได้นานกว่า session ของ shell ผูกแต่ละ worktree กับบันทึกงาน และการล้างก็ไม่ใช่ “ไดเรกทอรีไหนดูค้าง” อีกต่อไป แต่กลายเป็น “งานไหนเสร็จและตรวจสอบแล้ว”
นี่คือเลเยอร์ที่ Sharkly ตั้งอยู่ คุณมี coding agents อยู่แล้ว Sharkly เปลี่ยนพวกมันให้เป็นทีมโดยทำให้แต่ละรอบเป็น Task เมื่อ Task เริ่ม บริการภายในเครื่องบน Computer ที่เชื่อมต่อจะเตรียม worktree ที่แยกส่วนไว้ให้ เมื่อผลลัพธ์ของ Task กลับมาให้ตรวจสอบและมีคนยอมรับ วงจรชีวิตของ worktree ก็สิ้นสุดพร้อมกับ Task แทนที่จะคงอยู่เป็นไดเรกทอรีที่ไม่มีใครจำ คำถามเรื่องการล้างมีคำตอบเพราะ worktree ไม่เคยเป็นนิรนาม
การแบ่งงานยังคงซื่อสัตย์ Agent รับงาน ทำงานใน worktree ที่แยกส่วน รันการทดสอบ และส่ง diff กลับ คนกำหนดทิศทางและตัดสินใจขั้นตอน merge และ release Sharkly ไม่ใช่เครื่องแทนที่ Claude Code, Codex หรือคำสั่ง git ข้างต้น แต่มันเพิ่มบันทึกที่แชร์ร่วมกันเพื่อให้การแยกส่วน ความคืบหน้า ผลลัพธ์ และการล้างยังคงมองเห็นได้ตั้งแต่คำขอจนถึง release แทนที่จะกระจัดกระจายไปทั่วเทอร์มินัล ถ้าคุณรัน agent ตัวเดียวและล้างด้วยมือใช้เวลาสิบวินาที คุณยังไม่จำเป็นต้องใช้สิ่งนี้ เมื่อรายการ worktree เลื่อนพ้นหน้าจอ ปัญหาการจัดการคือปัญหาจริง และบันทึกของเราเกี่ยวกับ การรักษามนุษย์ไว้ในลูปตลอดการรัน agent ครอบคลุมด้านการตรวจสอบของมัน
เช็กลิสต์ที่คุณรันได้วันนี้
รันขั้นตอนนี้บน repo ใดก็ตามที่ agent ทำงานอยู่:
git worktree listและอ่านให้ครบก่อนลบอะไร- สำหรับ worktree ที่เสร็จแล้วแต่ละอัน: ยืนยันว่า branch ถูก merge แล้ว ตรวจสอบว่าไดเรกทอรีสะอาด แล้ว
git worktree remove(ห้ามใช้--forceกับ tree ที่สกปรกเด็ดขาด) git worktree prune --dry-runตรวจสอบ แล้วgit worktree pruneเพื่อล้าง metadata ที่เป็น orphangit worktree lockworktree ใดก็ตามที่คุณตั้งใจเก็บไว้ พร้อมสตริงเหตุผล- ตรวจสอบดิสก์:
du -shทั่วทั้งชุด worktree และลบ dependency ที่ติดตั้งซ้ำจาก tree ที่ตายแล้ว - ถ้าคุณทำสิ่งนี้มากกว่าวันละครั้ง หยุดเขียนสคริปต์ล้าง แล้วให้เจ้าของ Task แก่แต่ละ worktree แทน
คุณสามารถเก็บสี่คำสั่งไว้และรันด้วยมือ หรือ รัน coding agents ที่คุณมีอยู่ผ่าน Sharkly เพื่อให้ worktree ถูกสร้าง ติดตาม และปลดระวางพร้อมกับ Task ที่มันสังกัดอยู่
