كيفية استخدام Git Worktrees مع وكلاء البرمجة بالذكاء الاصطناعي

وجّه وكيلَي برمجة بالذكاء الاصطناعي إلى نفس الـ checkout، وسينتهي بهما المطاف إلى إهدار بعد الظهر كاملًا. أحدهما يعيد كتابة ملف يعدّله الآخر في تلك اللحظة. أحدهما يبدّل الفرع من تحت قدمي الآخر. وكلاهما يشغّل npm install على نفس node_modules، فيترك لك ملف قفل لم يكتبه أحد. الفشل يبقى صامتًا حتى ينفجر فجأة، وعندها تجد نفسك تفتّش في فوضى لا يقدر أي من الوكيلين على تفسيرها.

تُعدّ worktrees في Git الحل القياسي لهذه المشكلة. فـ worktree يمنح كل وكيل دليل عمل خاصًا به وفرعًا مسحوبًا خاصًا به فوق مستودع واحد مشترك، فتتوقف التصادمات في العمل المتوازي. يستعرض هذا الدليل الأوامر الحقيقية، والمزالق التي تؤلمك عمليًا، وانضباط التنظيف الذي لا يخبرك به أحد. ثم يوضّح أين تتوقف سكربتات worktree المكتوبة يدويًا عن التوسع، وكيف تشغّل Sharkly كل مهمة في worktree خاص بها تلقائيًا، بحيث تعود النتائج إلى سجل واحد مشترك بدلًا من أن تتشتت بين النوافذ الطرفية.

إذا كنت تشغّل وكيلًا واحدًا، فلست بحاجة إلى أي من هذا بعد. لكن بمجرد أن تشغّل اثنين، يصبح العزل ضرورة لا خيارًا.

باختصار

worktree في Git هو دليل عمل ثانٍ مرتبط بالمستودع نفسه، وله فرعه وفهرسه الخاصان. امنح كل وكيل برمجة بالذكاء الاصطناعي worktree خاصًا به، فيستطيع التعديل والبناء والاختبار بالتوازي دون أن يطمس عمل الآخر أو يتنازع معه على الفرع الحالي. الأوامر بسيطة، لكن التكلفة التشغيلية (التثبيتات لكل worktree، والتنظيف، والقرص، والتنسيق) هي ما يتضخم. وتدير Sharkly هذه التكلفة عبر تحضير worktree معزول لكل مهمة تلقائيًا، وإعادة كل نتيجة إلى المهمة للمراجعة.

لماذا لا يستطيع checkout واحد احتواء وكيلين

يحتوي أي checkout عادي في git على دليل عمل واحد وفهرس واحد وHEAD واحد بالضبط. وهذا لا بأس به لشخص واحد يؤدي مهمة واحدة. لكنه ينهار في اللحظة التي يعمل فيها وكيلان في وقت واحد، لأن هذه الثلاثة كلها حالة مشتركة.

تخيّل وكيلين على المستودع نفسه. الوكيل A يعيد هيكلة وحدة المصادقة على فرع اسمه auth-refactor. والوكيل B مطلوب منه إصلاح خطأ في التسجيل، فيشغّل git checkout -b fix-logging. هذا الأمر الوحيد ينقل HEAD في الـ checkout بأكمله. وتصبح تغييرات الوكيل A غير المُودَعة جالسة فوق الفرع الخطأ، فيسقط إيداعه التالي في المكان الخطأ، ويبدأ بناؤه بالفشل لأسباب سيقضي عشرين دقيقة في «تصحيحها». لم ينهَر شيء. الحالة فقط سارت في الاتجاه الخطأ بهدوء.

والأمر يزداد سوءًا مع الملفات. كلا الوكيلين يتشاركان دليل عمل واحدًا، فعندما يعيد الوكيل B توليد ملف إعدادات أو يشغّل منسّق الكود مجددًا، تُمحى تعديلات الوكيل A المفتوحة من القرص. لا يحتفظ وكلاء البرمجة بنموذج ذهني يقول «الآخر منشغل بأمر ما الآن». يقرأون الملف، ويتصرفون، ويكتبونه مرة أخرى. كاتبان، ملف واحد، بلا قفل. فتحصل على مشكلة فقدان التحديث الكلاسيكية، إلا أن الكاتبين هنا مستقلان وسريعان.

