النظام الذي لم يطلب إذن أحد: لماذا ينتشر jj حيث فشل Mercurial؟

كل بضع سنوات يظهر نظام إصدارات جديد أفضل من Git بمعايير واضحة: أوامر أبسط، سلوك أقل مفاجأةً، منحنى تعلّم أقصر. وكل بضع سنوات ينتهي إلى الهامش. حدث هذا مع Mercurial وFossil وDarcs، ولا شيء في تصميم أيٍّ منها يفسّر الخسارة. ما يفسّرها أن السؤال الذي يواجهه أي منافس لـGit ليس «هل هذه الأداة أفضل؟» بل سؤال آخر تمامًا — وفي 2026 ظهرت أداة اسمها jj تبدو وكأنها أوّل من قرأ السؤال بشكل صحيح.

القاعدة التي كسرت كل منافسي Git

الحكاية الشائعة أن Git فاز لأنه أقوى. الحكاية الأدقّ أن GitHub هو من فاز، وأن Git ركب الموجة. وحين تنظر إلى الأرقام يصير النمط واضحًا:

• في استطلاع Stack Overflow لعام 2018، كان نحو 87% من المطوّرين على Git مقابل 4% تقريبًا على Mercurial.
• Bitbucket أُطلق عام 2008 وهو يدعم Mercurial فقط. وبحلول 2019، كان أقل من 1% من مستخدميه الجدد يختارون Mercurial — على منصّة بُنيت له أصلًا.
• وFossil لم يفشل لضعف جودته، بل لاختلاف هدفه: صُمّم لمشروع SQLite الذي يعمل عليه عدد صغير جدًا من المساهمين ولا يستقبل مساهمات خارجية عادةً، بينما صُمّم Git لنواة لينكس بآلاف المساهمين.
• وDarcs كانت لديه مشكلة أداء حقيقية (الدمج الأُسّي الشهير)، وحين عالجها الإصدار الثاني كانت الهجرة قد حدثت بالفعل.

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

السؤال لم يعد «هل هذه الأداة أفضل من Git؟» بل «هل هي أفضل بما يكفي لتبرير التخلّي عن GitHub، وعن كل خدمة تكامل مستمر، وعن كل شرح على الإنترنت، وعن كل زميل يعرف Git بالفعل؟» — وهذا سقف لا تبلغه تحسينات الاستخدام وحدها مهما كانت جيّدة.

وهذا بالضبط ما يقوله المطوّرون عن أنفسهم: كثيرون انتقلوا من Mercurial إلى Git وهم يفضّلون Mercurial، لأن العثور على إجابة لمشكلة في Git أسهل بمراتب، ولأن أدوات CI تدعمه أولًا، ولأن المطوّر الجديد تعلّمه في الجامعة.

ما الذي فعله jj بشكل مختلف؟

jj (الاسم الكامل Jujutsu) نظام إصدارات موزّع بدأه المهندس Martin von Zweigbergk في جوجل، مكتوب بلغة Rust ومفتوح المصدر بالكامل، صدر أوّل مرة في 2022 ووصل إلى الإصدار 0.38 مطلع 2026.

لكن الميزة التي تهمّ هنا ليست في قائمة مزاياه التقنية. هي في قرار معماري واحد:

jj يقرأ ويكتب في مجلّد .git نفسه.

النتيجة العملية أن الكوميتات التي ينشئها jj هي كوميتات Git حقيقية، تُدفَع إلى GitHub أو GitLab أو أي خادم، ولا يلاحظ أحد شيئًا. زميلك على المستودع نفسه يواصل استخدام Git، وأنت تستخدم jj، ولا يحتاج أحدكما إلى معرفة ما يفعله الآخر.

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

هنا الفرق الجوهري عن كل من سبقه: Mercurial وFossil وPijul كانوا يطلبون من الجميع أن يتغيّروا معًا. jj لا يطلب من أحد شيئًا.

ثلاثة قرارات تصميمية تشرح لماذا يستحقّ التجربة

لو كان jj مجرّد واجهة ألطف لـGit لما استحقّ نصف ساعة. لكنه يغيّر ثلاثة أشياء أساسية.

