العودة إلى المدونة

Jujutsu مقابل Git: زرّ التراجع الذي لم يملكه Git قط

29 سبتمبر 2026

هل حلّ هذا المشكلة؟

إن reflog في git ينقذ الـ commits، لكنه لا ينقذك من الأمر الذي شغّلته عليها. هذه الفجوة — التراجع عن العملية لا عن الـ commit وحده — هي حجّة Jujutsu كلها. وبعد قراءة سجلّ المشروع بدلًا من دعايته، الحجّة تصمد أكثر مما يظنّ المشككون.

صفحة Undo Anything in Git hub في هذا الموقع قائمة أصلاً لأن قصة التراجع في git مبعثرة: reset وrevert وreflog، لكلٍّ قواعده. ورهان jj أن هذه التبعثر عيب في التصميم نفسه.

ما هو Jujutsu، ولماذا نقارنه بـ git أصلًا؟

jj نظام لإدارة الإصدارات متوافق مع Git: 31,796 نجمة على GitHub، و376 مساهمًا، وأول إصدار في ديسمبر 2020، وإصدار جديد كل شهر منذ ذلك الحين — من v0.35 في نوفمبر 2025 إلى v0.45.1 في سبتمبر 2026، اثنا عشر إصدارًا هبطت جميعها في الأسبوع الأول من كل شهر كأنها بمنبّه. وقد دُفع آخر commit صباح يوم نشر هذه التدوينة.

«متوافق مع Git» هو الجزء الذي يُنسى. يستخدم jj مستودع Git وسيط تخزين افتراضي — والـ README صريح: الـ commits والملفات تُخزَّن بصيغة git، فمستودعك المحلي ومستودعاتك البعيدة ومنصّاتك وخطوط CI تواصل العمل. وسؤال jujutsu vs git الذي يبحث عنه الجميع إطارٌ خاطئ: jj أقرب إلى واجهة جديدة فوق تخزين تثق به أصلًا. أمّا Sapling من Meta فقد راهنت على العكس بوسيط تخزين خاص بها، ولهذا فالانتقال إليها يعني ترك المزيد من منظومة git خلفك.

ماذا يفعل سِجلّ العمليات مما يعجز عنه git؟

هذا هو القرار التصميمي الذي يستحق المراجعة كلها. يسجّل git الـ commits في reflog — العمل الضائع بالخطأ يبقى قابلًا للاستعادة لنحو 90 يومًا. لكن reflog لا يعنيه تسلسل الأوامر الذي أنتج الفوضى. مقالة الاختيار بين revert وreset موجودة لأن git يُلزمك باختيار أمر التراجع الصحيح قبل أن تعرف أيّها تحتاج.

يسجّل jj كل عملية — كل rebase وكل abandon وكل squash — في سِجلّ عمليات. من الـ README نفسه: «لأن كل شيء موثّق، تستطيع التراجع بسهولة عن الخطأ الذي ارتكبته للتو.» يعرض jj op log تاريخ حالة المستودع، ويخطو jj undo فيها خطوةً خطوة إلى الخلف. rebase خاطئ؟ تراجع. reset إلى المكان الخطأ؟ تراجع. الأداة تمتدّ بالأمان نفسه الذي يمتدّ به git إلى بياناتك، لكن إلى إجراءاتها هي.

قصة التراجع في git تفترض أنك ستختار الأمر الصحيح. قصة jj تفترض أنك لن تفعل.

هل التعارضات فعلًا من الدرجة الأولى؟

نعم، وهو ما يغيّر عمل الفرق أكثر من قصة التراجع. يعامل git تعارض الدمج بوصفه حالة مؤقتة في شجرة العمل — تحلّه الآن أو تلغي. يخزّن jj التعارضات ككائنات في التاريخ: الـ commit المتعارض يمكن أن يوجد، وأن يُعمل له commit، بل ويُدفع. تحلّ التعارض لاحقًا فينقل jj الحلّ تلقائيًا إلى كل الأحداث — الآلية نفسها التي تُعيد ترتيب رصّتك من الـ commits تلقائيًا عندما تعدّل commitًا مبكرًا.

والنتيجة في مشروع حقيقي — تغييرات مكدّسة تُعيد ترتيب نفسها — هي ما يقنع الناس. من نقاش Hacker News حول أنماط jj (236 نقطة):

«الـ PRs المكدّسة مع إعادة foundational متعددة الفروع صارت تافهة. التعارضات أشياء حقيقية في التاريخ يمكن العودة إليها لاحقًا. كل شيء يُعمل له commit تلقائيًا، فلا أفقد عملًا بسبب reset/stash pop خاطئ.» — hellcow

