التفريع على غرار Git

إليك النموذج الذهني: يحول Rediacc الفروع ذات النسخ عند الكتابة إلى سجل إصدارات على غرار git. كل فرع غير قابل للتعديل هو نقطة إيداع: صورة مستقرة على مستوى البايتات ومجمّدة ترفض الوصل. الفروع هي مراجع مسماة تشير إلى نقطة إيداع. يستنسخ rdc repo checkout نقطة إيداع عبر رابط مرجعي إلى فرع عمل قابل للكتابة، ويجمع rdc repo merge خطَّين من السجل دون تعديل مستودع حي في مكانه أبداً.

يُعيَّن النموذج إلى مخزنَين. الجهاز هو مخزن الكائنات: نقاط الإيداع هي صور فروع غير قابلة للتعديل موجودة على مخزن البيانات. تكوين CLI هو مخزن المراجع: أسماء الفروع، وHEAD الحالية، وسجل المراجع كلها في التكوين المحلي وليس على الجهاز. هذا هو نفس الفصل الذي يستخدمه git بين .git/objects و.git/refs.

متى تستخدمه

الجأ إلى التفريع عندما يستحق الفرع اسماً. أجرى وكيل ذكاء اصطناعي عمليات على فرع من الإنتاج، وبدت النتائج جيدة، وتريد نقطة تحقق مجمّدة ومسماة يمكنك العودة إليها أو ترقيتها لاحقاً: rdc repo commit يجمّدها، وrdc repo branch يسميها. قبل ترحيل محفوف بالمخاطر، احفظ الفرع العامل كنقطة إيداع حتى يكون لديك نقطة تراجع دقيقة مضمونة عدم التغيير (نقطة الإيداع غير القابلة للتعديل ترفض الوصل، لذا لا شيء يمكنه الكتابة فيها). لمقارنة نقطتَي تحقق، يعمل rdc repo diff بين أي نقطتَي إيداع لأنهما تشتركان في سلف ذي نسخ عند الكتابة. لإعادة خط عمل مراجَع إلى فرع هدف، يبني rdc repo merge النتيجة في نسخة رابط مرجعي ويستبدلها بصورة ذرية، فلا يتعرض هدف قيد التشغيل للتلف في منتصف الدمج.

لا تلجأ إليه بديلاً عن rdc repo fork عندما تحتاج فقط إلى نسخة مؤقتة. الفرع العادي هو الوحدة الصحيحة للعزل المؤقت لكل اختبار. تضيف نقاط الإيداع قيمة عندما تستحق حالة ما الحفظ أو التسمية أو الشحن.

كيف ترتبط نقاط الإيداع بالفروع

المستودع هو ملف صورة LUKS واحد على تجمع btrfs. الفرع هو رابط مرجعي ثابت الوقت لتلك الصورة، لذا فإن تفريع مستودع بحجم 1 غيغابايت ومستودع بحجم 100 غيغابايت يكلف نفس التكلفة. نقطة الإيداع هي فرع تم وضع علامة عليه بأنه غير قابل للتعديل: يرفض renet وصله، مما يحافظ على استقرار صورته على مستوى البايتات إلى الأبد. هذا الاستقرار هو ما يجعل نقطة الإيداع نقطة تراجع موثوقة وأساساً حتمياً لنقل الدلتا بين الأجهزة.

يسجّل rdc repo commit رسالة الإيداع والمؤلف والطابع الزمني ونقطة الإيداع الأصل داخل المجلد (حتى تنتقل البيانات الوصفية مع الصورة عند الدفع) ويعكسها أيضاً خارج المجلد (حتى يتمكن rdc repo log من استعراض السجل دون فك قفل أي شيء). يستمر فرع العمل الذي أودعته دون تغيير، تماماً كما يترك git شجرة عملك سليمة بعد الإيداع.

الأوامر

rdc repo commit

يجمّد فرع عمل مثبتاً في نقطة إيداع جديدة غير قابلة للتعديل.

rdc repo commit --name <fork> --message "<message>" -m <machine>