1) نسخة العمل هي كوميت

في Git لديك ثلاث حالات: الملفات على القرص، ومنطقة التجهيز (staging)، والمستودع. في jj توجد حالة واحدة: ملفاتك الحالية هي كوميت قائم بذاته، يُحدَّث تلقائيًا كلما شغّلت أمرًا.

عمليًا: لا git add، ولا نسيان تجهيز ملفّ قبل الكوميت. الملف الجديد يُتتبَّع تلقائيًا، والمحذوف يُزال من التتبّع تلقائيًا. وحين تنتهي من وحدة عمل، تكتب jj new لتبدأ كوميتًا جديدًا فوقه.

الأثر الأوضح يظهر في تعديل كوميت قديم. في Git: كوميت إصلاح، ثم git rebase -i، ثم تحرير، ثم متابعة. في jj: تنتقل إلى الكوميت القديم مباشرةً وتحرّر الملف — وهذا وحده يكافئ git commit --amend، ويعيد تأسيس كل الكوميتات التي تليه تلقائيًا دون أمر إضافي.

2) الصراعات مواطن من الدرجة الأولى

في Git، الصراع يوقف العملية. rebase يتوقّف في منتصفه، وتدخل في حالة وسيطة عليك الخروج منها بـ--continue أو --abort.

jj يسجّل الحالة المتصارعة داخل الكوميت نفسه، فينجح الـrebase ولا يتوقّف، وتحلّ الصراع وقتما تشاء. والمخزَّن في الكوميت تمثيل منطقي للصراع، لا علامات <<<<<<< النصّية — ولهذا لا تتولّد لديك علامات صراع متداخلة عند إعادة تأسيس صراع قائم. ونتيجة جانبية مهمّة: jj يعيد تأسيس كوميتات الدمج (merge commits) بشكل صحيح، وهو أمر لا يجيده Git ولا Mercurial.

3) سجلّ العمليات

كل عملية تغيّر المستودع تُسجَّل في «سجلّ العمليات»، تراه بـjj op log. كل عملية تحمل لقطة كاملة لحالة المستودع عند انتهائها: أين كانت تشير العلامات والوسوم ومراجع Git، وما هي الرؤوس، وما هو كوميت نسخة العمل.

المعنى العملي لهذا سطر واحد: jj undo يتراجع عن أي عملية، لا عن آخر كوميت فقط. مع الصراعات من الدرجة الأولى، تصبح التجربة رخيصة — تدمج فرعًا، تجرّب ترتيبًا مختلفًا للكوميتات، ثم تستعيد حالتك الأصلية كما كانت.

جدول: نفس الموقف في النظامين

الموقف اليومي	في Git	في jj
حفظ التغييرات	git add ثم git commit	تلقائي؛ الملفات الحالية كوميت بالفعل
تعديل كوميت قديم	كوميت إصلاح ثم rebase -i	تنتقل إليه وتحرّر مباشرة، والباقي يُعاد تأسيسه تلقائيًا
صراع أثناء إعادة التأسيس	العملية تتوقّف وتنتظر --continue	العملية تنجح والصراع محفوظ داخل الكوميت
التراجع عن خطأ	حسب الحالة: reflog، reset، revert	jj undo لأي عملية
هل يحتاج موافقة الفريق؟	—	لا؛ الزملاء يرون كوميتات Git عادية

لماذا صار هذا مهمًّا في 2026 تحديدًا؟

هنا يدخل السياق الذي يغيّر وزن الموضوع كلّه.

حين كانت الكوميتات تُكتب يدويًا، كان تعديل التاريخ عملية استثنائية تحدث قبل فتح Pull Request. في 2026 تغيّر التوزيع: وكلاء البرمجة ينتجون تغييرات كبيرة ومتشعّبة دفعة واحدة، وتحوّل عبء المطوّر من الكتابة إلى التقسيم والمراجعة. استطلاعات 2026 تشير إلى أن المطوّرين صاروا يقضون نحو 11.4 ساعة أسبوعيًا في مراجعة كود مولّد بالذكاء الاصطناعي مقابل 9.8 ساعة في كتابة كود جديد — انعكاس كامل لنمط 2024.