هذا هو الألم الذي تظل الكلمة المفتاحية «git worktrees» تظهر بسببه. لا يبحث الناس عن worktrees لأن التفريع مثير للاهتمام. بل يبحثون لأنهم حاولوا تشغيل الوكلاء بالتوازي فاحترقوا. إن كنت منهم، فجانب التنفيذ المتوازي مشروح بعمق في دليلنا حول تشغيل عدة وكلاء Claude Code بالتوازي؛ أما هذا المقال فهو البدائية العازلة الكامنة تحته.

ما هو git worktree فعليًا

هذا هو التعريف الرسمي، وهو الجدير بالحفظ:

worktree في git هو دليل عمل إضافي مرتبط بالمستودع نفسه، وله فرعه المسحوب وفهرسه وHEAD الخاص به، ويتشارك قاعدة كائنات واحدة.

هذه العبارة الأخيرة هي الحيلة كلها. الـ worktree ليس نسخة مستنسخة. فالاستنساخ يضاعف مخزن الكائنات بأكمله: كل إيداع، وكل blob، وكل وسم يُنسخ إلى .git ثانٍ. أما الـ worktrees فتتشارك مخزن كائنات واحدًا وتضيف فقط دليل عمل ثانيًا خفيفًا. وتظهر إيداعاتك من كل worktree بمجرد حدوثها، لأن هناك تاريخًا واحدًا فقط في العمق. وما يختلف بين worktree وآخر هو الـ checkout: أي فرع مسحوب، وما هو مُجهَّز للإيداع، وما هو معدَّل على القرص.

وبالنسبة للوكلاء، ينطبق ذلك على المشكلة بانسيابية تامة. كل وكيل يحصل على worktree. وكل worktree له فرعه وملفاته. فلا يستطيعون طمس عمل بعضهم لأنهم حرفيًا في أدلة مختلفة، ولا يستطيعون انتزاع الفرع من تحت أقدام بعضهم لأن كل worktree يثبّت HEAD الخاص به. وتنتقل التعارضات إلى مكانها الصحيح: وقت الدمج، عن قصد، وتحت المراجعة، بدلًا من أن تحدث وسط التعديل بالخطأ.

أوامر worktree التي ستستخدمها فعليًا

ابدأ داخل مستودع عادي. كل أمر أدناه يُنفَّذ من داخله.

إنشاء worktree مع فرع جديد. هذا هو الأمر الذي ستستخدمه أكثر من غيره:

git worktree add -b fix-logging ../myproject-fix-logging main

هذا الأمر ينشئ دليلًا في ../myproject-fix-logging، ويصنع فرعًا جديدًا باسم fix-logging منطلقًا من main، ويسحبه هناك. وجّه وكيلًا إلى ذلك الدليل فيصبح لديه مكان عمل نظيف ومعزول.

إنشاء worktree لفرع موجود:

git worktree add ../myproject-auth auth-refactor

سرد ما لديك مفتوحًا:

git worktree list

/Users/you/myproject              9f3c1a2 [main]
/Users/you/myproject-fix-logging  9f3c1a2 [fix-logging]
/Users/you/myproject-auth         3b7e0d4 [auth-refactor]

سطر واحد لكل worktree، مع مساره، والإيداع المسحوب، والفرع. وعندما تشغّل أسطولًا من الوكلاء، تصبح هذه القائمة هي مرجعك الموثوق لمعرفة من يوجد أين.

إزالة worktree بعد دمج العمل أو التخلي عنه:

git worktree remove ../myproject-fix-logging

تشذيب البيانات الوصفية القديمة بعد حذف دليل worktree يدويًا (يفعل الوكلاء والسكربتات هذا أكثر مما تحب):

git worktree prune

هذا هو السطح كله. خمسة أوامر. فالصعوبة لا تكمن في الأوامر.

المزالق التي تؤلمك فعليًا

