سير عمل Git لمطوري C#: من الفوضى إلى النظام

سير عمل Git لمطوري C#: كيف تتوقف عن الخوف من الدمج وتبدأ في العيش

هل سبق لك أن أمضيت نصف يوم في محاولة فهم من ومتى أعاد كتابة طريقتك المفضلة CalculateOrderTotal()؟ أو ربما قمت بدفع "إصلاح عاجل" مباشرة إلى master، ثم تعطل الإنتاج مع خطأ NullReferenceException؟ مألوف؟ مرحبًا بك في نادي مطوري C# الذين يحاولون البقاء على قيد الحياة في فوضى Git بدون سير عمل واضح.

إذا كنت تعتقد أن Git هو مجرد git add . و git push، فأنت تفتقد الشيء الرئيسي. سير عمل Git الصحيح ليس نقاشًا دينيًا، بل أداة توفر الأعصاب والوقت والمال. خاصة في عالم C#، حيث لدينا حلول (.sln)، ومشاريع (.csproj)، والكثير من حزم NuGet التي تحب التعارض.

في هذه المقالة، سأعرض لكم استراتيجيات تفرع عملية، وأمثلة كود حقيقية لـ C#، وسأخبركم كيف تؤتمتوا الروتين. هيا بنا!

لماذا تتطلب مشاريع C# نهجًا خاصًا في Git؟

عندما تعمل مع C#، فأنت تتعامل ليس فقط مع ملفات نصية. لديك:

• الحل (.sln) — ملف واحد يشير إلى جميع المشاريع. إذا أضاف مطوران مشروعًا جديدًا في نفس الوقت، فإن تعارض الدمج مضمون.
• ملفات .csproj — ملفات XML يتم تحديثها عند إضافة حزم NuGet أو تغيير Target Framework. دمج هذه الملفات يدويًا هو ألم.
• appsettings.json و web.config — ملفات تكوين غالبًا ما تحتوي على سلاسل الاتصال. لا يجب دفعها، لكن الجميع ينسى.
• مجلدات bin/ و obj/ — إذا قمت بدفعها مرة واحدة، سيلعنك زملاؤك إلى الأبد.

لذلك، يجب أن يكون سير عمل Git الخاص بك لمشاريع C# مدروسًا بدقة. ويبدأ بـ .gitignore الصحيح.

الخطوة 1: إعداد .gitignore لـ C#

يمكن تنزيل .gitignore القياسي لـ C# من GitHub/gitignore، لكنني سأضيف بعض الأسطر المهمة التي غالبًا ما يتم تجاهلها:

# ملفات التكوين التي تحتوي على أسرار (لا تدفع!)appsettings.Development.jsonappsettings.Local.jsonsecrets.json

# الملفات التي تم إنشاؤها بواسطة ReSharper أو Rider*.DotSettings.user*.DotSettings

# حزم NuGet (ذاكرة التخزين المؤقت)packages/*.nupkg

# نتائج الاختباراتTestResults/*.trx

# مجلدات Visual Studio.vs/*.suo*.user*.sln.docstates

لماذا هذا مهم؟ تخيل أنك تدفع appsettings.Development.json مع سلسلة اتصال محلية بقاعدة البيانات. زميلك يسحب التغييرات، ويحدث تعطل لتطبيقه لأنه لا يملك قاعدة البيانات تلك. يبدو الأمر كخطأ بسيط، لكنه يهدر ساعة من وقت العمل.

اختيار استراتيجية التفرع لفريق C#

هناك العديد من سير عمل Git الشائعة. لمشاريع C#، أوصي باستراتيجيتين رئيسيتين: Git Flow و Trunk-Based Development. دعنا نناقشهما بالأمثلة.

الخيار 1: Git Flow (الكلاسيكي للمشاريع الكبيرة)

Git Flow يشبه SOLID بالنسبة لـ Git. إنه مثالي عندما يكون لديك إصدارات واضحة (مثل الإصدار 2.1.0، 2.2.0). تبدو الفروع كالتالي:

• main — فقط الكود المستقر.
• develop — فرع التكامل.
• feature/XXX-123-add-new-api — الميزات من develop.
• release/2.1.0 — التحضير للإصدار.
• hotfix/2.0.1-critical-bug — الإصلاحات العاجلة من main.

مثال لـ C#: أنت تعمل على ميزة جديدة "حساب الخصم باستخدام كود ترويجي".

# إنشاء ميزة من developgit checkout developgit pullgit checkout -b feature/ABC-42-add-promo-discount

# كتابة الكود في C#// DiscountService.cspublic class DiscountService{    public decima