Kotlin डेवलपर्स के लिए Git वर्कफ़्लो: प्रोजेक्ट को कैसे न तोड़ें

परिचय: Git सिर्फ 'git push' क्यों नहीं है

यदि आप Kotlin में लिखते हैं, तो आप जानते हैं कि यह भाषा कितनी सुखद है: संक्षिप्त, सुरक्षित, आधुनिक। लेकिन सबसे सुंदर कोड भी अराजकता में बदल जाता है यदि टीम में कोई स्पष्ट Git वर्कफ़्लो नहीं है। क्या आपने कभी एक ऐसी ब्रांच को मर्ज करने की कोशिश की है, जहाँ एक डेवलपर ने आधी फ़ाइलों का नाम बदल दिया, दूसरे ने कोरूटीन को रिफैक्टर किया, और तीसरे ने गलती से स्थानीय पथों के साथ `build.gradle.kts` अपलोड कर दिया?

Kotlin डेवलपर्स के लिए Git वर्कफ़्लो सिर्फ उबाऊ नियम नहीं है। यह संघर्षों से आपकी ढाल, स्थिर `main` का गारंटर और सोमवार को 'किसने क्या तोड़ा' का पता लगाने में समय बर्बाद न करने का तरीका है। इस लेख में, हम एक वास्तविक पाइपलाइन पर चर्चा करेंगे: Kotlin के लिए `.gitignore` सेट करने से लेकर Gradle और pre-commit हुक्स के माध्यम से स्वचालित जाँच तक।

चलिए रिपॉजिटरी में व्यवस्था लाते हैं!

1. आधार: Kotlin के लिए रिपॉजिटरी सेट करना

1.1. Kotlin के लिए सही .gitignore

पहली चीज़ जो प्रत्येक को करनी चाहिए वह है 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-हुक्स: आपका व्यक्तिगत लिंटर

Kotlin डेवलपर्स के लिए Git वर्कफ़्लो pre-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

अब प्रत्येक कमिट से पहले `ktlint` कोड को फ़ॉर्मेट करेगा, और `detekt` संभावित बग्स की जाँच करेगा। अब और 'लिंटर चलाना भूल गया' नहीं!

2. ब्रांचिंग रणनीति: अपना वर्कफ़्लो चुनें

2.1. Git Flow - बड़े प्रोजेक्ट्स के लिए क्लासिक

Kotlin मोनोलिथ या सख्त रिलीज़ वाले प्रोजेक्ट्स के लिए क्लासिक Git Flow उपयुक्त है। मुख्य ब्रांचेज़:

\n
• main - केवल स्थिर कोड जो प्रोडक्शन में है।
\n
• develop - डेवलपमेंट के लिए एकीकरण ब्रांच।
\n
• feature/* - प्रत्येक नई सुविधा।
\n
• release/* - रिलीज़ की तैयारी (बग फिक्स, वर्जन अपडेट)।
\n
• hotfix/* - प्रोडक्शन में तत्काल सुधार।
\n

Kotlin के लिए उदाहरण: आप कोरूटीन प्रोसेसिंग का एक नया फंक्शन विकसित कर रहे हैं। आप 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 - बहादुरों के लिए

स्टार्टअप में काम कर रहे हैं या pet-प्रोजेक्ट बना रहे हैं? Trunk-based (हर कोई छोटे कमिट्स के साथ main में कमिट करता है) डेवलपमेंट को गति देता है, लेकिन