Git में Feature Branch: यह क्या है, ब्रांच कैसे बनाएं और उनके साथ काम करें

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

Feature Branch (सुविधा ब्रांच) Git में एक अस्थायी ब्रांच है जो किसी विशिष्ट कार्यक्षमता को विकसित करने के लिए develop से बनाई जाती है। लंबे समय तक चलने वाली main और develop ब्रांच के विपरीत, feature ब्रांच सीमित समय — कुछ घंटों से लेकर कुछ हफ्तों तक — के लिए मौजूद रहती हैं।

feature branch का मुख्य उद्देश्य एक कार्य से संबंधित परिवर्तनों को बाकी कोड से अलग करना है। डेवलपर अपनी ब्रांच में प्रयोग कर सकता है, कई commits कर सकता है और कोड को तोड़ भी सकता है, बिना टीम के अन्य सदस्यों के काम को प्रभावित किए।

विकास पूरा होने के बाद, feature branch को अनिवार्य कोड समीक्षा के साथ Pull Request के माध्यम से वापस develop में विलय कर दिया जाता है। विलय के बाद, रिपॉजिटरी को साफ रखने के लिए ब्रांच को आमतौर पर हटा दिया जाता है।

Vincent Driessen, 2010 के अनुसार, feature ब्रांच के साथ Git Flow मॉडल विभिन्न प्रकार की ब्रांच के बीच जिम्मेदारियों के स्पष्ट विभाजन के कारण उद्योग मानक बन गया।

Feature Branch के साथ कार्यप्रवाह

कार्यप्रवाह feature branch के साथ उन चरणों के अनुक्रम से बना है जो डेवलपर प्रत्येक नई सुविधा के लिए करता है। यह प्रक्रिया विलय विवादों को कम करती है और कोड गुणवत्ता नियंत्रण सुनिश्चित करती है।

1. ब्रांच बनाना develop के नवीनतम commit से। डेवलपर develop पर स्विच करता है, उसे अपडेट करता है और एक नई feature ब्रांच बनाता है।
2. विकास और commits feature ब्रांच में। डेवलपर परिवर्तन करता है, स्पष्ट विवरण के साथ commits करता है और समय-समय पर ब्रांच को रिमोट रिपॉजिटरी में push करता है।
3. develop के साथ सिंक्रोनाइज़ेशन — विकास के दौरान, मुख्य ब्रांच आगे बढ़ सकती है। डेवलपर अपनी feature ब्रांच में develop का rebase या merge करता है।
4. Pull Request बनाना — जब सुविधा तैयार हो जाती है, डेवलपर कोड समीक्षा के लिए PR खोलता है। टीम कोड की समीक्षा करती है और टिप्पणियाँ छोड़ती है।
5. विलय और हटाना — PR की स्वीकृति के बाद, ब्रांच develop में विलय हो जाती है और स्थानीय और रिमोट दोनों जगहों से हटा दी जाती है।

develop के साथ समय-समय पर सिंक्रोनाइज़ेशन बहुत महत्वपूर्ण है। feature ब्रांच जितनी अधिक समय तक develop से परिवर्तनों को विलय किए बिना रहती है, अंतिम विलय में विवादों की संभावना उतनी ही अधिक होती है।

Feature ब्रांच सिंक्रोनाइज़ेशन आवृत्ति

Feature ब्रांच के नामकरण नियम

ब्रांच नामकरण टीम अनुशासन का एक महत्वपूर्ण हिस्सा है। एक समान नामकरण मानक जल्दी से यह पहचानने की अनुमति देता है कि किस कार्य पर काम चल रहा है और इसे कौन कर रहा है।

• feature/नाम — क्लासिक Git Flow में feature/ उपसर्ग का उपयोग किया जाता है। उदाहरण: feature/added-auth-module।
• feature/JIRA-123-विवरण — ट्रैकिंग सिस्टम में कार्य संख्या से लिंक। उदाहरण: feature/PROJ-42-add-login।
• feature/प्रकार/नाम — कार्य प्रकार के संकेत के साथ विस्तारित प्रारूप। उदाहरण: feature/feat/analytics-dashboard।

JIRA, Trello या अन्य सिस्टम से कार्य ID का उपयोग करना सबसे अच्छा अभ्यास है। यह स्वचालित रूप से कोड को कार्य से जोड़ता है और git log के माध्यम से ब्रांच खोज को सरल बनाता है।

Pull Request प्रक्रिया

Pull Request (या GitLab में Merge Request) feature ब्रांच को develop में विलय करने का अनुरोध है। PR केवल एक तकनीकी संक्रिया नहीं है, बल्कि एक टीम कोड समीक्षा प्रक्रिया है जो कोड गुणवत्ता में सुधार करती है और टीम के भीतर ज्ञान फैलाती है।

एक अच्छे PR में कार्य के संक्षिप्त विवरण के साथ शीर्षक, टिकट का लिंक और परिवर्तनों का विवरण होता है। डेवलपर को यह बताना चाहिए कि वास्तव में क्या किया गया, कौन सी फ़ाइलें बदली गईं और क्या प्रोजेक्ट के अन्य भागों के लिए संभावित जोखिम हैं।

टीम PR में कोड की समीक्षा करती है, टिप्पणियाँ छोड़ती है, परिवर्तनों का अनुरोध करती है (change requests) और विलय को मंजूरी देती है (approve)। स्वीकृति के बाद, merge या squash merge किया जाता है।

