Git में Develop Branch — यह क्या है, उद्देश्य और कार्य सिद्धांत

Git में Develop Branch क्या है

Develop Branch (डेवलपमेंट ब्रांच) Git Flow में एक लंबे समय तक चलने वाली ब्रांच है जो सभी डेवलपर्स से कोड इंटीग्रेशन के लिए केंद्रीय हब के रूप में कार्य करती है। डेवलपमेंट पूरा होने और कोड रिव्यू के बाद feature branches इसमें मर्ज की जाती हैं।

develop में कोड हमेशा रिलीज़ बनाने के लिए तैयार स्थिति में होता है, हालाँकि अभी तक प्रोडक्शन में डिप्लॉय नहीं किया गया है। इसका मतलब है कि develop की सभी सुविधाएँ रिव्यू, टेस्टिंग और इंटीग्रेशन जाँच से गुज़री हैं, लेकिन अभी भी अपने रिलीज़ चक्र की प्रतीक्षा कर रही हैं।

main के विपरीत, जहाँ प्रत्येक कोड संस्करण एक रिलीज़ है, develop में परिवर्तनों की एक सतत धारा होती है। feature branches के मर्ज होने पर develop में commits दिखाई देते हैं, जो दिन में कई बार हो सकता है।

Vincent Driessen, 2010 के अनुसार, develop एक सफल ब्रांचिंग मॉडल का एक महत्वपूर्ण तत्व है, क्योंकि यह ड्राफ्ट कार्य को रिलीज़ के लिए तैयार संस्करणों से अलग करता है।

develop और main branch में अंतर

develop और main के बीच अंतर को समझना उचित Git Flow वर्कफ़्लो के लिए महत्वपूर्ण है। ये ब्रांच अलग-अलग कार्य करती हैं और स्थिरता की अलग-अलग आवश्यकताएँ रखती हैं।

develop और main में विभाजन टीम को प्रोडक्शन संस्करण की स्थिरता को जोखिम में डाले बिना लगातार नए कोड को एकीकृत करने की अनुमति देता है। डेवलपर्स आधिकारिक रिलीज़ से पहले भी, PR अनुमोदन के तुरंत बाद अपना कोड develop में देख सकते हैं।

Git Flow में develop की भूमिका

Git Flow मॉडल में, develop feature branches (परिवर्तनों का स्रोत) और release branches (रिलीज़ की तैयारी) के बीच एक केंद्रीय स्थान रखता है। इस पदानुक्रम को समझना प्रभावी ब्रांचिंग की नींव है।

• Feature → Develop — प्रत्येक पूर्ण सुविधा को कोड रिव्यू के साथ Pull Request के माध्यम से develop में मर्ज किया जाता है।
• Develop → Release — जब रिलीज़ के लिए पर्याप्त परिवर्तन जमा हो जाते हैं, तो develop से release branch बनाई जाती है।
• Release → Main + Develop — अंतिम तैयारी के बाद, release branch को main (रिलीज़) और वापस develop (बग फिक्स) में मर्ज किया जाता है।
• Hotfix → Main + Develop — महत्वपूर्ण फिक्स main से बनाए जाते हैं और दोनों ब्रांच में मर्ज किए जाते हैं।

यह संरचना सुनिश्चित करती है कि develop में हमेशा सभी नई सुविधाओं के साथ नवीनतम कोड हो, जबकि main में केवल सत्यापित प्रोडक्शन कोड हो। यह App Store और Google Play में लंबे रिव्यू चक्र वाले मोबाइल प्रोजेक्ट्स के लिए विशेष रूप से महत्वपूर्ण है।

अन्य Git Flow ब्रांच के साथ develop का संबंध

Develop feature, release और hotfix branches के बीच केंद्रीय कड़ी के रूप में कार्य करता है। मर्ज दिशाओं को समझना संघर्षों और commit हानि को रोकने के लिए आवश्यक है।

develop में कोड गुणवत्ता आवश्यकताएँ

develop में कोड गुणवत्ता उच्च होनी चाहिए, लेकिन पूर्ण नहीं। main के विपरीत, जहाँ हर त्रुटि का मतलब तत्काल hotfix है, develop में मामूली कमियाँ स्वीकार्य हैं जो रिलीज़ से पहले ठीक कर दी जाएँगी।

develop में मर्ज करने से पहले कोड के लिए न्यूनतम आवश्यकताएँ:

• कंपाइलेशन — कोड बिना त्रुटियों के कंपाइल होना चाहिए। develop में टूटा हुआ build पूरी टीम के काम को अवरुद्ध करता है।
• यूनिट टेस्ट — सभी मौजूदा टेस्ट पास होने चाहिए। नए कोड को कम से कम 70% टेस्ट द्वारा कवर किया जाना चाहिए।
• कोड शैली — कोड को टीम के स्वीकृत फ़ॉर्मेटिंग और नामकरण मानकों का पालन करना चाहिए।
• कोई deprecated API नहीं — नए कोड में पुराने तरीकों के उपयोग की अनुमति नहीं है।

CI/CD पाइपलाइन में स्वचालित जाँच develop में प्रत्येक push पर चलनी चाहिए। यदि build टूटता है, तो जिम्मेदार डेवलपर को एक घंटे के भीतर समस्या को ठीक करना होगा या अपने commit को वापस लेना होगा।