الخيار	الوصف	الافتراضي
--name <name>	فرع العمل المراد إيداعه. يجب أن يكون مثبتاً. مطلوب.	مطلوب
--message <msg>	رسالة الإيداع. مطلوب.	مطلوب
--author <author>	مؤلف الإيداع المسجّل في بيانات الإيداع الوصفية.	غير محدد
-m, --machine <name>	الجهاز الهدف. مطلوب.	مطلوب
--debug	تشخيصات مفصّلة على stderr.	إيقاف

تُسجَّل نقطة الإيداع الجديدة في التكوين المحلي بـ immutable: true، ويتقدم headCommit لفرع العمل للإشارة إليها. يُرفض إيداع مستودع غير قابل للتعديل: استرجعه أولاً في فرع قابل للكتابة.

rdc repo branch

ينشئ مرجع فرع مسمى يشير إلى نقطة الإيداع الحالية لفرع العمل.

rdc repo branch --branch <name> --name <fork>

الخيار	الوصف	الافتراضي
--branch <branch>	اسم الفرع الجديد. مطلوب.	مطلوب
--name <name>	فرع العمل الذي تشير نقطة إيداعه الحالية إلى الفرع. مطلوب.	مطلوب

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

rdc repo checkout

يستنسخ نقطة إيداع غير قابلة للتعديل (أو طرف فرع) عبر رابط مرجعي إلى فرع عمل جديد قابل للكتابة.

rdc repo checkout --ref <commit> --tag <newFork> -m <machine>
rdc repo checkout --ref <branchName> --from <fork> --tag <newFork> -m <machine>

الخيار	الوصف	الافتراضي
--ref <commit|branch>	GUID نقطة الإيداع المراد استرجاعها، أو اسم فرع عند إعطاء --from. مطلوب.	مطلوب
--tag <name>	اسم فرع العمل القابل للكتابة الجديد. مطلوب.	مطلوب
-m, --machine <name>	الجهاز الهدف. مطلوب.	مطلوب
--from <workingFork>	يحلّ --ref كاسم فرع على مجموعة فروع فرع العمل هذا.	إيداع مباشر
--debug	تشخيصات مفصّلة على stderr.	إيقاف
--skip-router-restart	تخطي خطوة إعادة تشغيل الموجّه.	إيقاف

يُعيد الاسترجاع استخدام مسار الرابط المرجعي للفرع، لذا يكون شبه فوري وثابت الوقت بغض النظر عن حجم المستودع. يُعيَّن headCommit لفرع العمل الجديد إلى نقطة الإيداع المسترجَعة.

rdc repo log

يستعرض سجل الإيداعات القابلة للوصول من فرع عمل أو نقطة إيداع.

rdc repo log --name <fork> -m <machine>

الخيار	الوصف	الافتراضي
--name <name>	فرع العمل أو نقطة الإيداع لبدء استعراض السجل منها. مطلوب.	مطلوب
-m, --machine <name>	الجهاز الهدف. مطلوب.	مطلوب
--json	إخراج سجل الإيداعات بصيغة JSON.	إيقاف
--debug	تشخيصات مفصّلة على stderr.	إيقاف

يستعرض log سلسلة الآباء المسجّلة بواسطة rdc repo commit، ويقرأ مرآة الحالة خارج المجلد حتى لا تُفتح أي نقطة إيداع أو تُثبَّت. وهو للقراءة فقط.

rdc repo merge

يدمج نقطة إيداع أو فرع مصدر في فرع عمل هدف، دون تعديل الهدف الحي في مكانه.

rdc repo merge --name <target> --from <source> -m <machine>
rdc repo merge --name <target> --from <source> --resolve theirs -m <machine>

الخيار	الوصف	الافتراضي
--name <name>	فرع العمل الهدف للدمج فيه. مطلوب.	مطلوب
--from <source>	نقطة الإيداع أو الفرع المصدر للدمج منه. مطلوب.	مطلوب
-m, --machine <name>	الجهاز الهدف. مطلوب.	مطلوب
--force	يُهدئ هدفاً مثبتاً أو قيد التشغيل أولاً ثم يدمج. لا يعدّل وصلاً حياً أبداً.	إيقاف
--resolve <ours|theirs>	دمج ثلاثي على مستوى الملفات: يطوي تغييرات المصدر على الهدف ملفاً بملف، مع الإبقاء على (ours) أو أخذ نسخة المصدر (theirs) للملفات المعدَّلة على الجانبين. أغفله للأخذ الكامل بنسخة الصورة من المصدر.	إيقاف
--base <guid>	نقطة الإيداع السلف المشترك للدمج الثلاثي (تُستخدم مع --resolve). الافتراضي هو أصل نقطة إيداع المصدر، أو نقطة الإيداع الحالية للهدف.	تلقائي
--debug	تشخيصات مفصّلة على stderr.	إيقاف

