تخطَّ إلى المحتوى
ططارق الوليديAI Developer Tools Directory
J

Jujutsu (jj)

نشط ومستقريعمل محلياً ✓بدون اشتراك API

نظّم تغييرات Git بسلاسل قابلة لإعادة الصياغة، مع سجل للعمليات وتراجع محلي وتحديث للتغييرات التابعة.

$brew install jj
💡

الاستخدام المثالي لهذه الأداة

يناسب المطور الذي يراجع ميزة مقسمة إلى تغييرات صغيرة ويعود لتعديل خطوات سابقة. ابدأ بنسخة تجريبية منفصلة لفهم نسخة العمل وBookmarks؛ أجّل اعتماده في فريق يعتمد على أدوات Git لم تختبر توافقها.

التفاصيل والميزات المصورة

تعديل قديم في سلسلة تغييرات قد يجرّ وراءه إعادة ترتيب ومراجعة للتاريخ. Jujutsu، وأمره المختصر jj، يقدّم طريقة مختلفة لتنظيم هذا العمل مع مستودعات Git: تغييرات قابلة لإعادة الصياغة، وسجل لعمليات المستودع، ونسخة عمل تدخل ضمن نموذج التغييرات نفسه. فائدته المحتملة تظهر عندما تقسم ميزة إلى خطوات صغيرة وتعود لتعديل خطوة سابقة أثناء المراجعة.

🧭 ما الأداة؟ وأين تقع في سير العمل؟

Jujutsu نظام لإدارة الإصدارات بواجهة سطر أوامر. عند استخدام خلفية Git، تستطيع تبادل الالتزامات مع مستودع Git والتعاون مع فريق يستخدم أوامر Git المعتادة. لا يحتاج زملاؤك إلى التحول جماعيًا كي تبدأ تجربة محلية، لكن عليك فهم الفروق قبل إدخاله في مشروع مشترك. هذه خلاصة المستودع الرسمي ودليل التوافق، بتاريخ الاطلاع 25 أكتوبر 2026.

مكانه بين المحرر والمستودع البعيد: تكتب الشفرة في محررك، وتنظم تغييراتك محليًا بأوامر jj، ثم تتعامل مع المستودع البعيد عبر أوامر Git المدمجة فيه. لا يكتب الشفرة بدلًا منك، ولا يمنح المساعد البرمجي صلاحية جديدة بمجرد تثبيته. يمكن للمساعد الذي يملك تشغيل الطرفية استدعاؤه، وتظل حدود تلك الطرفية والمستودع هي الحدود الفعلية.

رسم توضيحي أصلي: المحرر ثم Jujutsu محليًا ثم مستودع Git البعيد
رسم توضيحي أصلي: المحرر ثم Jujutsu محليًا ثم مستودع Git البعيد

🧩 افهم نسخة العمل قبل حفظ أول تغيير

يمثل الرمز @ تغيير نسخة العمل الحالية. معظم أوامر jj تلتقط حالة الملفات وتحدّث هذا التغيير، بما فيها أوامر قد تبدو للقراءة مثل jj status. يتغير معرّف التزام Git عندما تتغير محتوياته، بينما يساعد معرّف التغيير في متابعة التغيير نفسه عبر إعادة صياغته. راجع نسخة العمل والمقارنة مع Git.

النتيجة العملية: لا تفترض أن عبارة «لم أنفّذ commit» تعني أن الملفات لم تدخل السجل المحلي. افصل بين ثلاثة أسئلة: ما الملفات الموجودة؟ ما الذي تحتويه نسخة العمل؟ وما الذي أرسلته إلى الخادم؟ التقاط الحالة المحلية لا يعني نشرها، لكنه يستحق المراجعة مثل أي تاريخ محفوظ.

قبل التجربة، اضبط أنماط تجاهل الملفات السرية والمؤقتة. الملفات الجديدة قد تُتبع تلقائيًا إن لم تكن مستثناة. وإضافة ملف متتبع إلى .gitignore لاحقًا لا تزيل تتبعه تلقائيًا؛ تشرح الوثائق استخدام jj file untrack لهذه الحالة. لا تعتمد على اسم المجلد وحده لحماية .env أو مفاتيح الوصول.

رسم توضيحي أصلي: تعديل الملفات ثم التقاط الحالة عند أمر jj ثم تحديث تغيير نسخة العمل
رسم توضيحي أصلي: تعديل الملفات ثم التقاط الحالة عند أمر jj ثم تحديث تغيير نسخة العمل

🛠️ التثبيت وتجربة محلية محدودة

على macOS أو Linux مع Homebrew، توثق صفحة التثبيت والإعداد الأمر التالي. الأمثلة هنا تعليمية، ولم أُثبّت الأداة أو أشغّلها على مستودعك لإعداد هذه البطاقة.

brew install jj
jj --version

تذكر ملاحظات الإصدار v0.46.0، المنشور في 7 أكتوبر 2026، أن الحد الأدنى لـ Git هو 2.42.0. افحص نسختك قبل التجربة. إن اخترت البناء من المصدر فراجع متطلبات Rust الخاصة بالإصدار بدل افتراض أن وجود Git وحده يكفي.