الأوامر بسيطة. أما الواقع التشغيلي فهو الذي تذهب فيه بعد الظهيرات. هذه هي أنماط الفشل التي تظهر بمجرد تشغيل وكلاء حقيقيين في worktrees حقيقية.

الملفات غير المتتبَّعة والمتجاهَلة في git لا تأتي معك. يسحب الـ worktree الملفات المتتبَّعة عند الفرع الذي طلبته. لكنه لا ينسخ node_modules، ولا .env، ولا venv، ولا ذاكرة البناء المؤقتة، ولا أي شيء آخر يتجاهله git. لذا فإن worktree جديد لمشروع Node لا يكون قابلًا للتشغيل حتى تنفّذ التثبيت فيه. وكل worktree يدفع ثمن تثبيت اعتماداته وملف بيئته وبنائه بنفسه. والوكلاء الذين يفترضون أن «المستودع جاهز» سيفشل أمرهم الأول في worktree جديد حتى تتعامل مع التهيئة بشكل صريح.

لا يمكنك سحب الفرع نفسه مرتين. يرفض git أن يكون فرع واحد مسحوبًا في worktreeين في آن واحد، وهو محق في ذلك. وإذا احتاج وكيلان كلاهما سحب main، فعلى أحدهما إنشاء فرع. وهذه ميزة لا قيد، لكنها تفاجئ من توقعوا أن تكون الـ worktrees نسخًا طليقة.

المساحة على القرص تنمو بسرعة. مخزن الكائنات مشترك، فالتاريخ رخيص. أما أدلة العمل وتثبيتاتها فليست كذلك. عشرة worktrees لمشروع فيه node_modules بحجم 900 ميغابايت تعني 9 غيغابايت من الاعتماديات المكررة. وعلى حاسوب محمول يشغّل حفنة من الوكلاء، ستشعر بذلك قبل الغداء.

الـ worktrees غير النظيفة تقاوم الإزالة. يرفض git worktree remove التنفيذ إذا كان في الـ worktree تغييرات غير مُودَعة، وهذا يحميك من التخلص من عمل لم ينهه الوكيل. وعندما تريد إزالته فعلًا، استخدم git worktree remove --force. لكنك الآن تتحمل قرار ما إذا كان ذلك العمل غير المُودَع مهمًا، لكل worktree، يدويًا.

الأدلة المحذوفة تترك أشباحًا. احذف مجلد worktree بـ rm -rf وسيظل git يسرده حتى تشغّل git worktree prune. والسكربتات التي تنشئ worktrees أسرع مما تنظّفها تتراكم لديها إدخالات قديمة، وهذه الإدخالات تحمل أقفالًا تمنع إعادة استخدام أسماء الفروع. التنظيف ليس اختياريًا؛ لكنه سهل النسيان حتى يصبح git worktree list مقبرة.

ذاكرات التخزين المؤقت المتداخلة للوكلاء ليست ملكك لتحذفها. تحتفظ بعض بيئات التشغيل بذاكرات worktree خاصة بها، مثلًا تحت ~/.claude/worktrees. لا توجّه سكربتات التنظيف الخاصة بك إليها. دع الأداة التي تملك ذاكرة التخزين المؤقت تديرها.

لا شيء من هذه صعب بمفرده. المشكلة أنها تتراكم. worktreeان تديرهما يدويًا. خمسة، فتكتب سكربتًا. اثنا عشر وكيلًا يعملون عبر مستودعين، فيصبح السكربت قطعة بنية تحتية صغيرة لها أخطاؤها الخاصة، وأنت المسؤول عن الاستجابة لها على مدار الساعة.

أين تتوقف السكربتات عن التوسع

المسار الصادق يبدو هكذا. تبدأ بدالة shell تغلّف git worktree add، وتُسقط وكيلًا في الدليل الجديد، وتشغّل التهيئة. فينجح الأمر. تضيف نظام تسمية حتى لا تتصادم الأدلة. تضيف أمر تنظيف. ثم تتكدس المتطلبات.