تُبنى النتيجة في نسخة رابط مرجعي وتُستبدل بصورة ذرية خلف علامة آمنة تجنباً للأعطال، لذا يظل الهدف الأصلي سليماً في حال انقطع الدمج. يُرفض الهدف المثبت أو قيد التشغيل ما لم يُعطَ --force، الذي يُوقف الهدف بصورة نظيفة قبل الاستبدال.

دون --resolve، الدمج هو أخذ كامل لنسخة الصورة من المصدر (يصبح الهدف هو المصدر). مع --resolve، يكون دمجاً ثلاثياً على مستوى الملفات مقابل الأصل المسجَّل لنقطة إيداع المصدر: تُؤخذ الملفات المعدَّلة على جانب واحد فقط من ذلك الجانب، وتُحلّ الملفات المعدَّلة على الجانبين وفق الراية. تُرفع تقارير بالمسارات المتعارضة.

rdc repo gc

يُعيد تدوير كائنات الإيداع الغير قابلة للتعديل على جهاز لا يصل إليها أي فرع أو HEAD.

rdc repo gc -m <machine>            # معاينة تجريبية (الافتراضي)
rdc repo gc --apply -m <machine>    # حذف الإيداعات غير القابلة للوصول

الخيار	الوصف	الافتراضي
-m, --machine <name>	الجهاز المراد جمع البيانات المهملة منه. مطلوب.	مطلوب
--apply	يحذف فعلياً الإيداعات غير القابلة للوصول (وإلا فهي معاينة تجريبية).	إيقاف
--debug	تشخيصات مفصّلة على stderr.	إيقاف

تُحسَب قابلية الوصول من التكوين المحلي (مخزن المراجع): مجموعة الإيداعات القابلة للوصول بمتابعة كل طرف فرع و HEAD أسفل سلسلة الآباء. الإيداعات الغير قابلة للتعديل على الجهاز خارج تلك المجموعة غير قابلة للوصول. لا يُجمَع كائن مثبت أو فرع عمل.

rdc repo fsck

يتحقق من مراجع التكوين مقابل الكائنات الموجودة على الجهاز.

rdc repo fsck -m <machine>

الخيار	الوصف	الافتراضي
-m, --machine <name>	الجهاز المراد فحصه. مطلوب.	مطلوب

يُبلّغ عن المراجع المتدلية (طرف فرع أو HEAD يشير إلى GUID لا كائن له على الجهاز) والإيداعات اليتيمة (إيداع غير قابل للتعديل على الجهاز لا يصله أي مرجع). وهو للقراءة فقط؛ استردّ الإيداعات اليتيمة بـ rdc repo gc --apply.

الفروع الغير قابلة للتعديل

rdc repo fork --immutable يضع علامة على الفرع الجديد بأنه للقراءة فقط عند الإنشاء، منتجاً قاعدة مكافئة لنقطة إيداع دون خطوة commit منفصلة.

rdc repo fork --parent <name> --tag <tag> --immutable -m <machine>

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

أمثلة

إيداع فرع عمل

$ rdc repo commit --name myapp:work --message "schema migration applied" -m server-1
Committed 4f3c2a1b9d8e: schema migration applied

إيداع مع مؤلف صريح

$ rdc repo commit --name myapp:work --message "nightly snapshot" --author ci-bot -m server-1
Committed 7a1b2c3d4e5f: nightly snapshot

تسمية فرع عند نقطة الإيداع الحالية

$ rdc repo branch --branch staging --name myapp:work
Branch "staging" -> 4f3c2a1b9d8e

استرجاع نقطة إيداع في فرع عمل جديد قابل للكتابة

$ rdc repo checkout --ref 4f3c2a1b9d8e --tag rollback-test -m server-1

