إدارة التفرع، وطلبات السحب، وحل النزاعات

مكتمل

يضيف مطوران أعمدة إلى نفس الجدول في نفس اليوم. أحدهما يدفع للإنتاج، والآخر يتبعه بعد ساعة ويكتب فوق التغيير الأول. هل يبدو هذا مألوفا؟ توجد برامج التفرع، وطلبات السحب، وحل النزاعات لمنع هذا النوع من التصادم بالضبط.

استخدم فروع الميزات لتغييرات قواعد البيانات

تتبع استراتيجية التفرع البسيطة لمشاريع قواعد بيانات SQL ثلاثة مبادئ:

• ينشئ فرعا للميزات لكل تغيير، سواء كان جداول جديدة، أو إصلاحات للأخطاء، أو تحديثات إجراءات مخزنة.
• يدمج تفرعات الميزات إلى طلبات السحب الرئيسية من خلال الطلبات.
• دائما أبق السفينة الرئيسية في حالة قابلة للنشر.

عندما تبدأ تغيير قاعدة البيانات، قم بالتفرع من main. عملك معزول عن كل ما هو جار. تقوم بتعديل الملفات ذات الصلة .sql ، وبما أن لكل كائن ملفه الخاص، فإن التزاما يضيف عمودا للمواد Customers فقط لا Tables/Customers.sql يلمس شيئا آخر.

git checkout -b feature/add-customer-email

بعد إكمال التغييرات، ادفع الفرع إلى المستودع البعيد:

git add .
git commit -m "Add Email column to Customers table"
git push origin feature/add-customer-email

راجع التغييرات مع طلبات السحب

طلب السحب يشير إلى أن تغييراتك جاهزة لرؤية عينين ثانية. نظرا لأن مشاريع قاعدة بيانات SQL تخزن كل كائن في ملف منفصل، فإن الفرق يظهر T-SQL الدقيق الذي تغير. الملفات المنفصلة تجعل مراجعة الأمر أسهل بكثير من سكريبت ترحيل مكون من 500 سطر يمزج بين تعديلات غير ذات صلة.

يجب أن تجيب طلبات السحب لتغييرات قاعدة البيانات على أسئلة مثل:

• هل يتعطل تغيير المخطط الاستعلامات أو الإجراءات المخزنة الموجودة؟
• هل قواعد التسمية متوافقة مع بقية المشروع؟
• هل يتطلب التغيير تحديثا موفقا لسكريبت ما بعد النشر؟
• هل يسبب التغيير فقدان البيانات أم يتطلب ترحيل البيانات؟

في Azure DevOps، أنشئ طلب سحب من فرع ميزة إلى main قسم المستودعات . في GitHub، استخدم تبويب طلبات السحب .

ربط طلبات السحب ببناءات CI

طلب سحب مع بناء أخضر يمنح المراجعين الثقة. قم بتكوين PR لتفعيل بناء CI يترجم مشروع قاعدة بيانات SQL. إذا فشل البناء بسبب مرجع معطل، خطأ في النحو، أو اعتماد غير محلول، يتم اكتشاف المشكلة قبل أن تصل إلى النسخة الرئيسية.

في Azure DevOps، تقوم بتكوين تفعيل بناء CI من خلال سياسة فرع التحقق من صحة البناء . في GitHub، تقوم بإعداد سير عمل يتم تفعيله عند pull_request الأحداث التي تستهدف الفرع main .

حل تعارضات الدمج في مشاريع قواعد بيانات SQL

تحدث التعارضات عندما يقوم فرعان بتعديل نفس الملف بطرق لا يستطيع Git تصحيحها بنفسه. في مشاريع قواعد البيانات، السيناريو الشائع هو قيام مطورين بتحرير نفس CREATE TABLE الجملة. أحدهما يضيف عمودا Phone ، والآخر يضيف Address، وكلاهما يلمس نفس المنطقة من الملف.

لحل النزاع:

1. اسحب أحدث التغييرات من main فرع الميزات الخاص بك:

   git checkout feature/add-customer-phone
   git pull origin main
   

2. Git يحدد الأقسام المتضاربة في الملف. افتح الملف وراجع كلا النسختين.

3. عدل الملف ليشمل كلا التغييرين في الصياغة الصحيحة.

4. ضع علامة على النزاع كحل والتزم:

   git add Tables/Customers.sql
   git commit -m "Resolve merge conflict: include both Phone and Address columns"
   

نصيحة

تقليل تكرار تعارضات الدمج من خلال إبقاء فروع الميزات قصيرة الأمد. أعد دمجها فور main اكتمال التغيير ومراجعته. الفروع طويلة الأمد التي تختلف بشكل main كبير عنها أصعب في الاندماج.

التحقق بعد حل النزاعات

دمج النص النظيف لا يضمن وجود مخطط صالح. افترض أن فرعا ما يعيد تسمية عمود بينما يضيف فرع آخر إجراء مخزنا يشير إلى اسم العمود القديم. Git يدمج الملفات بدون شكوى، لكن المشروع معطل. دائما أعد البناء بعد حل النزاعات:

dotnet build MyDatabaseProject.sqlproj

📝 البناء الناجح يؤكد أن مراجع الكائنات سليمة وأن بناء جملة T-SQL صحيح بعد الدمج.

النقاط الموجزة الأساسية

استخدم فروع الميزات قصيرة العمر لعزل تغييرات قاعدة البيانات، ودمجها مرة أخرى مع main طلبات سحب عبر الاستخدام. قم بتكوين بناءات CI كاختبارات طلب سحب بحيث تحقق نجاح dotnet build كل تغيير مقترح قبل الدمج. عادة ما تكون تعارضات الدمج في .sql الملفات بسيطة لأن كل ملف يحتوي على إعلان كائن واحد. دائما أعد بناء المشروع بعد حل تعارضات الدمج للتحقق من أن جميع مراجع الكائنات سليمة. بعد ذلك، تتعلم كيف تكتشف متى تخرج قاعدة البيانات الحية عن التزامن مع مشروعك.