develop के लिए CI/CD जाँच

develop के लिए GitHub Actions सेट करना सुनिश्चित करता है कि प्रत्येक PR मर्ज करने से पहले स्वचालित जाँच से गुज़रे। एक सामान्य पाइपलाइन में build, टेस्ट और लिंटिंग शामिल हैं।

# GitHub Actions — मर्ज के बाद develop की जाँच
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

develop में मर्ज के नियम

develop में मर्ज करना इंटीग्रेशन ब्रांच की स्थिरता बनाए रखने के लिए सख्त नियमों का पालन करना चाहिए। इन नियमों का उल्लंघन संघर्ष, टूटे हुए builds और टीम के समय की बर्बादी का कारण बनता है।

• केवल Pull Request के माध्यम से — develop में सीधा push निषिद्ध है। सभी परिवर्तन कोड रिव्यू से गुज़रते हैं।
• कम से कम एक अनुमोदन — PR को कार्य में शामिल नहीं कम से कम एक डेवलपर द्वारा अनुमोदित किया जाना चाहिए।
• Squash merge — साफ़ इतिहास के लिए develop में मर्ज करते समय सभी feature branch commits को एक में संयोजित करने की अनुशंसा की जाती है।
• PR अद्यतित होना चाहिए — मर्ज करने से पहले, PR को नवीनतम develop commit (rebase या merge) के सापेक्ष अद्यतित किया जाना चाहिए।

PR अद्यतित नियम विशेष रूप से महत्वपूर्ण है। यदि एक feature branch एक सप्ताह पहले बनाई गई थी और develop 50 commits आगे बढ़ गया है, तो सीधा मर्ज संघर्ष का कारण बन सकता है जिसे develop के बजाय PR के संदर्भ में हल करना बेहतर है।

develop को गलत मर्ज से बचाना

Branch protection rules GitHub, GitLab या Bitbucket स्तर पर सेटिंग्स हैं जो develop में गलत परिवर्तनों को रोकती हैं। वे सुनिश्चित करते हैं कि एक आकस्मिक push भी इंटीग्रेशन ब्रांच को न तोड़े।

develop के लिए अनुशंसित सुरक्षा नियम:

• Pull request आवश्यक — develop में सीधा push प्रतिबंधित करें। सभी परिवर्तन केवल PR के माध्यम से।
• अनुमोदन आवश्यक — PR मर्ज करने से पहले कम से कम 1-2 अनुमोदन।
• स्थिति जाँच आवश्यक — यदि CI/CD पाइपलाइन पास नहीं हुई है तो मर्ज को अवरुद्ध करें।
• अद्यतित होना आवश्यक — मर्ज करने से पहले PR ब्रांच को develop के सापेक्ष अद्यतित किया जाना चाहिए।
• Push पहुँच प्रतिबंधित करें — develop में push अधिकार केवल वरिष्ठ डेवलपर्स तक सीमित करें।

develop सुरक्षा सेट करने में 10 मिनट लगते हैं लेकिन टूटी हुई इंटीग्रेशन ब्रांच से संबंधित हफ्तों के डाउनटाइम को रोकता है। मल्टी-प्लेटफ़ॉर्म टीमों वाले मोबाइल प्रोजेक्ट्स के लिए, यह विशेष रूप से प्रासंगिक है।

develop के साथ काम करने के लिए कमांड उदाहरण

एक सामान्य डेवलपर के दिन पर विचार करें: सुबह वे develop को अपडेट करते हैं, एक नई feature branch बनाते हैं, और कार्य पूरा करने के बाद परिवर्तनों को वापस develop में मर्ज करते हैं।

# सुबह develop सिंक
git checkout develop
git pull origin develop

# develop से नई feature branch बनाना
git checkout -b feature/add-push-notifications

# सुविधा पर काम...
git add . && git commit -m "Add FCM integration"

# डेवलपमेंट के दौरान develop अपडेट करना
git fetch origin develop
git rebase origin/develop

# PR अनुमोदन के बाद — स्थानीय develop अपडेट करें
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

develop में git pull कमांड एक साथ दो ऑपरेशन करता है: git fetch (सर्वर से नए commits लाता है) और git merge (उन्हें स्थानीय ब्रांच के साथ मर्ज करता है)। develop के लिए, यह मानक सिंक्रनाइज़ेशन विधि है।

टूटे हुए मर्ज के बाद develop को पुनर्स्थापित करना

यदि build तोड़ने वाला कोड develop में आ जाता है, तो जल्दी से कार्य करने की आवश्यकता है। develop के डाउनटाइम का हर घंटा पूरी डेवलपमेंट टीम के लिए अवरुद्ध कार्य है।

यदि build तोड़ने वाला कोड develop में आ जाता है, तो समस्याग्रस्त परिवर्तनों को पूर्ववत करने वाला नया commit बनाने के लिए git revert का उपयोग करें। develop में git reset का उपयोग न करें — यह इतिहास को फिर से लिखता है जो अन्य टीम सदस्यों के पास पहले से है।

# समस्याग्रस्त commit ढूँढना
git log --oneline develop

# revert के माध्यम से commit रद्द करना (सुरक्षित)
git revert a1b2c3d

# रिमोट develop में फिक्स भेजना
git push origin develop

# किसी विशिष्ट commit में परिवर्तन देखना
git show a1b2c3d --stat