التفريع: الحفظ والتراجع

نسخ إصدارات مستودعاتك كما تُصدِر الكود. commit يُجمّد نسخة في صورة ثابتة؛ branch يُسمّيها؛ checkout يُحوّل أي التزام إلى نسخة قابلة للكتابة من جديد. في هذا الدرس نحفظ حالة معروفة الجودة، نحذف جدول PostgreSQL حقيقيًا، ونُعيد كل صف في ثوانٍ.

شاهد الدرس التعليمي

النموذج

Commits, branches, checkout

الالتزامات لا تتغير أبدًا: ترفض حتى التحميل. النسخ لا تنتظر: checkout هو استنساخ رابط فوري تقريبًا. النموذج الذهني الكامل موجود في دليل التفريع.

إنشاء نقطة تفتيش

ملف علامة يجعل الإصدار مرئيًا، وقاعدة بيانات حقيقية تجعل التراجع ذا معنى: جدول customers يحتوي على ثلاثة صفوف.

rdc term connect --machine <machine-name> --repository app:work --command 'echo v1 > version.txt && cat version.txt'

اكتب الإصدار الأول من حالتك في الـ fork العامل.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

يُشغّل الـ fork أيضاً قاعدة بيانات PostgreSQL حقيقية: جدول customers يحتوي على ثلاثة صفوف.

rdc repo commit --name app:work --message 'v1 baseline' --machine <machine-name>

نفّذ commit للـ fork العامل: حالة الـ repository الكاملة، بما في ذلك قاعدة البيانات، تُجمَّد في لقطة ثابتة مسمّاة.

rdc repo branch --branch stable --name app:work

أنشئ branch يشير إلى الـ commit، اسم مقروء للحالة المجمّدة.

يلتقط الالتزام كل شيء: الملفات وبيانات PostgreSQL. الفرع stable يُسمّي تلك الحالة المجمّدة الآن.

مواصلة العمل

rdc term connect --machine <machine-name> --repository app:work --command 'echo v2 > version.txt && cat version.txt'

واصل العمل: الـ fork يتغير، والسجل المُثبَّت يبقى مجمّداً.

الكارثة

تغيير محفوف بالمخاطر يحذف الجدول. ثم يُؤكد الاستعلام أن الضرر حقيقي.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "DROP TABLE customers"'

التغيير المحفوف بالمخاطر يحذف جدول customers في الـ fork العامل.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

الاستعلام عن الجدول الآن يفشل: relation "customers" غير موجودة. البيانات اختفت فعلاً من الـ fork العامل.

ERROR: relation "customers" does not exist. ثلاثة صفوف، اختفت. في الحياة الفعلية هذه اللحظة التي يغوص فيها قلبك؛ هنا هي الإعداد للحل المُنتظر.

rdc repo commit --name app:work --message 'v2 risky change' --machine <machine-name>

نفّذ commit للحالة الجديدة أيضاً، بما في ذلك الجدول المحذوف. السجل ينمو مثل git log.

rdc repo log --name app:work --machine <machine-name>

تصفّح سجل الـ commits باستخدام repo log، الرسائل والمؤلفون والأصول.

السجل يُثبت ما حدث فعلًا، بما في ذلك الحالة المكسورة: v2 risky change في الأعلى، v1 baseline تحتها.

التراجع في ثوانٍ

rdc repo checkout --ref stable --from app:work --tag rollback --machine <machine-name>

استخرج الـ branch الثابت في fork قابل للكتابة جديد، شبه فوري بفضل copy-on-write.

rdc repo up --name app:rollback --machine <machine-name>

شغّل الـ fork الخاص بالاسترجاع، يعمل جانباً من الـ fork العامل.

rdc term connect --machine <machine-name> --repository app:rollback --command 'cat version.txt'

اقرأ ملف العلامة في الـ fork الخاص بالاسترجاع: الإصدار الأول، تماماً كما تم commit-ه.

rdc term connect --machine <machine-name> --repository app:rollback --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

استعلم عن جدول customers في الـ fork الخاص بالاسترجاع: ثلاثة صفوف، تماماً كما تم commit-ها. الاسترجاع أعاد قاعدة البيانات، ليس الملفات وحدها.

نسخة التراجع تقرأ v1، وجدول customers عاد بثلاثة صفوفه كاملةً. استُعيدت قاعدة البيانات، لا الملفات وحدها. لم يُكتَب على شيء: النسخة الجارية ما زالت تحمل الإصدار الثاني، ويفتح الفيديو كليهما في VS Code ليُثبت ذلك.

التالي: الهجرة المباشرة.