استرجاع طرف فرع بالاسم

مع --from، تُحلّ قيمة --ref كاسم فرع على فرع العمل المعطى:

$ rdc repo checkout --ref staging --from myapp:work --tag staging-copy -m server-1

استعراض السجل

$ rdc repo log --name myapp:work -m server-1
commit 4f3c2a1b9d8e
  Author: ci-bot  Date: 2026-05-29T10:14:02Z
  schema migration applied
commit 9d8e7a1b2c3d
  Author: ci-bot  Date: 2026-05-28T22:01:55Z
  initial import

السجل بصيغة JSON

--json يُخرج الاستعراض المنظَّم، الأحدث أولاً:

$ rdc repo log --name myapp:work --json -m server-1
{
  "success": true,
  "start": "4f3c2a1b9d8e",
  "entries": [
    {
      "guid": "4f3c2a1b9d8e",
      "message": "schema migration applied",
      "author": "ci-bot",
      "parent": "9d8e7a1b2c3d",
      "committed_at": "2026-05-29T10:14:02Z",
      "immutable": true
    }
  ]
}

المقارنة بين نقطتَي إيداع

يعمل rdc repo diff بين أي نقطتَي إيداع لأنهما تشتركان في سلف ذي نسخ عند الكتابة. استرجع نقطة إيداع ثم قارنها بأخرى:

$ rdc repo checkout --ref 4f3c2a1b9d8e --tag review -m server-1
$ rdc repo diff --name review --base myapp:work -m server-1
M  db/schema.sql

1 file changed: 0 added, 1 modified, 0 deleted, 0 renamed

راجع rdc repo diff للمرجع الكامل للمقارنة.

دمج خط عمل مراجَع

$ rdc repo merge --name myapp:main --from myapp:work -m server-1
Merged myapp:work into myapp:main

الدمج في هدف قيد التشغيل

يُرفض الهدف المثبت أو قيد التشغيل ما لم يُعطَ --force، الذي يُهدئه أولاً:

$ rdc repo merge --name myapp:main --from myapp:work --force -m server-1
Merged myapp:work into myapp:main

الدمج الثلاثي على مستوى الملفات

فرعان (feature وhotfix) مسترجَعان من نفس نقطة الإيداع كلٌّ عدَّل بعض الملفات. --resolve theirs يطوي المصدر (hotfix) في الهدف (feature): تُؤخذ الملفات التي عدَّل جانبٌ واحدٌ منها من ذلك الجانب، وتُحلّ الملفات التي عدَّلها الجانبان لصالح المصدر. يُكتشف الأساس تلقائياً من السلف المشترك (أو حدّده بـ --base):

$ rdc repo merge --name myapp:feature --from myapp:hotfix --resolve theirs -m server-1
Merged myapp:hotfix into myapp:feature (three-way); 1 conflict(s) resolved --theirs: [config/app.yaml]

config/app.yaml عُدِّل على الجانبين وحُلّ لصالح المصدر؛ يُطبَّق ملف أضافه hotfix فقط، ويُحتفظ بملف عدَّله feature فقط. تُرفع تقارير بالمسارات المتعارضة حتى تتمكن من مراجعتها.

إنشاء قاعدة غير قابلة للتعديل مباشرة

$ rdc repo fork --parent myapp --tag baseline-v1 --immutable -m server-1

نقل الدلتا والسحب

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

لا تمرر قاعدة يدوياً في العادة. بعد دفع كامل، يحتفظ CLI بالصورة المدفوعة كقاعدة غير قابلة للتعديل على كلا الجهازين ويسجّلها، حتى يشحن الدفع التالي لذلك المستودع الدلتا فقط تلقائياً دون أي راية، حتى لفرع موجود بالفعل على الهدف. (إعادة الدفع الكاملة لفرع موجود تتطلب --force، لأن ذلك يستبدل الصورة بأكملها بدلاً من تطبيق دلتا متحقَّق منها.) مرّر --delta-base <guid> لتحديد قاعدة معينة، و--strategy <auto|physical|shared> للتحكم في كيفية اكتشاف الكتل المتغيرة (auto هو الخيار الصحيح في معظم الحالات).

