سير عمل Git لمطوري Kotlin: كيف لا تفسد المشروع

مقدمة: لماذا Git ليس مجرد "git push"

إذا كنت تكتب بلغة Kotlin، فأنت تعلم كم هي لغة ممتعة: موجزة، آمنة، حديثة. ولكن حتى أكثر الأكواد أناقة تتحول إلى فوضى إذا لم يكن لدى الفريق سير عمل Git واضح. هل سبق لك أن حاولت دمج فرع حيث قام أحد المطورين بإعادة تسمية نصف الملفات، وآخر قام بإعادة هيكلة coroutines، وثالث قام عن طريق الخطأ برفع ملف `build.gradle.kts` بمسارات محلية؟

سير عمل Git لمطوري Kotlin ليس مجرد قواعد مملة. إنه درعك ضد التعارضات، وضامن استقرار `main`، وطريقة لتجنب إضاعة يوم الاثنين في معرفة "من أفسد ماذا". في هذه المقالة، سنحلل مسار عمل حقيقي: من إعداد `.gitignore` الخاص بـ Kotlin إلى الفحوصات التلقائية عبر Gradle و pre-commit hooks.

هيا بنا لننظم المستودع!

1. الأساسيات: إعداد المستودع لـ Kotlin

1.1. ملف .gitignore الصحيح لـ Kotlin

أول شيء يجب على الجميع فعله هو نسيان نسخ القوالب من GitHub. في مشاريع Kotlin، هناك مجلدات محددة لا يجب أن تدخل المستودع. إليك الحد الأدنى من المجموعة الأساسية:

# Kotlin & JVM\n*.class\n*.jar\n*.war\n*.ear\nbuild/\n!gradle/wrapper/gradle-wrapper.jar\n\n# IDE (IntelliJ IDEA)\n.idea/\n*.iml\n*.iws\nout/\n\n# OS\n.DS_Store\nThumbs.db\n\n# Gradle\n.gradle/\nlocal.properties\n

لاحظ: نحن نستبعد صراحة `.idea/` - هذا سينقذ الزملاء من التعارضات في إعدادات IDE. و `local.properties` (مسار SDK) هو شيء محلي بحت.

1.2. خطافات Git: المدقق الشخصي الخاص بك

سير عمل Git لمطوري Kotlin لا يمكن تصوره بدون pre-commit hooks. يتم تشغيلها قبل إنشاء commit. الأداة الأكثر شيوعًا هي pre-commit مع إضافات لـ Kotlin.

مثال على ملف الإعداد `.pre-commit-config.yaml`:

repos:\n  - repo: https://github.com/pre-commit/mirrors-ktlint\n    rev: v0.50.0\n    hooks:\n      - id: ktlint\n        args: ["--format"]\n\n  - repo: https://github.com/detekt/detekt\n    rev: v1.23.1\n    hooks:\n      - id: detekt\n

الآن، قبل كل commit، سيقوم `ktlint` بتنسيق الكود، وسيتحقق `detekt` من وجود أخطاء محتملة. لا مزيد من "نسيت تشغيل المدقق"!

2. استراتيجية التفرع: اختر سير العمل الخاص بك

2.1. Git Flow - الكلاسيكية للمشاريع الكبيرة

بالنسبة لمشاريع Kotlin المتجانسة أو المشاريع ذات الإصدارات الصارمة، فإن Git Flow الكلاسيكي مناسب. الفروع الرئيسية:

\n
• main - فقط الكود المستقر الموجود في الإنتاج.
\n
• develop - فرع التكامل للتطوير.
\n
• feature/* - كل ميزة جديدة.
\n
• release/* - التحضير للإصدار (إصلاح الأخطاء، تحديث الإصدار).
\n
• hotfix/* - إصلاحات عاجلة في الإنتاج.
\n

مثال لـ Kotlin: تقوم بتطوير وظيفة جديدة لمعالجة coroutines. تقوم بإنشاء فرع feature/coroutine-flow، وتعمل عليه، ثم تدمجه في develop. عندما تتراكم الميزات الكافية للإصدار، تقوم بإنشاء release/2.1.0، وتصلح الأخطاء هناك، وعندها فقط تدمجه في main.

2.2. GitHub Flow - لـ CI/CD والإصدارات السريعة

إذا كنت تكتب خدمة مصغرة على Ktor أو Spring Boot وتنشر يوميًا، فإن Git Flow سيكون مبالغًا فيه. استخدم GitHub Flow:

\n
• فرع main دائمًا جاهز للنشر.
\n
• كل مهمة - feature/الاسم.
\n
• بعد الانتهاء - Pull Request، مراجعة الكود، اختبارات تلقائية، دمج في main.
\n
• مباشرة بعد الدمج - النشر (من الناحية المثالية).
\n

مناسب تمامًا لمشاريع Kotlin ذات التغطية الجيدة للاختبارات.

2.3. Trunk-based - للشجعان

هل تعمل في شركة ناشئة أو تعمل على مشروع شخصي؟ Trunk-based (الجميع يدمج في main بcommits قصيرة) يسرع التطوير، ولكنه يتطلب انضباطًا عاليًا واختبارات ممتازة.