अनुमोदन / अनुमोदित होना: यह क्या है, Git में अनुमोदन और code review

pull request अनुमोदन क्या है

अनुमोदन pull request पर एक सकारात्मक समीक्षा है, जिसका मतलब है कि समीक्षक ने कोड की जाँच की, कोई गंभीर समस्या नहीं पायी, और परिवर्तनों को merge के लिए तैयार मानता है। GitHub इंटरफ़ेस में, यह PR पृष्ठ पर हरा «Approve» बटन है। अनुमोदन के बाद, लेखक (या लिखने की अनुमति वाला कोई भी सदस्य) merge कर सकता है।

अनुमोदन प्रक्रिया Branch Protection Rules का हिस्सा है। रिपोजिटरी के मालिक अनिवार्य आवश्यकताएँ कॉन्फ़िगर करते हैं: न्यूनतम अनुमोदन संख्या (उदाहरण के लिए, 1 या 2), कौन अनुमोदित कर सकता है (कोड स्वामी, टीम सदस्य), और क्या परिवर्तनों के बाद PR को पुनः अनुमोदित किया जाना चाहिए (Dismiss stale reviews)। नियम कॉन्फ़िगरेशन के बिना, अनुमोदन वैकल्पिक है, लेकिन पेशेवर टीमों में यह अनिवार्य है।

GitLab Approval Rules नामक एसी ही प्रणाली का उपयोग करता है। GitLab में, आप यह कॉन्फ़िगर कर सकते हैं कि विभिन्न समूहों से कितने अनुमोदन आवश्यक हैं (उदाहरण के लिए, बैकएण्ड डिवेलपर्स से 2 और DevOps से 1)। सभी अनिवार्य अनुमोदन मिलने के बाद, CI/CD पाइपलाइन के हरे होने पर PR स्वचालित रूप से merge के लिए अनलॉक हो जाता है।

समीक्षा के प्रकार: Approve, Request Changes, Comment

GitHub और GitLab में तीन प्रकार की समीक्षाएँ हैं जो एक समीक्षक pull request पर छोड़ सकता है। प्रत्येक प्रकार की अलग स्थिति और merge प्रक्रिया के लिए अलग-अलग परिणाम होते हैं। Approve हरा है, Request Changes लाल है, Comment नैट्रल ग्रे है। चुनाव कोड की गुणवत्ता और परिवर्तनों की स्वीकृति की तैयारी पर निर्भर करता है।

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

Request Changes — समीक्षक को ऐसी समस्याएँ मिलती हैं जिन्हें merge से पहले ठीक किया जाना चाहिए: तार्किक त्रुटियाँ, कमज़ोरियाँ, आर्किटेक्चर उल्लंघन, टेस्ट की कमी। Request Changes के बाद, PR अवरुद्ध हो जाता है, और इसे अनलॉक करने के लिए उसी समीक्षक से पुनः अनुमोदन आवश्यक है (यदि नए कमिट पर Dismiss stale reviews विकल्प सक्षम है)।

• Approve — कोड merge के लिए तैयार है, CI पार करने के बाद merge किया जा सकता है।
• Request Changes — अनिवार्य सुधार, पुनरीक्षण तक PR अवरुद्ध है।
• Comment — बिना PR को अवरुद्ध किए सामान्य टिप्पणी या सुझाव।

रिपोजिटरी में अनुमोदन नियम कॉन्फ़िगर करना

