Hotfix Branch: यह क्या है, मोबाइल डेवलपमेंट में कैसे बनाएं और उपयोग करें

Hotfix Branch क्या है?

Hotfix Branch Git में एक अस्थायी ब्रांच है जो सक्रिय प्रोडक्शन वातावरण में गंभीर दोषों के त्वरित सुधार के लिए बनाई जाती है। Feature ब्रांचों के विपरीत, जो develop से शाखा करती हैं और कई दिनों या हफ्तों तक चलती हैं, hotfix main/master से बनाई जाती है और बग को ठीक करने के लिए जितनी आवश्यक हो उतनी ही समय तक मौजूद रहती है।

Hotfix का मुख्य उद्देश्य गंभीर त्रुटि का पता लगने और प्रोडक्शन में उसे ठीक करने के बीच के समय को न्यूनतम करना है। टीम वर्तमान स्प्रिंट या रिलीज़ चक्र के समाप्त होने की प्रतीक्षा नहीं करती, बल्कि तुरंत पैच जारी करती है। यह विशेष रूप से मोबाइल एप्लिकेशन के लिए महत्वपूर्ण है, जहां एक गंभीर बग उपयोगकर्ताओं को ब्लॉक कर सकता है और उनके जाने का कारण बन सकता है।

Google Play Console के अनुसार, Google Play में अपडेट समीक्षा का औसत समय 2 से 24 घंटे है। App Store के लिए, एक्सप्रेस समीक्षा में 1 से 4 घंटे लग सकते हैं। Hotfix ब्रांचें समीक्षा पूरी होने से पहले सुधार तैयार करने और अनुमोदन के तुरंत बाद इसे जारी करने की अनुमति देती हैं।

Hotfix कैसे काम करता है

Hotfix प्रक्रिया में तीन चरण होते हैं: main से ब्रांच बनाना, सुधार करना, और main और develop में वापस मर्ज करना। सामान्य सुधार से मुख्य अंतर यह है कि hotfix हमेशा दोनों ब्रांचों में मर्ज किया जाता है, ताकि अगले रिलीज़ में सुधार खो न जाए।

टीम को hotfix में नई कार्यक्षमता या रीफैक्टरिंग नहीं शामिल करनी चाहिए। केवल लक्षित सुधार, जो गंभीर समस्या को हल करने के लिए न्यूनतम आवश्यक हो। इस नियम से किसी भी विचलन से रिग्रेशन का जोखिम बढ़ता है और पैच जारी करने में देरी होती है।

Hotfix की आवश्यकता कब होती है

Hotfix तीन परिदृश्यों में आवश्यक है: एक गंभीर बग उपयोगकर्ताओं को ब्लॉक करता है (क्रैश, डेटा हानि), एक सुरक्षा कमजोरी को तत्काल बंद करने की आवश्यकता है, या महत्वपूर्ण व्यावसायिक तर्क टूट गया है (भुगतान, प्रमाणीकरण)। यदि बग गंभीर नहीं है, तो इसे develop के माध्यम से नियमित रिलीज़ चक्र में ठीक किया जा सकता है।

मोबाइल एप्लिकेशन के लिए, hotfix में सर्वर-साइड परिवर्तन भी शामिल हो सकते हैं यदि आर्किटेक्चर रिमोट फीचर टॉगलिंग (feature flags) की अनुमति देता है। इस मामले में, hotfix ब्रांच न्यूनतम हो सकती है या यदि सुधार सर्वर साइड पर किया जा सकता है तो इसकी बिल्कुल आवश्यकता नहीं होती।

ब्रांचिंग मॉडल और Hotfix का स्थान

सभी ब्रांचिंग मॉडल hotfix ब्रांचों का समर्थन नहीं करते। पारंपरिक Git Flow hotfix को एक पूर्ण ब्रांच प्रकार के रूप में शामिल करता है, जबकि अधिक आधुनिक दृष्टिकोण (GitHub Flow, Trunk-based) आपातकालीन सुधारों को अलग तरीके से संभालते हैं।

Git Flow और Hotfix

Git Flow एकमात्र मॉडल है जहां hotfix feature और release के समान एक अंतर्निहित ब्रांच प्रकार है। Git Flow में, hotfix main से बनाया जाता है, और पूरा होने पर, main (संस्करण टैग के साथ) और develop दोनों में मर्ज किया जाता है। यह सुनिश्चित करता है कि सुधार अगले रिलीज़ में खो न जाए।

