Pull Request: यह क्या है, निर्माण प्रक्रिया और कोड रिव्यू

Pull Request क्या है?

Pull Request (PR) एक वितरित संस्करण नियंत्रण प्रणाली में एक शाखा से दूसरी शाखा में परिवर्तन शामिल करने का औपचारिक अनुरोध है। PR GitHub, GitLab और Bitbucket प्लेटफॉर्म पर सहयोगी विकास का केंद्रीय तत्व है, जो कोड चर्चा, स्वचालित परीक्षण और परिवर्तन अनुमोदन प्रक्रिया को जोड़ता है।

नाम “Pull Request” संचालन के सार को दर्शाता है: डेवलपर रिपॉजिटरी मालिक से उसके परिवर्तनों को “खींचने” (pull) का अनुरोध (request) करता है। यह शब्द GitHub द्वारा 2008 में पेश किया गया था — उससे पहले, पैच और merge requests (GitLab का शब्द) के रूप में एक समान तंत्र मौजूद था। आज, PR टीम Git विकास के लिए वास्तविक मानक है।

GitHub Octoverse, 2025 के अनुसार, 89% ओपन-सोर्स प्रोजेक्ट्स में परिवर्तन करने के लिए PR बनाना आवश्यक है। कॉर्पोरेट विकास में, यह आंकड़ा 95% तक पहुँचता है। PR न केवल एक तकनीकी उपकरण बन गया है, बल्कि विकास संस्कृति का हिस्सा बन गया है: PR के माध्यम से ज्ञान हस्तांतरण, बग का पता लगाना और आर्किटेक्चरल निर्णयों का समन्वय होता है।

Pull Request के घटक

एक विशिष्ट PR में शीर्षक, विवरण, परिवर्तित फ़ाइलों की सूची (diff), समीक्षक टिप्पणियाँ और CI जाँच स्थितियाँ शामिल होती हैं। प्रत्येक PR एक विशिष्ट स्रोत शाखा और लक्ष्य शाखा से जुड़ा होता है, और विलय के बाद स्वचालित रूप से हटाया जा सकता है।

Pull Request कैसे बनाएं

PR बनाना रिमोट रिपॉजिटरी में फीचर शाखा प्रकाशित करने से शुरू होता है। पुश करने के बाद, डेवलपर प्लेटफॉर्म इंटरफ़ेस या CLI (gh, glab) के माध्यम से PR खोलता है। आइए GitHub के उदाहरण से प्रक्रिया देखें।

शाखा पुश करना और PR खोलना

पहला कदम — रिमोट रिपॉजिटरी में फीचर शाखा पुश करना और वेब इंटरफ़ेस या कमांड लाइन के माध्यम से Pull Request बनाना है।

# फीचर शाखा बनाएं और पुश करें
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLI के माध्यम से PR बनाएं
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

PR बनाने के बाद, GitHub स्वचालित रूप से CI पाइपलाइन (GitHub Actions) चलाता है, लक्ष्य शाखा के साथ विरोध की जाँच करता है और समीक्षकों को आमंत्रित करता है। PR विवरण टेम्पलेट को .github/PULL_REQUEST_TEMPLATE.md के माध्यम से कॉन्फ़िगर किया जा सकता है ताकि सभी PR में आवश्यक अनुभाग हों: लक्ष्य, परिवर्तन, परीक्षण, संबंधित कार्य।

विवरण और टैगिंग

गुणवत्तापूर्ण PR विवरण में शामिल है: कार्य का लिंक (issue/ticket), परिवर्तनों का संक्षिप्त विवरण, परीक्षण निर्देश और संबंधित परिवर्तनों की सूची। लेबल (bug, feature, refactoring) PR को वर्गीकृत करने में मदद करते हैं, जबकि assignees और reviewers CODEOWNERS के माध्यम से स्वचालित रूप से निर्धारित होते हैं।

# CODEOWNERS के माध्यम से समीक्षक नियुक्त करें (रिपॉजिटरी रूट में फ़ाइल)
# उदाहरण .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# gh cli के माध्यम से समीक्षक नियुक्त करते हुए PR बनाएं
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS परिवर्तित फ़ाइलों के आधार पर स्वचालित रूप से समीक्षक निर्धारित करने के लिए एक मानक GitHub/GitLab तंत्र है। उदाहरण के लिए, src/auth/ निर्देशिका में कोई भी परिवर्तन स्वचालित रूप से team-auth और senior-dev को समीक्षक के रूप में निर्धारित करता है। यह प्रक्रिया को गति देता है और सुनिश्चित करता है कि सही लोग PR देखें।