# الدفع الأول هو نقل كامل؛ يحتفظ أيضاً بقاعدة قابلة لإعادة الاستخدام على كلا الطرفين.
$ rdc repo push --name myapp:work --to-machine backup-1 -m server-1

# بعد التغييرات المحلية، يشحن الدفع التالي الكتل المتغيرة فقط دون راية.
$ rdc repo push --name myapp:work --to-machine backup-1 -m server-1

# تحديد قاعدة صريحة (نقطة إيداع غير قابلة للتعديل موجودة على كلا الجهازين).
$ rdc repo push --name myapp:work --to-machine backup-1 --delta-base 4f3c2a1b9d8e -m server-1

# يعمل نقل الدلتا أيضاً عكسياً، بسحب الكتل المتغيرة فقط من جهاز المصدر.
$ rdc repo pull --name myapp:work --from-machine backup-1 --delta-base 4f3c2a1b9d8e -m server-1

# إعادة سحب مستودع محلي موجود (استبداله) بـ --force.
$ rdc repo pull --name myapp:work --from-machine backup-1 --force -m server-1

ينطبق نقل الدلتا فقط بين الأجهزة (جهاز بعيد مع قاعدة FIEMAP). الدفع إلى تخزين الكائنات السحابي ينقل الصورة الكاملة دائماً. يجب أن تكون القاعدة متطابقة تماماً على الطرفين، وهو ما يضمنه بالضبط نقطة إيداع غير قابلة للتعديل أو فرع --immutable.

مخطط JSON

rdc repo log --json يُغلّف نتيجة renet في الغلاف المعياري. السجل المُستعرض يعيش في entries، الأحدث أولاً:

الحقل	النوع	الوصف
success	boolean	ما إذا اكتمل الاستعراض.
start	string	GUID بدأ منه الاستعراض.
entries	array	كائن واحد لكل إيداع، الأحدث أولاً.
entries[].guid	string	GUID نقطة الإيداع.
entries[].message	string	رسالة الإيداع. محذوفة إذا كانت فارغة.
entries[].author	string	مؤلف الإيداع. محذوف إذا كان فارغاً.
entries[].parent	string	GUID نقطة الإيداع الأصل. محذوف عند الجذر.
entries[].committed_at	string	طابع زمني RFC 3339 للإيداع. محذوف إذا لم يُعيَّن.
entries[].immutable	boolean	ما إذا كانت نقطة الإيداع للقراءة فقط (دائماً true لنقطة إيداع حقيقية).

لحقول الغلاف وقواعد الاكتشاف التلقائي التي تُصدر JSON في البيئات غير الطرفية، راجع مرجع إخراج JSON.

القيود

• المراجع محلية. أسماء الفروع وHEAD وسجل المراجع موجودة في تكوين CLI، وليس على الجهاز. دفع نقطة إيداع إلى جهاز آخر يشحن كائن الإيداع وبياناته الوصفية داخل المجلد، لكن مرجع الفرع مفهوم خاص بالتكوين.
• نقطة الإيداع ترفض الوصل. هذا هو المقصود: عدم التعديل هو ما يجعل نقطة الإيداع مستقرة على مستوى البايتات. لتشغيل نقطة إيداع أو تعديلها، استرجعها أولاً في فرع عمل قابل للكتابة.
• دقة الدمج على مستوى الملفات، ليس الأسطر. كلٌّ من الأخذ الكامل بنسخة الصورة (بدون --resolve) والدمج الثلاثي لكل ملف (--resolve ours|theirs) مدعومان. يحلّ الدمج الثلاثي التعارضات ملفاً كاملاً في كل مرة وفق الراية؛ لا ينتج أجزاء على مستوى الأسطر أو علامات دمج داخل الملف.
• السجل هو سلسلة آباء. يستعرض rdc repo log الرابط الفردي parent المسجَّل وقت الإيداع. يتوقف عند الوصول إلى إيداع لا توجد بياناته الوصفية على الجهاز المستعلَم.

انظر أيضاً

• rdc repo diff. مقارنة على مستوى الملفات بين أي نقطتَي إيداع أو فرعين مرتبطين.
• المستودعات. إنشاء المستودعات وتفريعها وتثبيتها وتشغيلها.