يعمل Worktree بشكل أفضل كدليل تنفيذ مؤقت

في الفترة الأخيرة، كان الاستخدام الشائع هو إعداد worktree أولاً، ثم فتح Codex / Claude Code داخل ذلك الدليل. لأنه في النماذج المبكرة، لم تكن سياقات الذاكرة والاستيعاب مستقرة بما يكفي، فإذا سمحت لها بإنشاء worktree مباشرة في مساحة العمل الرئيسية، فسيكون من السهل أن تخلط بين الدليل الحالي و الدليل الذي أنشأه الـ worktree بعد ضغط السياق، مما يؤدي إلى تشويش الأمور في النهاية.
لكن لهذا الأسلوب أيضًا جانب سلبي، وهو أنه بمرور الوقت، يبدأ العمل بـ worktree كمساحة عمل دائمة. المشكلة أن الـ worktree مرتبط أصلاً بالفرع، ومع مرور الوقت، ستواجه حتمًا مشاكل مثل التبديل بين الفروع، ومزامنة الفروع، وتنظيف الفروع، وغيرها من المتاعب الإضافية.
الفرق بين الـ Worktree والنسخة المستقلة من الـ clone، كثير من الناس لا يميزونه بشكل واضح. فمزاياه ليست مجرد "دليل إضافي"، بل هو في جوهره نفس الـ repo، يشارك في قاعدة بيانات الـ git objects، وتكلفة نسخه منخفضة، ولا يحتاج إلى إعادة تنزيل البيانات عبر الشبكة. وهذا مفيد جدًا للمستودعات الكبيرة. لذلك، إذا كنت تريد فقط إنشاء دليل مؤقت للتنفيذ المتوازي، فإن الـ worktree مناسب جدًا. فقط عندما تحتاج إلى قاعدة بيانات objects مستقلة تمامًا، مثل الحاجة إلى ربطها بـ Docker أو بيئة افتراضية، فإن الـ local clone يكون أكثر ملاءمة.
على الأقل بالنسبة لـ Codex / Claude Code الآن، لم تعد هذه المشكلة بالغة الخطورة. أنا الآن أميل أكثر للعمل مباشرة في الدليل الرئيسي، ودعها تنشئ الـ worktree حسب الحاجة، ثم بعد التعديلات، تدمج التغييرات وتعيد حذف الـ worktree. هذا يتوافق أكثر مع الهدف الأصلي للـ worktree: دليل مؤقت منخفض التكلفة للتنفيذ، وليس مساحة عمل ثانية دائمة.
وأخيرًا، خطوة أبعد، أنا الآن أجرّب طريقة تتضمن إدارة مساحة عمل عالمية، حيث يتم فتح جميع مشاريع Codex في هذا الدليل، وتقوم هي بإدارة عمليات النسخ والـ worktree وفقًا للقواعد. هذا يسهل الحفاظ على الذاكرة العامة متصلة، وإذا كانت هناك حاجة لتعديل عدة مشاريع في آن واحد، فهي تعرف كيف تنجز التعديلات واحدة تلو الأخرى، ثم تجري الاختبارات المشتركة.