समीक्षा के आधार पर PR अपडेट करना

समीक्षक की टिप्पणियाँ प्राप्त करने के बाद, डेवलपर उसी फीचर शाखा में सुधार करता है और नए कमिट पुश करता है — PR स्वचालित रूप से अपडेट होता है। प्रकाशित फीचर शाखा में इतिहास को फिर से लिखना (rebase) महत्वपूर्ण नहीं है यदि PR पहले से खुला है, क्योंकि यह टिप्पणियों में विशिष्ट कमिट के लिंक को तोड़ता है।

# समीक्षक की टिप्पणियों के आधार पर परिवर्तन करें
git checkout feature/biometric-auth
# कोड ठीक करें
git commit -m "fix: handle biometric timeout per review"
git push

# PR स्वचालित रूप से अपडेट होगा
# अनुमोदन के बाद — GitHub इंटरफ़ेस के माध्यम से PR विलय करें

कोड रिव्यू प्रक्रिया

कोड रिव्यू Pull Request का केंद्रीय तत्व है। समीक्षक परिवर्तनों की शुद्धता, कोड शैली, सुरक्षा और आर्किटेक्चरल स्थिरता की जाँच करता है। गुणवत्तापूर्ण समीक्षा न केवल बग को रोकती है बल्कि टीम के भीतर कोडबेस के बारे में ज्ञान फैलाती है।

Google के Engineering Practices (2025) कोड रिव्यू के निम्नलिखित सिद्धांतों की सिफारिश करते हैं: समीक्षक को परिवर्तनों के संदर्भ को समझना चाहिए, सामान्य टिप्पणियों के बजाय विशिष्ट सिफारिशें देनी चाहिए, और तकनीकी और शैलीगत टिप्पणियों को अलग करना चाहिए। समीक्षा का समय PR बनाने के 24 घंटे से अधिक नहीं होना चाहिए।

मोबाइल डेवलपमेंट के लिए, कोड रिव्यू में विशिष्ट जाँच शामिल हैं: targetSdk के साथ संगतता, सही lifecycle हैंडलिंग (Android) / view lifecycle (iOS), मेमोरी लीक की अनुपस्थिति (LeakCanary, Instruments), डार्क थीम समर्थन और स्थानीयकरण। इन जाँचों को linters और Detekt/ktlint के माध्यम से स्वचालित किया जा सकता है।

टिप्पणियों के प्रकार

PR प्लेटफॉर्म तीन प्रकार की टिप्पणियों का समर्थन करते हैं: सामान्य (पूरे PR पर), पंक्तिबद्ध (कोड की विशिष्ट पंक्ति पर), और सुझाव (प्रतिस्थापन कोड के साथ)। सुझाव एक क्लिक में परिवर्तन लागू करने की अनुमति देते हैं, जिससे प्रक्रिया तेज होती है और पुनरावृत्तियों की संख्या कम होती है।

सभी टिप्पणियों के हल होने और CI जाँच पास होने के बाद, समीक्षक अनुमोदन (Approved) भेजता है। PR को विलय किया जा सकता है। GitHub और GitLab शाखा सुरक्षा नियमों का समर्थन करते हैं: आवश्यक अनुमोदनों की संख्या, अनिवार्य CI जाँच, और PR के बिना main में पुश पर प्रतिबंध। मोबाइल प्रोजेक्ट्स के लिए, शाखा सुरक्षा में बिल्ड सत्यापन भी शामिल है: PR को विलय नहीं किया जा सकता यदि एप्लिकेशन बिल्ड नहीं होता (gradle build failed / xcodebuild failed)।

PR में विरोध समाधान

मर्ज विरोध Pull Request में सक्रिय टीम वर्क में एक सामान्य स्थिति है। प्लेटफॉर्म वेब इंटरफ़ेस के माध्यम से विरोध समाधान प्रदान करते हैं (सरल विरोधों के लिए) या स्थानीय रूप से हल करने की सिफारिश करते हैं। GitHub Actions प्रत्येक पुश पर फीचर शाखा में स्वचालित रूप से मर्जियबिलिटी की जाँच करता है और यदि मर्ज संभव नहीं है तो PR को विरोध के रूप में चिह्नित करता है।