GitHub Flow और Trunk-based

GitHub Flow hotfix के लिए अलग ब्रांच प्रकार का उपयोग नहीं करता। इसके बजाय, डेवलपर main से एक सामान्य feature ब्रांच बनाता है, सुधार करता है, और Pull Request खोलता है। समीक्षा और CI जांच के बाद, ब्रांच main में मर्ज होती है और तुरंत तैनात होती है। लाभ सरलता है, नुकसान तत्काल सुधार के लिए समर्पित चैनल का अभाव है।

Trunk-based विकास hotfix को (गंभीर मामलों के लिए) सीधे main में कमिट के माध्यम से संभालता है, जिसमें अनिवार्य पोस्ट-फैक्टम समीक्षा होती है। इस दृष्टिकोण के लिए उच्च टीम अनुशासन और विश्वसनीय स्वचालित परीक्षणों की आवश्यकता होती है, क्योंकि परिवर्तन तुरंत प्रोडक्शन में चले जाते हैं।

Hotfix Branch कैसे बनाएं

Hotfix बनाना मुख्य ब्रांच पर स्विच करने और hotfix/ उपसर्ग के साथ एक नई ब्रांच बनाने से शुरू होता है। आइए मोबाइल एप्लिकेशन में एक गंभीर बग को ठीक करने के उदाहरण के साथ चरण-दर-चरण प्रक्रिया देखें।

main से ब्रांच बनाना

पहला कदम — main पर स्विच करें और सुनिश्चित करें कि ब्रांच अद्यतित है। फिर एक स्पष्ट नाम के साथ hotfix ब्रांच बनाएं जो सुधार की प्रकृति को दर्शाता हो।

# main पर स्विच करें और नवीनतम परिवर्तन प्राप्त करें
git checkout main
git pull origin main

# hotfix ब्रांच बनाएं
git checkout -b hotfix/crash-on-login

ब्रांच बनाने के बाद, आप सुधार कर सकते हैं। याद रखना महत्वपूर्ण है: hotfix में न्यूनतम संख्या में परिवर्तन होने चाहिए। कोड को रीफैक्टर न करें या नई सुविधाएँ न जोड़ें — केवल लक्षित सुधार जो समस्या को हल करता हो।

सुधार को कमिट करना

Hotfix में कमिट में एक सूचनात्मक संदेश होना चाहिए जो समस्या और उसके समाधान का स्पष्ट रूप से वर्णन करता हो। प्रारूप: प्रकार(क्षेत्र): संक्षिप्त विवरण + tracker में कार्य का लिंक।

# परिवर्तित फ़ाइलें जोड़ें
git add src/ui/login/LoginActivity.kt

# विवरण के साथ कमिट बनाएं
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

कमिट संदेश में समस्या का विवरण और कार्य का लिंक होना चाहिए। इससे इतिहास में खोज सरल हो जाती है और सहकर्मियों को यह समझने में मदद मिलती है कि क्या ठीक किया गया और क्यों। मोबाइल प्रोजेक्ट के लिए, उस एप्लिकेशन संस्करण को भी शामिल करना आम है जिसमें बग पाया गया था।

main और develop में मर्ज करना

अंतिम कदम — hotfix को वापस main (नए पैच संस्करण टैग के साथ) और develop (ताकि सुधार अगले रिलीज़ में संरक्षित रहे) में मर्ज करना है। पहले main में टैग के साथ मर्ज करें, फिर develop में मर्ज करें।

# main में मर्ज करें और टैग बनाएं
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# develop में मर्ज करें
git checkout develop
git merge --no-ff hotfix/crash-on-login

# परिवर्तन सर्वर पर भेजें
git push origin main --tags
git push origin develop

--no-ff फ़्लैग यह सुनिश्चित करता है कि मर्ज कमिट बनाया जाए, भले ही hotfix को fast-forward के माध्यम से लागू किया जा सकता हो। यह जानकारी संरक्षित करता है कि एक आपातकालीन सुधार किया गया था और भविष्य में इतिहास विश्लेषण को सरल बनाता है।

Hotfix, Feature और Release ब्रांचों में अंतर