تريد معرفة أي وكيل في أي worktree الآن، وما حالة فرعه. لكن git worktree list لا يعرف شيئًا عن الوكلاء؛ إنه يعرف الأدلة. فتضيف ملف ربط. وتريد ألا تدهس تثبيتات الاعتماديات لكل worktree قرصك، فتضيف منطق تخزين مؤقت. وتريد أن تستقر مخرجات الوكيل وفروقه ونتائج اختباره في مكان يستطيع إنسان مراجعته، بدلًا من أن تُحتجز في نافذة طرفية تُغلق. فتبدأ الآن في كتابة جامع نتائج. وتريد ألا يلتقط وكيلان المهمة نفسها من قائمة الانتظار. فتبدأ الآن في كتابة قفل.

وفي نقطة ما تكون قد أعدت بناء طبقة تنسيق من سكربتات shell، ولا أحد مهمته صيانتها. هذا هو الخط الفاصل الذي تدور حوله مناقشة بديل vibe kanban، وهو السبب الذي يدفع الفرق إلى البحث عن طبقة إدارة حقيقية بمجرد أن يتجاوز عدد الوكلاء حدًا معينًا. فالـ worktree لم يكن يومًا الجزء الصعب. الصعب هو تنسيق تشغيلات معزولة كثيرة وإعادة نتائجها إلى مكان واحد.

كيف تشغّل Sharkly كل مهمة في worktree خاص بها

Sharkly منصة شاملة لأوامر الوكلاء وإدارتهم. وهي لا تستبدل Claude Code أو Codex أو غيرها من أدوات التنفيذ التي يستخدمها وكلاؤك بالفعل؛ بل تضيف حولها طبقة المهام والحواسيب والسياق والمراجعة المشتركة. وعزل الـ worktree مدمج في تلك الطبقة، فتتوقف عن كتابته يدويًا.

الآلية مباشرة. كل مهمة تحصل على دليل معزول. وللعمل المدعوم بمستودع، تحضّر Sharkly worktree جديدًا لكل تشغيل من بيانات مستودعها المخزنة مؤقتًا، فيستطيع عدة مهام العمل على المصدر نفسه دون الكتابة أبدًا في checkout مشترك واحد. لن تشغّل git worktree add. ولن تكتب نظام تسمية، ولا مهمة تنظيف، ولا ملف ربط. تُسند مهمة، فيكون العزل موجودًا سلفًا.

وهذا هو فصل الاهتمامات الذي يجعل الأمر كله هادئًا. الوكيل يحدد كيف ينبغي التعامل مع العمل. والحاسوب يوفّر المضيف والموارد المحلية. وبيئة التشغيل تنفّذ جلسة الوكيل الفعلية. وتبقى المهمة السجل المشترك للفريق. ولأن كل تشغيل في worktree خاص به، يمكن للواجهة الأمامية والخلفية وإصلاح خطأ وتغطية اختبارات جديدة أن تتحرك كلها في الوقت نفسه دون أن يدوس بعضها على بعض، وهو تحديدًا التوازي الذي كان الأسلوب اليدوي يطمح إليه.

والنتائج لها مكان تذهب إليه. فالتنفيذ والعوائق والنتائج والنقاش اللاحق تعود كلها إلى الجدول الزمني للمهمة. وبدلًا من أن يعيش فرق الوكيل في نافذة طرفية عليك أن تتذكر تفقدها، يعود ملخص التغييرات ومخرجات التحقق والحدود المعروفة إلى المهمة، حيث يقبلها إنسان أو يطلب تعديلات أو يقرر الدمج. ويبقى السياق والتقدم والعوائق والنتائج والمراجعة البشرية ظاهرة من الطلب حتى الإصدار، في مكان واحد مشترك بدلًا من أن تتوزع بين مطالبات خاصة وجلسات طرفية. وإن كنت جديدًا على هذا النموذج، فإن إسناد مهمتك الأولى إلى وكيل برمجة بالذكاء الاصطناعي هو أقصر طريق للبدء.

وتبقى محتفظًا بالأدوات التي تستخدمها بالفعل. ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المُهيَّأة في تلك الأدوات؛ وتضيف Sharkly حولها العزل والتنسيق والمراجعة.