Pull Request के सर्वोत्तम अभ्यास

प्रभावी Pull Requests कोड रिव्यू को गति देते हैं और बग की संख्या कम करते हैं। SmartBear (2025) के एक अध्ययन से पता चला है कि 200 लाइनों तक के कोड वाले PR को 1000 लाइनों से अधिक वाले PR की तुलना में 2 गुना अधिक सार्थक टिप्पणियाँ मिलती हैं, और समीक्षा का समय 3 गुना कम हो जाता है।

• छोटे PR — इष्टतम आकार 100-300 लाइनें। बड़े PR को तार्किक भागों में विभाजित करें: प्रत्येक PR एक कार्य हल करता है। इससे समीक्षा सरल होती है और विरोध की संभावना कम होती है
• स्पष्ट विवरण — Conventional Commits के अनुसार शीर्षक (feat:, fix:, refactor:), बॉडी में “क्या और क्यों” होता है न कि “कैसे” (कोड खुद बोलता है)। टेम्पलेट: लक्ष्य → परिवर्तन → परीक्षण → संबंधित issues
• त्वरित प्रतिक्रिया — 24 घंटे के भीतर समीक्षा। यदि PR एक दिन से अधिक प्रतीक्षा करता है, तो टीम संदर्भ खो देती है और मर्ज विरोधों की संख्या बढ़ जाती है
• स्वचालन — linters, फ़ॉर्मेटर और परीक्षण PR बनाते समय स्वचालित रूप से चलने चाहिए। लाल CI जाँच वाले PR को विलय न करने दें
• Draft PR — प्रारंभिक आर्किटेक्चर चर्चा के लिए उपयोग करें। Draft PR को समीक्षा की आवश्यकता नहीं होती और इसे विलय नहीं किया जा सकता, लेकिन यह सहकर्मियों को प्रारंभिक चरण में कोड दिखाने की अनुमति देता है

अतिरिक्त अभ्यास: शुक्रवार शाम को PR न बनाएं (सोमवार तक कोई समीक्षा नहीं करेगा), 1-2 लोगों से समीक्षा का अनुरोध करें (अधिक गुणवत्ता में सुधार किए बिना प्रक्रिया को धीमा करता है), विलय से पहले इतिहास को संपीड़ित करने के लिए squash merge का उपयोग करें। मोबाइल प्रोजेक्ट्स के लिए, PR विवरण में परीक्षण बिल्ड (Firebase App Distribution / TestFlight) का लिंक जोड़ने की भी सिफारिश की जाती है ताकि समीक्षक चल रहे एप्लिकेशन में परिवर्तनों को सत्यापित कर सके।

विभिन्न प्लेटफॉर्म पर Pull Request

Pull Requests के साथ काम करने के लिए मुख्य प्लेटफॉर्म GitHub, GitLab और Bitbucket हैं। साझा अवधारणा के बावजूद, प्रत्येक में विशेषताएँ हैं जो टीम के लिए उपकरण चुनते समय विचार करने योग्य हैं।

GitHub सबसे लोकप्रिय प्लेटफॉर्म है जिसमें सबसे बड़ा समुदाय, CI/CD के लिए Actions और एप्लिकेशन का व्यापक पारिस्थितिकी तंत्र (GitHub Marketplace) है। GitLab में बिल्ट-इन CI/CD और पूर्ण सेल्फ-होस्टेड डिप्लॉयमेंट क्षमता है। Bitbucket Jira और Atlassian पारिस्थितिकी तंत्र के साथ घनिष्ठ रूप से एकीकृत है, कॉर्पोरेट वातावरण में लोकप्रिय है।

मोबाइल डेवलपमेंट के लिए, प्लेटफॉर्म का चुनाव अक्सर CI/CD क्षमताओं द्वारा निर्धारित होता है: GitHub Actions iOS बिल्ड के लिए macOS runners का समर्थन करता है, GitLab में iOS/Android के लिए बिल्ट-इन runners हैं, Bitbucket Firebase Test Lab के साथ अच्छी तरह से एकीकृत होता है। प्लेटफॉर्म के बावजूद, PR प्रक्रिया समान रहती है: शाखा → समीक्षा → CI → मर्ज।