تلك الجملة الأخيرة هي التي يجب أن تتوقف عندها. نسخة العمل في jj هي بحد ذاتها commit يُعدَّل مع كل تغيير. لا stash لأنه لا شيء يحتاج stash — تغيير الفرع يحمل عملك الجاري كـ commit. ومعلّق آخر انتقل إليه في عمله لدى فريق يعمل بـ git حصرًا: «لم تحدث أي مشكلة.»

ماذا يقول السجلّ ضد jj؟

السِجلّ الصادق، لأن للسجلّ وجهًا آخر:

  • إصدار 0.x بلا تجميل. اثنا عشر إصدارًا شهريًا تعني أيضًا اثنتي عشرة فرصة شهريًا لتغييرات كاسرة. المشروع يسير سريعًا ويقول ذلك.
  • الـ bookmarks تسكن خارج git. الـ commits والملفات على تخزين git، أمّا بيانات الفروع الوصفية فبصيغة jj الخاصة. المستودعات المزدوجة (colocated) تعمل جسرًا بينهما، لكنها قطعة إضافية يلزم فهمها.
  • 1,262 issue مفتوحة. مشروع صحي، وقائمة مهام حقيقية.
  • المتشكك محقّ في شيء أيضًا. أكثر التحفظات تصويتًا في نقاش HN: «قرأت عن jj مرات كثيرة وما زلت لا أفهم أيّ مشكلة يحلّها فعلًا.» إذا كان سير عملك مع git فرعًا واحدًا ودمجًا بين حين وآخر، فلن يغيّر سِجلّ العمليات أسبوعك. المكاسب تأتي مع العمل المكدّس والتواريخ المتعارضة وأيام التراجع الكثيفة — الأيام التي يحصد فيها مولّد git undo زواره.

هل تنتقل من git إلى jj؟

الحكم من السجلّ، مع سطر الصدق الإلزامي: قرأتُ السجلّ، ولم أشغّله. كل رقم وكل اقتباس هنا من المستودع ومن README ومن نقاش HN العام — لا من طرفي.

ما يدعمه السجلّ: جرّب jj بنمط colocated على مشروع جانبي — مستودع واحد، أداتان، صفر هجرة. معرفتك بـ git تنتقل كما هي، لأن الكائنات في الأسفل كائنات git. ويمكن للفرق تبنّيه فردًا فردًا، لأن jj يدفع commits عادية من git إلى المنبع. وما لا يدعمه السجلّ: هجرة شاملة دفعة واحدة لفريق راسخ، أو إسناد الأتمتة الحرجة إلى أداة 0.x قبل فترة تجربة بإصدار مثبّت.

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

هل تقايض عطلة أسبوع من الذاكرة العضلية بسِجلّ تراجع يغطي الأداة نفسها؟ وبصراحة — آخر مرة فقدت فيها عملًا بسبب reset، هل استعاد reflog كل شيء؟

FAQ

هل Jujutsu متوافق مع Git؟

نعم. يستخدم jj مستودع Git وسيط تخزين افتراضي، فيعمل المستودع نفسه بالأداتين معًا (colocated)، وتبقى مستودعاتك البعيدة ومنصّات الاستضافة وخطوط CI كما هي.

هل يتراجع jj عن rebase أو reset؟

نعم — وهذه هي سِجلّ العمليات. يوثّق jj كل إجراء ينفّذه، ويرجع بك jj undo خطوةً خطوة. إن reflog في git ينقذ الـ commits فقط؛ أمّا سِجلّ jj فينقذ العمليات نفسها.

كيف يتعامل jj مع تعارضات الدمج؟

يخزّنها ككائنات من الدرجة الأولى داخل التاريخ. الحالة المتعارضة يمكن commit عملها ودفعها وحلّها لاحقًا — والحلّ الواحد ينتقل تلقائيًا إلى كل الـ commits الأحداث.

هل Jujutsu جاهز للإنتاج؟

يقول السجلّ نعم للأفراد والفرق الصغيرة: 31,796 نجمة، 376 مساهمًا، إصدار كل شهر منذ 2020، وكل مطوري النواة يستخدمون jj لبناء jj نفسه. ما يزال 0.x، فالتغييرات الكاسرة تأتي مع الإصدارات الشهرية.

— mrsaynothing

$ احصل على الطرح التالي بالبريد

رسالة واحدة لكل مقال. وافق أو حطّمها.

self-hosted · بلا أطراف ثالثة · إلغاء الاشتراك بنقرة واحدة

ما هذا؟