Branch Protection Rules merge गुणवत्ता को नियंत्रित करने की GitHub की प्रणाली है। प्रत्येक संरक्षित ब्रांच (main, develop, release/*) के लिए Settings → Branches में कॉन्फ़िगर किया जाता है। मुख्य पैरामीटर: अनिवार्य अनुमोदनों की संख्या, कोड स्वामी (CODEOWNERS), अनिवार्य CI/CD जाँच, और PR के बिना push पर प्रतिबंध।

Dismiss stale pull request approvals पैरामीटर स्वचालित रूप से अनुमोदन हटा देता है यदि PR में कोई नए कमिट जोड़े जाते हैं। यह सुनिश्चित करता है कि समीक्षक कोड के उसी संस्करण को मंजूरी दें जो merge किया जाएगा। इस सेटिंग के बिना, लेखक अनुमोदन के बाद नया कोड जोड़ सकता है और यह बिना दोबारा जाँचे main में पहुँच जाएगा।

CODEOWNERS — रिपोजिटरी के रूट में एक फ़ाइल जो विभिन्न निर्देशिकाओं के लिए उत्तरदायियों को निर्दिष्ट करती है। यदि PR किसी कोड स्वामी की फ़ाइलों को प्रभावित करता है, तो उसका अनुमोदन अनिवार्य हो जाता है। CODEOWNERS उत्तरदायित्व के क्षेत्रों को वितरित करने की अनुमति देता है: iOS डिवेलपर Swift फ़ाइलों के लिए उत्तरदाय हैं, DevOps Docker कॉन्फ़िग के लिए, परीक्षक परीक्षण परिदृश्यों के लिए।

# रिपोजिटरी रूट में उदाहरण CODEOWNERS फ़ाइल

# iOS डिवेलपर Swift कोड के मालिक हैं
*.swift @team/ios-developers

# DevOps CI/CD कॉन्फ़िगरेशन का मालिक है
.github/workflows/* @devops-team

# QA इंजीनियर परीक्षणों की समीक्षा करते हैं
**/tests/* @qa-engineers

# बाकी सभी चीज़ों के लिए डिफ़ॉल्ट मालिक
* @tech-leads

अनुमोदन से पहले code review: क्या जाँचें

Code review अनुमोदन से पहले एक व्यवस्थित कोड जाँच है, diff पर एक सरफरी नज़र नहीं। एक गुणवत्तापूर्ण code review में आर्किटेक्चर, तर्क, शैली, परीक्षण और सुरक्षा की जाँच शामिल है। इस जाँच के बिना, अनुमोदन गुणवत्ता नियंत्रण उपकरण के बजाय एक औपचारिकता मात्र हो जाता है।

सबसे पहले क्या जाँचा जाता है: परिवर्तनों का तर्क — क्या कोड कार्य को हल करता है, क्या दुष्प्रभाव हैं, क्या सीमांत मामलों का सही हैंडलिंग है। परीक्षण — क्या नए परीक्षण सभी परिदृश्यों को कवर करते हैं, क्या मौजूदा परीक्षण परिवर्तनों के बाद पास होते हैं। सुरक्षा — क्या SQL इंजेक्शन, XSS, संवेदनशील डेटा लीक नहीं हैं।

क्या समीक्षा का विषय नहीं होना चाहिए: फ़ॉर्मेटिंग शैली (इसके लिए linters और formatters हैं), पहले से लिए गए आर्किटेक्चर निर्णय (उनपर कोड लिखने से पहले चर्चा की जाती है)। यदि समीक्षा 400 से अधिक लाइनों की है या एक घंटे से अधिक समय लेती है, तो यह संकेत है कि कार्य बहुत बड़ा है और उसे विखंडित करने की आवश्यकता है। सबसे अछी समीक्षा प्रथाएँ — PR बनाने के 24 घंटों के भीतर 200–400 लाइनों के हिस्से।

• तर्क — समाधान की शुद्धता, त्रुटि हैंडलिंग, सीमांत मामले।
• परीक्षण — नए परिदृश्यों का कवरेज, मौजूदा परीक्षणों का पास होना, कोई flaky परीक्षण नहीं।
• सुरक्षा — कोई इंजेक्शन नहीं, आउटपुट एस्केपिंग, डेटा एक्सेस नियंत्रण।
• प्रदर्शन — एल्गोरिदम दक्षता, अनावश्यक क्वेरीज, मेमरी लीकेज।
• दस्तावेज़ीकरण — क्या दस्तावेज़ीकरण अपडेट है, क्या जटिल भागों में टिप्पणीयाँ स्पष्ट हैं।

टीम में अनुमोदन के साथ कार्यप्रवाह

5–10 डिवेलपर्स की टीम में अनुमोदन के साथ एक सामान्य कार्यप्रवाह इस प्रकार दिखता है: एक डिवेलपर PR बनाता है, समीक्षकों को निर्दिष्ट करता है (आमतौर पर टीम से 1–2 लोग या कोड स्वामी), CI/CD स्वचालित जाँच चलाता है। सभी अनिवार्य अनुमोदन और हरा CI मिलने के बाद, लेखक merge करता है। PR बनाने से लेकर merge तक का समय जटिलता के आधार पर औसतन 2 घंटे से 2 दिन तक होता है।

GitHub Actions अनुमोदन के बाद merge को स्वचालित करने की अनुमति देता है। यदि ब्रांच नियम कॉन्फ़िगर किए गए हैं, तो GitHub सभी शर्तों के पूरा होने तक merge को अवरुद्ध कर देता है। कुछ टीमें bors-ng या Mergify का उपयोग करती हैं — बॉट जो सभी अनुमोदन मिलने और CI पार करने के बाद स्वचालित रूप से PR को merge करते हैं। यह प्रक्रिया को तेज करता है और merge में मानवीय कारक को समाप्त करता है।

एक आधुनिक दृष्टिकोण है trunk-based development जिसमें अल्पजीवी ब्रांचें होती हैं। इस कार्यप्रवाह में, अनुमोदन कुछ घंटों के भीतर मिल जाना चाहिए, अन्यथा कार्य पुराना माना जाता है और इसे main के साथ पुनः सिंक करने की आवश्यकता होती है। उच्च समीक्षा संस्कृति वाली टीमें 4 कार्य घंटों से अधिक नहीं में अनुमोदन समय का लक्ष्य रखती हैं।

अनुमोदन में गलतियाँ और उनसे कैसे बचें

सबसे आम गलती बिना वास्तविक कोड जाँच के औपचारिक अनुमोदन है। जब PR बड़ा हो या समय सीमा पास हो, तो समीक्षक परिवर्तनों की जाँच किए बिना Approve दबा सकता है। यह पूरी code review प्रक्रिया को अवमूल्य करता है। समाधान: PR आकार पर सीमा निर्धारित करें (400 लाइनों से अधिक नहीं) और स्वचालित जाँच के लिए कोड विश्लेषण उपकरणों (SonarQube, CodeClimate) का उपयोग करें।

दूसरी गलती अत्यधिक सर्बराह अनुमोदन है। परफेक्ट कोड की उम्मीद विकास को अवरुद्ध करती है। समीक्षक कभी-कभी शैलीगत टिप्पणियों को ठीक करने की आवश्यकता होती है जो गुणवत्ता को प्रभावित नहीं करतीं। समाधान: अनिवार्य (blocking) और ऐच्छिक (टिप्पणी) के बीच स्पष्ट अंतर करें। GitHub आपको यह निर्दिष्ट करने की अनुमति देता है कि क्या कोई टिप्पणी अवरुद्ध करने वाली है।

तीसरी गलती CI/CD की जाँच किए बिना अनुमोदन है। भले ही कोड सही लगे, लेकिन हो सकता है कि वह कंपाइल न हो या परीक्षणों में विफल हो। कॉन्फ़िगर की गई Branch Protection लाल CI पर merge को स्वचालित रूप से अवरुद्ध कर देती है, लेकिन कुछ टीमें गति के लिए यह सुरक्षा बंद कर देती हैं। समाधान: अनुमोदन से पहले हमेशा CI स्थिति की जाँच करें और लाल पाइपलाइन वाले PR को कभी मंजूरी न दें।

• औपचारिक अनुमोदन — बिना वास्तविक कोड जाँच के। समाधान: प्रति PR 400 लाइन की सीमा।
• अत्यधिक कड़ापन — शैलीगत टिप्पणियों के कारण अवरुद्ध करना। समाधान: blocking और optional में बाँटें।
• CI की अनदेखी — लाल पाइपलाइन पर अनुमोदन। समाधान: हमेशा परीक्षण स्थिति की जाँच करें।
• लेखक निर्द्वार — PR लेखक द्वारा अनुमोदन। समाधान: लेखक के विरुद्ध Branch Protection कॉन्फ़िगर करें।