اضبط هوية الالتزامات المحلية باستخدام بياناتك المناسبة؛ القيم التالية أمثلة تستبدلها:

jj config set --user user.name "Example Name"
jj config set --user user.email "name@example.com"

ثم ابدأ بنسخة منفصلة من مستودع تجريبي عام، داخل مجلد تجارب فارغ. توضح الوثائق التعليمية وطريقة الاستنساخ هذا النمط:

jj git clone https://github.com/octocat/Hello-World
cd Hello-World
jj status
jj log

اقرأ الحالة والتاريخ، وعدّل ملفًا تجريبيًا، ثم نفّذ jj diff لمراجعة الفرق. يفتح jj describe محرر وصف التغيير؛ وبعد إنهاء الوصف ينشئ jj new تغييرًا جديدًا فوق الحالي. أبقِ التجربة محلية أولًا، ولا تنقلها إلى مستودع عمل مزدحم قبل أن تفهم ما يظهر في jj log.

🔁 ماذا يحدث عندما ترجع إلى خطوة سابقة؟

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

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

رسم توضيحي أصلي: تعديل التغيير الأساسي يحدّث التابعين مع ضرورة مراجعة التعارضات والاختبارات
رسم توضيحي أصلي: تعديل التغيير الأساسي يحدّث التابعين مع ضرورة مراجعة التعارضات والاختبارات

↩️ سجل العمليات: وسيلة لفهم ما تغيّر

يعرض jj op log عمليات تعديل المستودع، ويساعد jj undo في التراجع عن عملية محلية. هذا مستوى مختلف عن قراءة قائمة الالتزامات: قد تريد فهم ما فعله أمر إعادة ترتيب، لا مجرد معرفة أسماء الملفات المتغيرة. التفاصيل في سجل العمليات.

قبل التراجع، اقرأ العملية المقصودة واحفظ سياقك: ما الأمر السابق؟ هل تعمل في مساحة العمل الصحيحة؟ هل نفّذت تغييرًا بعيدًا بعده؟ لا تتعامل مع undo كإلغاء لنشر بعيد، أو كنسخة احتياطية لكل ملف على الجهاز. ويقيّد الإصدار v0.46.0 التراجع عن عمليات مساحة عمل أخرى افتراضيًا؛ لا تتجاوز هذا القيد في تجربة أولى.

رسم توضيحي أصلي: اقرأ سجل العمليات وحدد العملية المحلية ثم تراجع وراجع الحالة
رسم توضيحي أصلي: اقرأ سجل العمليات وحدد العملية المحلية ثم تراجع وراجع الحالة

🏷️ كيف يصل العمل إلى فريق يستخدم Git؟

تسمى المؤشرات المسماة للتغييرات هنا Bookmarks، وتُربط بفروع Git عند التبادل معه. يعرضها jj bookmark list. لا يوجد مفهوم فرع نشط مطابق تمامًا لعادتك مع git checkout؛ لذلك لا تنقل ذاكرة أوامر Git حرفيًا. راجع دليل Bookmarks قبل أول إرسال إلى فرع مشترك.

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

⚖️ ما الذي تكسبه؟ ومتى تؤجل اعتماده؟

حاجتكما يقدمه jjما يبقى عليك
مراجعة ميزة مقسمةتنظيم تغييرات قابلة لإعادة الصياغةتقسيم مفهوم ووصف مفيد لكل خطوة
تعديل خطوة مبكرةتحديث التغييرات التابعةحل التعارضات وفحص السلوك
فهم أمر غيّر التاريخسجل عمليات وتراجع محليتحديد العملية الصحيحة ومراجعة الحالة
تعاون مع فريق Gitخلفية Git وتبادل الفروعفهم Bookmarks واختبار أدوات الفريق

ابدأ بتجربة صغيرة إذا كنت تراجع سلاسل تغييرات باستمرار وتريد تقييم طريقة أخرى لتنظيمها. أجّل الاعتماد العام إن كان الفريق لا يملك وقتًا لتعلم النموذج، أو إن كانت أدواته تعتمد على سلوك Git محدد لم تتحقق من توافقه. لا تعني عبارة «متوافق مع Git» أن كل إعداد أو امتداد أو hook يعمل كما تتوقع؛ اختبر متطلبات مشروعك بالاسم وفق دليل التوافق.

🔐 التكلفة والصلاحيات وحدود التحقق

الأداة مفتوحة المصدر بترخيص Apache-2.0. أوامرها المحلية لا تحتاج اشتراك نموذج ذكاء اصطناعي أو مفتاح API مدفوع. تثبيت الحزم والاستنساخ والجلب والإرسال تحتاج اتصالًا بحسب العملية، وتستخدم العمليات البعيدة آلية مصادقة Git. لا تخلط بين «تعمل محليًا» وبين وعد بأن جميع الأوامر بلا شبكة.

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

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

📚 المصادر وتاريخها

أعيد التحقق من المستودع والإصدار والتثبيت ونسخة العمل وBookmarks وسجل العمليات والتوافق في 28 أكتوبر 2026. بقي الإصدار الأخير v0.46.0؛ رصد GitHub: 32270 نجمة و1266 تفرعًا. لم تُنفّذ الأوامر على مشروع.