Swift डेवलपर्स के लिए Git वर्कफ़्लो: कमिट से रिलीज़ तक बिना दर्द के

Swift डेवलपर्स के लिए Git वर्कफ़्लो: कैसे पागल न हों और प्रोडक्शन को न तोड़ें

ईमानदारी से स्वीकारो: तुमने कितनी बार मुख्य ब्रांच में "fix" या "правки" संदेश वाला कमिट देखा है? और कितनी बार मर्ज कॉन्फ्लिक्ट ने तुम्हारे जीवन का एक घंटा ले लिया, क्योंकि किसी ने कमिट करने से पहले pull करना भूल गया? यदि तुम एक Swift-डेवलपर हो जो एक टीम में काम करता है - शौकिया प्रोजेक्ट से लेकर "Тинькофф" या "Яндекс.Карты" स्तर के बड़े एप्लिकेशन तक - देर-सबेर तुम Git में अराजकता का सामना करोगे।

अच्छी खबर: Swift डेवलपर्स के लिए सही git वर्कफ़्लो रिपॉजिटरी को युद्ध के मैदान से एक सुव्यवस्थित प्रणाली में बदल देता है। इस लेख में, हम चर्चा करेंगे कि iOS और macOS प्रोजेक्ट्स के लिए कौन से दृष्टिकोण वास्तव में काम करते हैं, बिना दर्द के कोड रिव्यू कैसे सेट करें, और CI/CD को पहले दिन से तुम्हारी प्रक्रिया में क्यों शामिल किया जाना चाहिए।

चलो शुरू करते हैं!

1. मानक git वर्कफ़्लो Swift के तहत अक्सर क्यों टूट जाता है

Swift-प्रोजेक्ट्स की अपनी विशिष्टताएँ होती हैं: Xcode प्रोजेक्ट्स, स्टोरीबोर्ड (या SwiftUI), Podfile / SPM निर्भरताएँ, और बाइनरी एसेट्स (चित्र, फ़ॉन्ट)। यदि सामान्य वेब प्रोजेक्ट में मर्ज कॉन्फ्लिक्ट 30 सेकंड में हल हो जाता है, तो iOS में .xcodeproj या .xcworkspace के कारण इसमें आधा घंटा लग सकता है।

मुख्य समस्याएँ जो एक अच्छा Swift डेवलपर्स के लिए git वर्कफ़्लो हल करता है:

\n
• .xcodeproj में कॉन्फ्लिक्ट - जब दो डेवलपर एक साथ फ़ाइलें जोड़ते हैं;
\n
• गंदा कमिट इतिहास - "WIP", "правки", "और правки";
\n
• कोड रिव्यू का अभाव - बग जो main में पहुँच जाते हैं और बिल्ड को तोड़ देते हैं;
\n
• टूटा हुआ CI - टेस्ट पास नहीं होते, और रिलीज़ तक किसी को पता नहीं चलता।
\n

2. Git Flow बनाम GitHub Flow: Swift-प्रोजेक्ट के लिए क्या चुनें?

क्लासिक Git Flow (ब्रांचेज़ develop, release, hotfix, feature) एक शक्तिशाली लेकिन भारी दृष्टिकोण है। यह स्पष्ट रिलीज़ चक्र वाले बड़े प्रोजेक्ट्स के लिए आदर्श है, उदाहरण के लिए, जब तुम संस्करण 1.0, 1.1, 2.0 और सख्त QA के साथ बैंक के लिए एप्लिकेशन बना रहे हो।

दूसरी ओर, GitHub Flow (सभी परिवर्तन फ़ीचर-ब्रांचेज़ और main में Pull Request के माध्यम से) स्टार्टअप्स और उन टीमों के लिए एक हल्का विकल्प है जो हर दिन डिप्लॉय करते हैं। यह Swift-प्रोजेक्ट्स के लिए भी काम करता है, लेकिन कुछ शर्तों के साथ: यदि तुम्हारे पास स्टोरीबोर्ड या XIB हैं, तो main में मर्ज यथासंभव साफ होना चाहिए।

Swift में Git Flow का उपयोग कब करें

\n
• लंबे रिलीज़ चक्र वाले बड़े एंटरप्राइज़ प्रोजेक्ट्स (जैसे, बैंक, टेलीमेडिसिन);
\n
• कई समानांतर संस्करण (v1.0 समर्थन में, v2.0 विकास में);
\n
• main ब्रांच की स्थिरता के लिए सख्त आवश्यकताएँ।
\n

Swift में GitHub Flow का उपयोग कब करें

\n
• तेज़ डिप्लॉय वाले स्टार्टअप और मध्यम प्रोजेक्ट्स;
\n
• 10 लोगों तक की टीमें;
\n
• SwiftUI पर प्रोजेक्ट्स (रेफरेंस में कम कॉन्फ्लिक्ट)।
\n

व्यक्तिगत रूप से, मैं हाइब्रिड की सलाह देता हूँ: सरलीकृत develop-ब्रांच के साथ Git Flow - यह मध्यम जटिलता के Swift-प्रोजेक्ट्स के लिए आदर्श संतुलन है।

3. फ़ीचर-ब्रांच सेट करना: नियम जो नसों को बचाएंगे

प्रत्येक नई सुविधा develop (या main, यदि तुम GitHub Flow का उपयोग कर रहे हो) से एक अलग ब्रांच है। यहाँ एक सरल टेम्पलेट है जिसका मैं अपने प्रोजेक्ट्स में उपयोग करता हूँ:

git checkout develop\ngit pull --rebase origin develop\ngit checkout -b feature/SPT-123-login-screen

महत्वपूर्ण: ब्रांच बनाने से पहले हमेशा rebase करें ताकि पुराने कमिट अपने साथ न खींचें। और प्रीफ़िक्स के बारे में मत भूलें: feature/, bugfix/, hotfix/, release/। इससे इतिहास में खोज आसान हो जाती है।

develop के साथ कितनी बार सिंक्रोनाइज़ करें

दिन में एक बार या कमिट करने से पहले rebase करें। इससे कॉन्फ्लिक्ट कम होते हैं। कमांड:

git checkout feature/SPT-123-login-screen\ngit rebase develop

यदि कॉन्फ्लिक्ट अपरिहार्य हैं (जैसे, .xcodeproj के कारण), तो git mergetool