मोबाइल डेवलपमेंट में PR समीक्षा का औसत समय 4 से 24 घंटे तक है। Danger लाइब्रेरी सीधे PR में linters और परीक्षण चलाकर कुछ जाँचों को स्वचालित करती है।

अच्छा PR बनाने के लिए सुझाव

• आकार — 300-400 लाइनों से अधिक परिवर्तन नहीं। बड़े PR की समीक्षा करना कठिन है, समीक्षा की गुणवत्ता गिर जाती है।
• एक PR — एक कार्य — एक अनुरोध में असंबंधित परिवर्तनों को मिलाने से बचें।
• स्क्रीनशॉट — UI परिवर्तनों के लिए पहले और बाद के स्क्रीनशॉट संलग्न करें।
• परीक्षण — नई कार्यक्षमता के लिए यूनिट परीक्षण लिखें और उन्हें PR में शामिल करें।

Feature ब्रांच के विलय की रणनीतियाँ

PR की स्वीकृति के बाद, feature ब्रांच को विभिन्न तरीकों से develop में विलय किया जा सकता है। विलय रणनीति का चुनाव commit इतिहास और परिवर्तनों को वापस लाने की क्षमता को प्रभावित करता है।

• Merge commit — एक विलय commit बनाता है, feature ब्रांच के पूरे commit इतिहास को संरक्षित करता है। इतिहास पूरा रहता है, लेकिन ब्रांचिंग ग्राफ अधिक जटिल हो जाता है।
• Squash merge — feature ब्रांच के सभी commits को एक में जोड़ता है और इसे develop के ऊपर जोड़ता है। इतिहास साफ हो जाता है, लेकिन मध्यवर्ती commits के बारे में जानकारी खो जाती है।
• Rebase and merge — feature ब्रांच के commits को develop के नवीनतम commit के ऊपर पुनः लिखता है और बिना अतिरिक्त commit के विलय करता है। इतिहास रैखिक रहता है।

बार-बार रिलीज़ वाली मोबाइल परियोजनाओं के लिए, आमतौर पर squash merge का उपयोग किया जाता है: यह develop में साफ इतिहास देता है, जबकि विकास विवरण PR विवरण और tracker कार्य में रहते हैं।

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

अनुभवी डेवलपर भी feature ब्रांच के साथ काम करते समय गलतियाँ करते हैं। सामान्य समस्याओं का ज्ञान समय और डेटा की हानि से बचने में मदद करता है।

• ब्रांच का बहुत लंबा जीवन — feature ब्रांच develop के साथ सिंक्रोनाइज़ेशन के बिना 2-3 सप्ताह से अधिक जीवित रहती है, जिससे बड़े पैमाने पर विलय विवाद होते हैं।
• अस्पष्ट विवरण वाले Commits — “fix” या “update” जैसे संदेश यह नहीं बताते कि क्या बदला गया और क्यों।
• कार्यों का मिश्रण — एक ही feature ब्रांच में दो असंबंधित सुविधाएँ विकसित की जाती हैं, जिससे चयनात्मक वापसी असंभव हो जाती है।
• सिंक्रोनाइज़ेशन का अभाव — डेवलपर git fetch नहीं करता और develop को अपडेट नहीं करता, जिससे अंतिम विलय में विवाद उत्पन्न होते हैं।

इन समस्याओं से बचने का सबसे अच्छा तरीका प्रोजेक्ट की शुरुआत में काम के नियमों पर सहमत होना और CI/CD पाइपलाइन में स्वचालित जाँच का उपयोग करना है।

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

एक व्यावहारिक परिदृश्य पर विचार करें: एक डेवलपर मोबाइल ऐप में एक नई प्रमाणीकरण सुविधा शुरू करता है। वह एक feature ब्रांच बनाता है, कोड पर काम करता है और Pull Request के साथ कार्य पूरा करता है।

# develop को अपडेट करें और feature ब्रांच बनाएँ
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# सुविधा पर काम: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# feature ब्रांच को सर्वर पर push करें
git push origin feature/add-login-screen

# develop के साथ सिंक्रोनाइज़ करें (rebase)
git fetch origin develop
git rebase origin/develop

# PR स्वीकृति के बाद: स्थानीय develop अपडेट करें और ब्रांच हटाएँ
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

कमांड git branch -d ब्रांच को तभी हटाता है जब उसके परिवर्तन पूरी तरह से विलय हो चुके हों। यदि ब्रांच विलय नहीं हुई है, तो Git जबरन हटाने के लिए git branch -D का उपयोग करने का सुझाव देगा — इस फ्लैग का सावधानी से उपयोग करें।

Feature ब्रांच में जाँच का स्वचालन

PR बनाने से पहले प्रत्येक feature ब्रांच के लिए CI/CD पाइपलाइन चलनी चाहिए। यह कोड के अन्य डेवलपर्स की समीक्षा में जाने से पहले प्रारंभिक चरण में समस्याओं का पता लगाने में मदद करता है।

# feature ब्रांच की जाँच के लिए GitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

पाइपलाइन जाँचती है कि कोड संकलित होता है, परीक्षण पास होते हैं और कोड शैली टीम के मानकों को पूरा करती है। सभी जाँच पास करने के बाद ही Pull Request बनाया जा सकता है।