ومعنى ذلك أن مهارة «خذ تغييرًا ضخمًا وقسّمه إلى سلسلة كوميتات مفهومة وقابلة للمراجعة» انتقلت من مهارة نادرة إلى عمل يومي متكرّر. وهذه بالضبط العملية التي يجعلها Git مؤلمة ويجعلها jj رخيصة.

لاحظ أن هذا ادّعاء عن سير العمل، لا عن الأداء الخام، ولا يوجد قياس معياري يثبته. لكنه يفسّر لماذا يظهر الاهتمام بـjj الآن بعد أربع سنوات من إطلاقه بهدوء.

ما الذي لا يقوله المتحمّسون

المقالات المتحمّسة تتجاهل عادةً أربع نقاط تستحقّ أن تعرفها قبل أن تقرّر:

• المنظومة أصغر بكثير. أدوات الطرف الثالث وإضافات المحرّرات وتكاملات CI كلّها مبنية حول Git، ودعم jj فيها متفاوت.
• الأداء في المستودعات العملاقة. بعض الحالات الحدّية في الـmonorepo أبطأ ممّا تتوقّع.
• التوثيق فيه زوايا خشنة، والإصدار ما زال في نطاق 0.x — أي أن الأوامر والسلوك عرضة للتغيير بين الإصدارات.
• jj ليس بديلًا عن Git، وهذا مقصود. التوصيف الأدقّ أنه طبقة واجهة فوق Git، تمامًا كما أن TCP/IP بنية تحتية لا يتفاعل معها أحد مباشرةً. السؤال المطروح ليس «هل يزيح jj نظام Git؟» بل «هل يصبح jj ما يتعامل معه المطوّرون فعليًا بينما يبقى Git هو البروتوكول تحته؟».

وأمّا التوقّعات المتداولة — مثل أن يصبح jj الواجهة الافتراضية لمشروع مفتوح المصدر كبير خلال سنتين — فهي رأي كتّاب، لا خبر ولا إعلان، وتستحق أن تُقرأ بهذا الوصف.

جرّبه بأمان في نصف ساعة

إن أردت الحكم بنفسك بدل الاعتماد على انطباعات الآخرين، هذه أقصر طريق:

1. ابدأ بمستودع منخفض المخاطر — مشروع جانبي، أو مستودع توثيق، لا مشروع العميل الذي يسلَّم غدًا.
2. فعّله داخل مستودع Git قائم بوضع التعايش (jj git init --colocate)، فيبقى .git كما هو ويظلّ Git متاحًا بجواره في أي لحظة.
3. تعلّم خمسة أوامر فقط في البداية: jj st لعرض الحالة، وjj new لبدء وحدة عمل، وjj describe لكتابة الرسالة، وjj squash لدمج التغيير في الكوميت الأب، وjj op log مع jj undo للتراجع.
4. ادفع بشكل طبيعي إلى GitHub وراقب النتيجة عند زملائك: كوميتات عادية تمامًا، بلا أي أثر للأداة.
5. احكم بعد أسبوعين لا بعد يومين. أوّل يومين ستشتاق إلى منطقة التجهيز لمجرّد الاعتياد؛ الفرق الحقيقي يظهر في أوّل rebase معقّد.

أسئلة شائعة

هل أحتاج موافقة فريقي لاستخدامه؟

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

هل سأفقد GitHub وPull Requests؟

لا. jj يتعامل مع Git كواجهة خلفية، والدفع والسحب وفتح الـPull Requests تجري كالمعتاد على منصّتك الحالية. ما تفقده هو بعض التكاملات المتخصّصة التي تفترض أوامر Git حرفيًا في سير عملها المحلّي.

هل يصلح لمستودع ضخم أو لفريق كبير؟

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

الخلاصة

قصة jj ليست قصة أداة أفضل من Git — فقد كانت هناك أدوات أفضل من Git، وخسرت كلّها. القصة أن أثر الشبكة يُهزم بطريقة واحدة فقط: بألّا تطلب من الشبكة أن تتحرّك معك.

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