Hotfix उद्देश्य, जीवनकाल और मर्ज नियमों के मामले में feature और release ब्रांचों से मौलिक रूप से भिन्न है। इन अंतरों को समझना टीम में Git प्रक्रियाओं को सही ढंग से व्यवस्थित करने के लिए महत्वपूर्ण है।

Feature ब्रांच नई कार्यक्षमता के लिए होती है। यह कई दिनों से लेकर कई हफ्तों तक चलती है, develop से बनाई जाती है और develop में वापस मर्ज होती है। Feature में कई कमिट हो सकते हैं, जिनमें प्रयोगात्मक भी शामिल हैं, जो बाद में squash या rebase के माध्यम से संपीड़ित किए जाते हैं।

Release ब्रांच रिलीज़ को तैनाती के लिए तैयार करती है। यह develop से बनाई जाती है, इसमें स्थिरीकरण के दौरान पाए गए बग ठीक किए जाते हैं, और यह नई कार्यक्षमता स्वीकार नहीं करती। पूरा होने पर, release main (टैग के साथ) और develop में मर्ज होती है।

Hotfix वहीं, सीधे main के साथ बनाया और मर्ज किया जाता है, develop को छोड़ते हुए (हालांकि सुधार के बाद develop के साथ भी सिंक्रोनाइज़ किया जाता है)। इसमें न्यूनतम परिवर्तन होते हैं और न्यूनतम समय के लिए मौजूद रहता है। जबकि feature या release ब्रांचों को अगले चक्र तक स्थगित किया जा सकता है, hotfix को स्थगित नहीं किया जा सकता।

मोबाइल डेवलपमेंट के लिए, यह अंतर विशेष रूप से महत्वपूर्ण है: App Store और Google Play मुख्य रिलीज़ से अलग पैच संस्करण जारी करने की अनुमति देते हैं। Hotfix ब्रांच सुनिश्चित करती है कि पैच रिलीज़ अधूरी सुविधाओं के साथ मिश्रित न हो।

Hotfix के साथ काम करते समय सामान्य गलतियाँ

Hotfix के साथ काम करते समय गलतियाँ आपातकालीन सुधार के लाभों को समाप्त कर सकती हैं। आइए पाँच सबसे सामान्य समस्याओं पर नज़र डालें जो Git Flow का उपयोग करने वाली टीमों में उत्पन्न होती हैं।

• develop से hotfix बनाना — यदि hotfix develop से बनाया जाता है, तो अधूरी सुविधाएँ पैच में आ सकती हैं। Hotfix केवल main से बनाया जाना चाहिए ताकि यह सुनिश्चित हो सके कि सुधार में केवल स्थिर कोड शामिल है।
• एक hotfix में कई सुधार — प्रत्येक सुधार अपनी अलग hotfix ब्रांच में होना चाहिए। एक ब्रांच में कई बग मिलाने से कोड समीक्षा जटिल हो जाती है, रिग्रेशन का जोखिम बढ़ता है, और आवश्यकता पड़ने पर रोलबैक मुश्किल हो जाता है।
• develop में मर्ज छोड़ना — यदि hotfix develop में मर्ज नहीं किया जाता है, तो सुधार अगले रिलीज़ में खो जाएगा। टीम पाएगी कि वही बग फिर से प्रकट हुआ है और उसे इसे फिर से ठीक करना होगा।
• गलत संस्करण टैग — hotfix को पैच वृद्धि (v2.3.0 → v2.3.1) मिलनी चाहिए, न कि माइनर (v2.4.0) या मेजर (v3.0.0)। सिमैंटिक वर्जनिंग का उल्लंघन बिल्ड सिस्टम को तोड़ता है और उपयोगकर्ताओं को भ्रमित करता है।
• CI जाँच का अभाव — यहां तक कि आपातकालीन hotfix को भी स्वचालित परीक्षण पास करने चाहिए। CI छोड़ने से नई त्रुटि पेश करने का जोखिम बढ़ जाता है। त्वरित जाँच के साथ hotfix ब्रांचों के लिए अलग pipeline रखने की अनुशंसा की जाती है।

इनमें से प्रत्येक गलती पैच रिलीज़ में देरी या प्रोडक्शन में नई समस्याओं के प्रकट होने का कारण बनती है। टीमों को CONTRIBUTING.md में hotfix के साथ काम करने के नियमों को दस्तावेज़ित करना चाहिए और उन्हें CI/CD जाँच के माध्यम से स्वचालित करना चाहिए।