worktrees اليدوية مقابل طبقة إدارة

كلا الأسلوبين يستخدم البدائية نفسها. والفرق هو من يحمل العبء التشغيلي.

استخدم worktrees اليدوية عندما تكون مطورًا واحدًا يشغّل وكيلًا أو اثنين ويريد تحكمًا كاملًا في الـ shell. هذا الإعداد جيد فعلًا، ويستحق التعلم لأن آلياته تعلّمك ما تفعله أي طبقة فوقه. واستخدم طبقة إدارة عندما يكبر العدد، أو عندما يحتاج أكثر من شخص إلى رؤية العمل، أو عندما يكون فقدان نتائج وكيل في نافذة طرفية مغلقة قد كلفك شيئًا بالفعل. وهذا يطابق قاعدة القرار الصادقة في دليل تنسيق وكلاء الذكاء الاصطناعي لدينا: لا تضف آليات التنسيق حتى يصبح العمل المتوازي واقعًا، ولا تستمر في كتابتها يدويًا بمجرد أن يصبح كذلك.

عقد الإنسان والوكيل لا يزال قائمًا

العزل يغيّر مكان حدوث العمل، لا من يتخذ القرار. فـ worktrees تتيح للوكلاء البحث والتنفيذ والاختبار وإعداد التقارير بالتوازي دون تصادمات. ويظل البشر هم من يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وتتوقف الأتمتة حيث يلزم حكم الفريق. وworktree جديد لكل وكيل هو ما يجعل هذا الحد قابلًا للفرض: عمل كل وكيل يصل كتغيير مميز وقابل للمراجعة على فرعه الخاص، لا كتعديل لا يمكن تتبعه مدمج في checkout مشترك. أنت تراجع فروعًا، لا فوضى. وللصورة الأوسع لما يعنيه هذا التحول يومًا بيوم، يضع شرحنا حول البرمجة الوكيلية السياق، بينما يغطي ما هو Sharkly المنصة من البداية إلى النهاية.

بعض الأساليب المجرّبة للـ worktrees اليدوية

إن كنت ستبقى على الأسلوب اليدوي في الوقت الحالي، فهذه العادات تمنع معظم الألم:

• سمِّ أدلة worktree بأسماء الفروع أو المهام، لا بأرقام متسلسلة. فـ myproject-auth-refactor يخبرك بما هو؛ أما myproject-wt3 فلا.
• اجعل الـ worktrees أشقاء للـ checkout الرئيسي، لا متداخلة بداخله. فالتداخل يربك الأدوات التي تتنقل في الشجرة ويضخم قواعد التجاهل لديك.
• أتمت التهيئة لكل worktree في سكربت واحد يشغّله الوكيل أولًا، فيصبح الـ worktree الجديد قابلًا للتشغيل في خطوة واحدة بدلًا من الفشل بسبب تثبيت ناقص.
• نفّذ التشذيب وفق جدول، لا وفق المزاج. فتشغيل git worktree prune يوميًا مع مراجعة git worktree list يبقي الإدخالات الشبحية قليلة.
• لا تحذف أبدًا ذاكرة تخزين مؤقت متداخلة لبيئة تشغيل مثل ~/.claude/worktrees من سكربتاتك الخاصة. دع بيئة التشغيل تتولى ذلك.
• أودِع أو خزّن التغييرات مؤقتًا قبل الإزالة. فـ --force موجود للحالات التي تكون فيها متأكدًا، لا كخيار افتراضي.

الخاتمة

worktrees في Git هي البدائية العازلة التي تجعل وكلاء البرمجة بالذكاء الاصطناعي المتوازيين آمنين. والأفكار الأساسية جديرة بالحفظ:

• الـ checkout الواحد له فرع واحد وفهرس واحد وHEAD واحد، ولا يستطيع احتواء وكيلين في آن واحد.
• الـ worktree يضيف دليل عمل ثانيًا على التاريخ المشترك نفسه، فيحصل كل وكيل على فرعه وملفاته الخاصة.
• الأوامر الخمسة (add وlist وremove وprune و--force عندما تعنيها فعلًا) بسيطة.
• التكلفة التشغيلية (التثبيتات لكل worktree، والقرص، والتنظيف، والتنسيق، وجمع النتائج) هي ما يتضخم.
• الـ worktrees اليدوية مناسبة لوكيل أو اثنين؛ أما طبقة الإدارة فتستحق مكانها مع ارتفاع العدد والمخاطر.
• تحضّر Sharkly worktree جديدًا لكل مهمة تلقائيًا وتعيد كل نتيجة إلى المهمة للمراجعة البشرية.

تعلّم الأوامر اليدوية أولًا؛ فهي تعلمك ما تفعله أي طبقة فوقها. وعندما يبدأ العمل الكتابي في التكلفة أكثر من العمل نفسه، ترفع Sharkly عنك عبء الـ worktree والتنسيق والمراجعة. صِل حاسوبًا واحدًا، وأنشئ وكيلًا واحدًا، وأسند إليه شيئًا مملًا.

الأسئلة الشائعة

ما هو git worktree ببساطة؟ هو دليل عمل ثانٍ مرتبط بالمستودع نفسه، وله فرعه المسحوب وتغييراته المُجهَّزة وغير المُجهَّزة الخاصة به. ويتشارك تاريخ إيداعات واحدًا مع الـ checkout الرئيسي، لذا فهو أخف بكثير من الاستنساخ. وبالنسبة لوكلاء الذكاء الاصطناعي، يعني أن كل وكيل يحصل على مكان خاص به للعمل دون المساس بملفات أي أحد آخر.

لماذا يحتاج وكلاء البرمجة بالذكاء الاصطناعي إلى worktrees؟ لأن وكيلين يتشاركان checkout واحدًا سيَطمس كل منهما ملفات الآخر ويغيّر فرعه. وworktree لكل وكيل ينقل التعارضات إلى وقت الدمج، حيث تكون ظاهرة وقابلة للمراجعة، بدلًا من أن تحدث وسط التعديل حيث تُفسد الحالة بصمت. راجع دليلنا لتشغيل عدة وكلاء Claude Code بالتوازي للاطلاع على إعداد التوازي الكامل.

هل الـ worktree مثل الاستنساخ؟ لا. فالاستنساخ ينسخ قاعدة الكائنات بأكملها إلى مستودع منفصل. أما الـ worktree فيتشارك قاعدة كائنات واحدة ويضيف فقط دليل عمل جديدًا وسحب فرع. والإيداعات المُنفَّذة في أي worktree تظهر فورًا من جميعها، واستخدام القرص أقل بكثير.

هل يمكن لـ worktreeين سحب الفرع نفسه؟ لا. يرفض git سحب فرع واحد في worktreeين في آن واحد، لحمايتك من الكتابات المتعارضة على الفرع نفسه. وإذا احتاج وكيلان ذلك الفرع كأساس، فعلى أحدهما إنشاء فرع جديد منه.

كيف أنظّف الـ worktrees بأمان؟ أودِع أي عمل أو خزّنه مؤقتًا أولًا، ثم نفّذ git worktree remove <path>. وإن حذفت دليل worktree يدويًا، فشغّل git worktree prune لمسح البيانات الوصفية القديمة. ولا توجّه سكربتات التنظيف أبدًا إلى ذاكرة تخزين مؤقت خاصة ببيئة تشغيل مثل ~/.claude/worktrees.

متى ينبغي أن أتوقف عن إدارة الـ worktrees يدويًا؟ عندما تنسّق أكثر من وكيلين، أو عندما يحتاج أكثر من شخص إلى رؤية العمل، أو عندما تكون نتيجة ضائعة في نافذة طرفية مغلقة قد كلفتك وقتًا. عندئذ تستحق طبقة إدارة تعزل كل تشغيل وتتتبعه أن تدفع تكلفتها بنفسها. ويغطي دليل تنسيق وكلاء الذكاء الاصطناعي لدينا متى تقوم بهذه النقلة.