Git और GitHub इंटीग्रेशन: Codex को अपने PR का समीक्षक बनाना
📚 सीरीज नेविगेशन: पिछला लेख [25 Worktrees समानांतर काम] आपको Git Worktree का उपयोग करके Codex में "समानांतर लेन" बनाना सिखाता है ताकि बिना किसी फ़ाइल टकराव के कई कार्य एक साथ चल सकें। यह लेख कार्यक्षेत्र को आपके स्थानीय टर्मिनल से GitHub रिपोजिटरी में स्थानांतरित करता है: कि कैसे Codex को अपने Pull Request (PR) में शामिल करें, ताकि वह स्वचालित रूप से कोड की समीक्षा कर सके, आपके नियमों के अनुसार खामियाँ निकाल सके, और सुधारे गए बदलावों को सीधे ब्रांच में पुश कर सके। अगला लेख [27 स्वचालन और CI/CD] यह समझाएगा कि इस व्यवस्था को कैसे CI (Continuous Integration) पाइपलाइन में जोड़कर पूर्ण स्वचालन हासिल किया जाए।
आइए कोडिंग टीम में होने वाले एक सामान्य परिदृश्य से शुरुआत करें। एक PR (पुल रिक्वेस्ट) बनाने से लेकर उसे मुख्य शाखा में मर्ज (Merge) करने तक, अधिकतर समय कोड समीक्षा करने में नहीं, बल्कि "समीक्षक (Reviewer) के उपलब्ध होने की प्रतीक्षा में" बीतता है—समीक्षक व्यस्त होते हैं, और आपका PR घंटों तक यूँ ही अटका रहता है।
और जब समीक्षा होती भी है, तो समीक्षक आमतौर पर "वेरिएबल का नाम ठीक नहीं है" या "यहाँ स्पेस कम है" जैसी बुनियादी चीज़ों पर ध्यान देते हैं; जबकि गंभीर सुरक्षा चूक—समानांतर प्रोसेसिंग में बग, क्रेडेंशियल्स का लीक होना या यूज़र प्राइवेसी डेटा का लॉग्स में जाना—थकान के कारण अक्सर छूट जाती हैं।
Codex का GitHub इंटीग्रेशन इसी समस्या का समाधान है: PR कमेंट में इसे @codex द्वारा मेंशन करें, और वह बिना थके कोड परिवर्तनों (diff) की समीक्षा करके, आपके प्रोजेक्ट नियमों के अनुसार मुख्य जोखिमों को पहचानकर कमेंट के रूप में दर्ज कर देगा। आपको GitHub से बाहर जाने की आवश्यकता नहीं होगी, और विलय (Merge) का अंतिम निर्णय आपके हाथ में ही रहेगा—समीक्षा वह करेगा, अनुमति आप देंगे। यह वही सुरक्षा नियम है जिसे हम अनुमतियों (लेख 15) से देखते आ रहे हैं।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
- PR कमेंट में
@codex reviewद्वारा समीक्षा कैसे शुरू की जाती है, उसका आउटपुट क्या होता है, और यह किन स्तरों की समस्याओं (P0/P1) को दिखाता है। - "स्वचालित समीक्षा (Automatic Review)" को कैसे सक्रिय करें—ताकि नए PR बनते ही स्वतः समीक्षा हो सके, बिना मेंशन किए।
AGENTS.mdमेंReview guidelinesद्वारा अपनी कस्टम समीक्षा नीतियां लिखना: जैसे सुरक्षा नियम या कोड स्टाइल।- समीक्षा के बाद
@codex fixकमांड द्वारा समस्याओं को स्वतः ठीक करके ब्रांच में पुश करना, और सुरक्षा सीमाएं। - स्थानीय सत्र में
/reviewका उपयोग: GitHub पर कोड पुश करने से पहले टर्मिनल में ही कोड की स्व-जाँच करना। - एक सामान्य नियम: कौन से कार्य AI को सौंपे जा सकते हैं, और कौन से कड़े निर्णय आपको स्वयं लेने चाहिए।
⚠️ इस लेख में वर्णित GitHub आधारित समीक्षा (
@codex review, स्वचालित समीक्षा) Codex Cloud सेवाओं पर आधारित है, जिसके लिए लाइसेंस और प्रोजेक्ट क्रेडेंशियल्स की आवश्यकता होती है; जबकि स्थानीय/reviewके लिए इसकी आवश्यकता नहीं होती। हम दोनों को अलग-अलग समझेंगे।
01 दो प्रकार के Codex: GitHub आधारित बनाम स्थानीय टर्मिनल आधारित
आगे बढ़ने से पहले दोनों में अंतर समझें:
तुलना: शिक्षक की भूमिका से जो या तो आपकी परीक्षा कॉपी की जाँच करता है, या क्लास में लिखते समय आपके पास बैठकर देखता है। एक वह है जो "काम पूरा होने और जमा करने के बाद मूल्यांकन करता है"; दूसरा वह है जो "काम करने के दौरान ही सलाह देता है"। दोनों कार्य शिक्षक के ही हैं, लेकिन परिदृश्य अलग-अलग हैं।
Codex में ये दो रूप हैं:
1. GitHub आधारित (Cloud): आप GitHub PR कमेंट में @codex review लिखते हैं, Codex क्लाउड पर एक कार्य शुरू करता है, PR परिवर्तनों (diff) को पढ़ता है, और फिर PR पर कमेंट के रूप में समीक्षा लिखता है। यह OpenAI क्लाउड वातावरण पर चलता है (लेख 10)। आवश्यकता: प्रोजेक्ट को Codex Cloud से जोड़कर Code review सेटिंग्स को सक्षम करना होगा।
2. स्थानीय /review (CLI): आप अपने टर्मिनल सत्र में /review चलाते हैं, यह आपकी स्थानीय मशीन पर ही समीक्षा शुरू करता है, आपके द्वारा चयनित परिवर्तनों को पढ़ता है, और सुरक्षा खामियों की सूची दिखाता है। यह केवल कोड पढ़ता है, उसमें कोई बदलाव नहीं करता। इसके लिए GitHub या क्लाउड की आवश्यकता नहीं होती, यह पूरी तरह स्थानीय है।
| आयाम | GitHub आधारित @codex review | स्थानीय /review |
|---|---|---|
| सक्रियण स्थान | GitHub PR कमेंट्स में | टर्मिनल Codex सत्र में |
| निष्पादन वातावरण | Codex Cloud (क्लाउड) | स्थानीय मशीन |
| लक्ष्य | PR के कोड परिवर्तन (diff) | स्थानीय परिवर्तन (अनकमिटेड / ब्रांच अंतर) |
| परिणाम का स्थान | PR पर कमेंट के रूप में दर्ज | टर्मिनल स्क्रीन पर सूची के रूप में |
| आवश्यकता | Cloud सेटअप और Code review विकल्प सक्षम | किसी सेटअप की आवश्यकता नहीं |
| कोड में बदलाव | नहीं (जब तक कि @codex fix न कहें) | कभी नहीं (शुद्ध पठन) |
इस लेख में मुख्य ध्यान GitHub आधारित समीक्षा पर रहेगा; स्थानीय /review का विवरण धारा 06 में दिया गया है, जो कोड पुश करने से पहले की "स्व-जाँच" प्रक्रिया है।
💡 संक्षेप में: Codex कोडिंग समीक्षा दो तरीकों से करता है—GitHub में
@codex reviewजो क्लाउड पर चलती है और PR पर परिणाम दर्ज करती है; तथा टर्मिनल में/reviewजो स्थानीय रूप से चलती है और केवल सुरक्षा चेतावनी दिखाती है।
02 @codex review का उपयोग
मुख्य तरीका सरल है: PR कमेंट बॉक्स में @codex review लिखें और सबमिट करें।
यह महत्वपूर्ण क्यों है? क्योंकि कोड समीक्षा में काफी मानसिक ध्यान लगाना पड़ता है, और व्यस्तता के समय कोडर अक्सर इसे टालते हैं। Codex यहाँ एक कुशल सहायक की भूमिका निभाता है।
तुलना: ड्राफ्ट सबमिट करने से पहले प्रूफरीडर को दिखाने से। स्वयं लिखी हुई चीज़ में गलतियाँ खोजना कठिन होता है क्योंकि दिमाग उसे सही मानकर पढ़ता है। एक तटस्थ प्रूफरीडर को देने पर वह व्याकरण और वाक्यों के तालमेल की कमियाँ तुरंत पकड़ लेता है। Codex भी यही करता है: वह कोड स्टाइल की प्रशंसा नहीं करता, बल्कि संभावित जोखिमों को खोजता है।
जब आप GitHub PR में यह लिखते हैं:
@codex reviewतो निम्नलिखित प्रक्रिया शुरू होती है:
- Codex कमेंट पर 👀 का रिएक्शन देता है—जिसका अर्थ है कि उसने निर्देश प्राप्त कर लिया है और काम शुरू कर दिया है।
- वह क्लाउड पर कार्य शुरू करके, PR परिवर्तनों को पढ़ता है और नियमों से मिलान करता है।
- काम होने पर, वह कमेंट के रूप में समीक्षा जोड़ देता है, जहाँ विशिष्ट लाइनों पर टिप्पणियाँ होती हैं।
आधिकारिक सुरक्षा सेटिंग:
GitHub में, Codex केवल P0 (अति गंभीर) और P1 (गंभीर) स्तर की समस्याओं को ही चिह्नित करता है, ताकि समीक्षा का ध्यान मुख्य जोखिमों पर केंद्रित रहे।
यह अनावश्यक छोटी टिप्पणियों (जैसे स्पेस या ब्रैकेट स्टाइल) से कमेंट्स की बाढ़ को रोकता है। केवल गंभीर खामियाँ ही दिखाई देती हैं, जिससे आपका ध्यान भटकता नहीं है।
उदाहरण के लिए, हाल ही में एक पेमेंट API के PR में समीक्षा करते समय Codex ने चेतावनी (P1) दिखाई कि कॉल बैक API में सुरक्षा सत्यापन (idempotency key) की कमी है, जिससे डुप्लिकेट रिक्वेस्ट से भुगतान का जोखिम हो सकता है। यह एक महत्वपूर्ण सुरक्षा चूक थी जिसे पकड़ना आवश्यक था।
💡 संक्षेप में: PR कमेंट में
@codex reviewलिखने पर Codex कोड की जाँच करता है और टिप्पणियाँ लिखता है; यह केवल गंभीर P0/P1 स्तर की समस्याओं को दिखाता है, जिससे समीक्षा साफ़ और काम की बनी रहती है।
03 स्वचालित समीक्षा (Automatic Reviews)
मैन्युअल रूप से मेंशन करना बार-बार याद रखना कठिन हो सकता है। इसके लिए आप स्वचालित समीक्षा (Automatic Reviews) सक्षम कर सकते हैं।
तुलना: अस्पताल में बार-बार स्वास्थ्य जाँच के लिए अपॉइंटमेंट लेने के बजाय स्वास्थ्य बीमा की वार्षिक योजना लेने से। योजना लेने के बाद आपको याद रखने की आवश्यकता नहीं होती, चेकअप अपने समय पर स्वतः निर्धारित हो जाता है।
इसे कैसे सक्षम करें:
यदि आप चाहते हैं कि Codex हर नए PR पर स्वचालित समीक्षा करे, तो Codex सेटिंग्स में Automatic reviews विकल्प को सक्षम करें। ऐसा करने पर जैसे ही नया PR बनेगा, Codex स्वतः समीक्षा कमेंट्स लिख देगा, मेंशन करने की आवश्यकता नहीं होगी।
सक्रियण के चरण (यह settings पेज ChatGPT में Codex सेटिंग्स में होता है):
- settings पेज पर जाएं (URL:
https://chatgpt.com/codex/settings/code-review)। - Automatic reviews विकल्प को ऑन (enabled) करें।
अब दोनों का सही संतुलन कैसे बनाएं:
- प्रोजेक्ट के मुख्य रिपोजिटरी में → स्वचालित समीक्षा ऑन रखें ताकि सुरक्षा की पहली परत हमेशा बनी रहे।
- व्यक्तिगत या छोटे प्रोजेक्ट्स में → मैन्युअल मेंशन
@codex reviewका उपयोग करें ताकि अनावश्यक कोडिंग सीमाएं खर्च न हों। - गंभीर सुरक्षा बदलावों पर → स्वचालित समीक्षा के बाद भी आप अतिरिक्त सुरक्षा जाँच के लिए मेंशन करके निर्देश दे सकते हैं (जैसे
@codex review for security regressions)।
| आयाम | मैन्युअल मेंशन @codex review | स्वचालित समीक्षा |
|---|---|---|
| सक्रियण | कमेंट में मेंशन करने पर | नया PR बनते ही स्वतः |
| निरंतरता | भूलने की संभावना रहती है | हमेशा स्वतः काम करता है |
| उपयुक्तता | छोटे प्रोजेक्ट्स या विशिष्ट जाँच के लिए | मुख्य कोडिंग प्रोजेक्ट्स के लिए |
| नियंत्रण स्तर | चयनित फ़ाइलों पर ध्यान केंद्रित कर सकते हैं | सभी PR पर समान सुरक्षा जाँच |
💡 संक्षेप में: स्वचालित समीक्षा सक्रिय करने पर नए PR बनते ही Codex स्वतः समीक्षा शुरू कर देता है, याद रखने की आवश्यकता नहीं होती; यह प्रोजेक्ट्स के लिए सुरक्षा सुनिश्चित करने का सही तरीका है।
04 समीक्षा नीतियों को अनुकूलित करना: AGENTS.md का उपयोग
Codex समीक्षा के लिए किन नियमों का पालन करता है? डिफ़ॉल्ट कोडिंग नियमों के अलावा आप Review guidelines अनुभाग में अपने विशिष्ट नियम लिख सकते हैं।
AGENTS.md (लेख 11) वह निर्देश फ़ाइल है जिसे Codex हर कार्य से पहले पढ़ता है। आप इसमें अपनी समीक्षा प्राथमिकताएं लिख सकते हैं।
तुलना: कारखाने में काम करने वाले इंस्पेक्टर को विशिष्ट चेकलिस्ट देने से। बुनियादी नियमों (जैसे सुरक्षा बेल्ट पहनना) के अलावा, आप उसे बताते हैं कि "इस बैच में पैकिंग की गुणवत्ता को विशेष रूप से देखना है"। वह उस चेकलिस्ट के अनुसार कड़ाई से जाँच करता है।
प्रोजेक्ट रूट की AGENTS.md फ़ाइल में लिखने का उदाहरण:
## Review guidelines
- Don't log PII (व्यक्तिगत डेटा को लॉग्स में न लिखें).
- Verify that authentication middleware wraps every route (सुनिश्चित करें कि सभी राउट्स पर सुरक्षा सत्यापन लागू हो).इन्हें लिखने के बाद Codex हर समीक्षा में इन नियमों की कड़ाई से जाँच करेगा।
यहाँ उसी "就近原则 (निकटता नियम)" का पालन किया जाता है जिसे हमने लेख 11 में देखा था:
Codex फ़ाइल के सबसे पास वाली
AGENTS.mdफ़ाइल के नियमों को लागू करता है। आप विशिष्ट फ़ोल्डर्स में अलग नियम फ़ाइलें रख सकते हैं ताकि संवेदनशील क्षेत्रों पर कड़े नियम लागू किए जा सकें।
उदाहरण के लिए, भुगतान संबंधित फ़ोल्डर src/payment/AGENTS.md में:
## Review guidelines
- कैलकुलेशन के लिए हमेशा Decimal का उपयोग करें, float प्रतिबंधित है।
- डुप्लिकेट पेमेंट से बचने के लिए हमेशा सुरक्षा टोकन सत्यापित करें।इसके बाद जब भी भुगतान मॉड्यूल के कोड में बदलाव होगा, Codex विशेष रूप से इन नियमों को जाँचेगा।
इसके अतिरिक्त, आप निर्देश देते समय भी तात्कालिक प्राथमिकताओं को लिख सकते हैं:
@codex review for security regressionsयह निर्देश विशेष रूप से सुरक्षा खामियों पर ध्यान केंद्रित करने के लिए कहेगा।
💡 संक्षेप में: समीक्षा नियम
AGENTS.mdकेReview guidelinesअनुभाग में लिखे जाते हैं; निकटता नियम के अनुसार विशिष्ट फ़ोल्डर्स के लिए कड़े नियम सेट किए जा सकते हैं; तात्कालिक निर्देश कमेंट्स में सीधे दिए जा सकते हैं।
05 सुधार लागू करना: @codex fix का उपयोग
समीक्षा में कोई गंभीर त्रुटि (P1) मिलने पर क्या करें? आप कमेंट में Codex को उसे ठीक करने का निर्देश दे सकते हैं, और वह सुधार करके सीधे आपकी ब्रांच में बदलाव पुश कर देगा।
तुलना: सहायक द्वारा ड्राफ्ट में गलतियाँ सुधार कर फ़ाइल वापस टेबल पर रखने से। वह न केवल गलतियों को चिह्नित करता है बल्कि आपके कहने पर उन्हें सुधार भी देता है। लेकिन इसके लिए उसे अलमारी खोलने (राइट एक्सेस) की अनुमति होनी चाहिए।
कमेंट में निर्देश देने का तरीका:
@codex fix the P1 issueआधिकारिक सुरक्षा विवरण:
Codex इस PR का उपयोग संदर्भ के रूप में करके एक क्लाउड कार्य शुरू करता है, और यदि उसे अनुमतियाँ (write access) प्राप्त हैं, तो वह सुधारों को सीधे संबंधित ब्रांच में पुश कर देता है।
दो महत्वपूर्ण बातें:
पहला, यह कार्य क्लाउड पर निष्पादित होता है। यह सत्र शुरू करके कोडिंग नियमों के अनुसार बदलाव करता है और टेस्ट रन करके जाँचता है।
दूसरा, इसके लिए write अनुमतियाँ होना आवश्यक है। यह अनुमतियों (लेख 15) के नियमों के अनुसार काम करता है, यदि क्रेडेंशियल्स में पुश की अनुमति नहीं है, तो वह बदलाव नहीं कर पाएगा।
मेंशन करने के अंतर को समझें:
@codex review→ समीक्षा मार्ग को सक्रिय करता है (केवल टिप्पणियाँ लिखता है, कोड नहीं बदलता)।@codex+ कोई अन्य निर्देश (जैसे@codex fix the CI failuresया@codex write tests) → कार्य मार्ग को सक्रिय करता है, जहाँ वह कोड में बदलाव करके पुश करता है।
नियम: कोड में सुधार या परीक्षण के कार्य Codex को सौंपे जा सकते हैं, लेकिन "मर्ज (Merge)" करने का अंतिम निर्णय हमेशा आपको स्वयं लेना चाहिए। वाहन की कोडिंग लेन वह चलाए, लेकिन मुख्य सड़क पर मोड़ने का निर्णय आपका होना चाहिए।
💡 संक्षेप में:
@codex fix the P1 issueलिखने पर Codex क्लाउड सत्र शुरू करके त्रुटि को ठीक करता है और अनुमतियाँ होने पर ब्रांच में पुश कर देता है; merge का निर्णय हमेशा डेवलपर का होना चाहिए।
इस प्रक्रिया को चित्र द्वारा समझें:
यह आरेख दिखाता है कि PR बनने पर स्वचालित समीक्षा या मेंशन द्वारा जाँच शुरू होती है, नियमों से मिलान किया जाता है, त्रुटियाँ कमेंट के रूप में लिखी जाती हैं, और @codex fix द्वारा उन्हें सुधारा जाता है।
06 स्थानीय /review का उपयोग: कोड पुश करने से पहले स्व-जाँच
GitHub पर कोड भेजने से पहले, आप स्थानीय स्तर पर भी बदलावों की जाँच कर सकते हैं।
तुलना: परीक्षा कॉपी जमा करने से पहले स्वयं एक बार उत्तरों को ध्यान से पढ़ने से। गलतियाँ पहले ही सुधार ली जाएँ तो बेहतर रहता है।
स्थानीय टर्मिनल सत्र में चलाएं:
/reviewचलाने पर स्क्रीन पर समीक्षा के कई विकल्प (Presets) दिखाई देंगे:
- Review against a base branch (आधार ब्रांच से तुलना): चयनित ब्रांच (जैसे
main) से कोड के अंतर (diff) की जाँच करना। - Review uncommitted changes (अनकमिटेड बदलावों की जाँच): जिन बदलावों को अभी कमिट नहीं किया गया है, उनकी सुरक्षा जाँच।
- Review a commit (कमिट की जाँच): किसी विशिष्ट कमिट के बदलावों का विश्लेषण करना।
- Custom review instructions (कस्टम समीक्षा निर्देश): कोडिंग नियमों के बाहर किसी विशिष्ट निर्देश (जैसे "वेब सुरक्षा जाँचना") के अनुसार जाँच।
आप config.toml में review_model द्वारा समीक्षा के लिए एक अधिक शक्तिशाली मॉडल को सेट कर सकते हैं, भले ही आप सामान्य बातचीत में किसी तेज़ मॉडल का उपयोग कर रहे हों।
समीक्षा का सही क्रम:
- कोड लिखने के बाद, स्थानीय सत्र में
/reviewचलाएं और Review uncommitted changes चुनें। - चिह्नित की गई समस्याओं को स्थानीय स्तर पर ही ठीक करें।
- कोड साफ़ होने पर ही उसे कमिट करके पुश करें, जिससे GitHub पर अतिरिक्त समीक्षा कमेंट्स लिखने की आवश्यकता नहीं होगी।
💡 संक्षेप में: स्थानीय
/reviewकोड पुश करने से पहले सुरक्षा जाँच करने का साधन है; यह केवल कोड पढ़ता है और सुरक्षा चेतावनी दिखाता है; समस्याओं को पहले ही ठीक कर लेने से रिपोजिटरी साफ़ बनी रहती है।
07 GitHub CLI (gh) टूल कॉन्फ़िगर करना
यदि आप Desktop App या IDE का उपयोग कर रहे हैं, तो GitHub CLI (gh) टूल को स्थापित करना आवश्यक है।
तुलना: सहायक को ऑफिस के अलमारी की चाबी देने से। बिना चाबी के वह फाइलों की जाँच नहीं कर सकता। gh टूल भी Codex को GitHub इतिहास और समीक्षा कमेंट्स को सीधे पढ़ने की अनुमति देता है।
आधिकारिक विवरण:
GitHub CLI (
gh) इंस्टॉल करकेgh auth loginद्वारा लॉगिन करें, ताकि Codex PR का विवरण, समीक्षा टिप्पणियाँ और फ़ाइलें लोड कर सके। ऐसा न करने पर, साइडबार में PR की जानकारी दिखाई नहीं देगी।
स्थापना के तरीके:
# macOS (Homebrew)
brew install gh
# Windows (winget)
winget install --id GitHub.cli
# स्थापना के बाद लॉगिन करें
gh auth loginलॉगिन होने के बाद, Desktop App में इस प्रकार काम किया जा सकता है:
- Side panel में PR समीक्षा खोलें।
- समीक्षा टिप्पणियाँ और कोड बदलाव देखें।
- संबंधित टिप्पणियों को सुधारने के लिए Codex को निर्देश दें।
- सुधारों के diff की जाँच करें।
- संतुष्ट होने पर ही कोड को कमिट और पुश करें।
सुरक्षा चेतावनी: PR कमेंट्स या चर्चा बाहरी डेटा होते हैं, जिनमें दुर्भावनापूर्ण निर्देश (prompt injection) हो सकते हैं। इसलिए Codex द्वारा टिप्पणियों के आधार पर स्वतः कोड बदलते समय सावधानी रखें।
💡 संक्षेप में: Desktop App में PR विवरण देखने के लिए
ghइंस्टॉल करकेgh auth loginचलाना आवश्यक है; सुधारों के बाद पुश करने का निर्णय कोडर का होना चाहिए।
08 सुरक्षा सीमा: merge और force-push का निर्णय
सभी कार्यों के बावजूद, दो कड़े निर्णय आपको हमेशा स्वयं लेने चाहिए:
तुलना: सहायक दस्तावेज़ों को तैयार कर सकता है, लेकिन हस्ताक्षर केवल अधिकृत व्यक्ति ही कर सकता है। हस्ताक्षर से कानूनन ज़िम्मेदारी तय होती है। Git में merge और force-push भी हस्ताक्षर के समान हैं।
इन ऑपरेशन्स का विवरण:
| क्रिया | सुरक्षा प्रभाव | निर्णय कर्ता |
|---|---|---|
@codex review / स्थानीय /review | सुरक्षित (केवल पढ़ना) | AI |
@codex fix द्वारा ब्रांच में बदलाव | मध्यम (केवल उस विशिष्ट ब्रांच में) | AI (आपके निर्देश पर) |
| PR को मुख्य शाखा में मर्ज (merge) करना | उच्च (सभी डेवलपर्स प्रभावित होंगे) | केवल आप स्वयं |
git push --force (फ़ोर्स पुश) | अति उच्च (इतिहास बदल सकता है) | केवल आप स्वयं |
दो महत्वपूर्ण नियम:
पहला, merge का बटन हमेशा स्वयं क्लिक करें। Codex कोड सुधार सकता है, लेकिन उसे मुख्य रिपोजिटरी (main/master) में शामिल करने का निर्णय आपका होना चाहिए क्योंकि वह प्रोजेक्ट की सुरक्षा सीमा है।
दूसहा, force-push कभी भी स्वचालित रूप से न होने दें। git push --force से पुराना इतिहास मिट सकता है, जिससे दूसरों का काम नष्ट हो सकता है। यह अत्यंत संवेदनशील कोडिंग ऑपरेशन है।
याद रखें कि codex exec डिफ़ॉल्ट रूप से read-only (केवल पढ़ने की अनुमति) पर चलता है, जो इसकी अंतर्निहित सुरक्षा सीमा को दर्शाता है।
💡 संक्षेप में: समीक्षा और सुधार Codex को सौंपे जा सकते हैं, लेकिन PR मर्ज करना और force-push करना हमेशा आपके नियंत्रण में होना चाहिए; यह कोडिंग सुरक्षा का बुनियादी नियम है।
09 कोडिंग समीक्षा का संतुलन चित्र
निम्नलिखित चित्र GitHub कोडिंग प्रवाह में मानवीय नियंत्रण और AI सहायता के बीच संतुलन दिखाता है:
यह आरेख दिखाता है कि स्थानीय स्व-जाँच से शुरू होकर, GitHub पर स्वचालित समीक्षा, और अंत में मर्ज (Merge) करने का निर्णय कोडर द्वारा ही लिया जाता है।
इस संतुलन से सुरक्षा और गति दोनों बनी रहती हैं।
10 अभ्यास: स्थानीय /review का परीक्षण
चूँकि GitHub Cloud के लिए लाइसेंस की आवश्यकता होती है, हम स्थानीय /review का परीक्षण करेंगे जो पूरी तरह सुरक्षित है।
चरण 1: एक टेस्ट Git रिपोजिटरी बनाएं (टर्मिनल में चलाएं)
mkdir review-demo && cd review-demo
git init
printf 'def get_user(uid):\n return db.query("SELECT * FROM users WHERE id=" + uid)\n' > app.py
git add app.py && git commit -m "feat: initial get_user"यहाँ हमने app.py में SQL इंजेक्शन सुरक्षा चूक (SQL Injection) छोड़ दी है (string concatenation द्वारा Query चलाना)।
चरण 2: फ़ाइल में बदलाव करें (अनकमिटेड बदलाव)
printf 'def get_user(uid):\n return db.query("SELECT * FROM users WHERE id=" + uid)\n\ndef delete_user(uid):\n db.execute("DELETE FROM users WHERE id=" + uid)\n' > app.pyअब फ़ाइल में एक नया फंक्शन delete_user जुड़ गया है, जिसे कमिट नहीं किया गया है।
चरण 3: Codex शुरू करें और समीक्षा चलाएं
codexसत्र में प्रवेश करने के बाद चलाएं:
/reviewसूची में से Review uncommitted changes (अनकमिटेड बदलावों की जाँच) चुनें।
चरण 4: परिणाम देखें
अपेक्षित परिणाम: Codex समीक्षा करके चेतावनी देगा कि कोड में SQL इंजेक्शन (SQL Injection) का जोखिम है और इसे parameterized query में बदलने का सुझाव देगा। मूल फ़ाइल app.py में कोई बदलाव नहीं होगा, यह केवल चेतावनी दिखाएगा।
चरण 5: हटाना (साफ़ करना)
अभ्यास के बाद निर्देशिका डिलीट कर दें:
cd .. && rm -rf review-demo💡 संक्षेप में: अभ्यास के चरण हैं—टेस्ट रिपोजिटरी बनाना (SQL इंजेक्शन त्रुटि के साथ) → फ़ाइल बदलना →
/reviewद्वारा अनकमिटेड बदलाव जाँचना → सुरक्षा चेतावनी देखना → निर्देशिका डिलीट करना।
11 सारांश
इस लेख में हमने Codex के Git और GitHub इंटीग्रेशन को विस्तार से समझा है।
मुख्य बिंदुओं का सारांश:
| कार्य | साधन | मुख्य बिंदु |
|---|---|---|
| PR समीक्षा | @codex review | केवल P0/P1 स्तर की गंभीर सुरक्षा चेतावनियाँ दिखाता है |
| स्वचालित समीक्षा | Automatic reviews | नया PR बनते ही स्वतः सक्रिय होता है, क्रेडेंशियल्स की सुरक्षा के लिए अच्छा है |
| नीतियां सेट करना | AGENTS.md | Review guidelines में कस्टम नियम लिखना, फ़ोल्डर स्तर पर कस्टमाइज़ेशन संभव |
| त्रुटि सुधार | @codex fix | सुधार करके सीधे ब्रांच में पुश करना, write क्रेडेंशियल्स आवश्यक |
| स्व-जाँच | /review | कोड पुश करने से पहले स्थानीय स्तर पर ही सुरक्षा खतरों की जाँच |
| GitHub CLI | gh टूल | Desktop App में PR इतिहास लोड करने के लिए क्रेडेंशियल्स लॉगिन आवश्यक |
| सुरक्षा नियम | merge / force-push | अंतिम विलय (Merge) और बलपूर्वक पुश (Force Push) का निर्णय केवल डेवलपर का |
अब आप यह कर सकते हैं: GitHub समीक्षा और स्थानीय समीक्षा में अंतर बताना, स्वचालित समीक्षा सक्षम करना, AGENTS.md में नियम लिखना, @codex fix का सुरक्षा परिप्रेक्ष्य समझना, स्थानीय स्तर पर /review चलाना, gh टूल का सेटअप करना, और सुरक्षा सीमाओं का ध्यान रखना।
अगला लेख [27 स्वचालन और CI/CD]—इस लेख में हमने GitHub की कोडिंग समीक्षा की बात की। अगले लेख में हम Codex को CI/CD पाइपलाइन (जैसे GitHub Actions) में एकीकृत करना सीखेंगे ताकि कोडिंग एरर होने पर स्वतः सुधार और डिप्लॉयमेंट की प्रक्रिया को पूरी तरह स्वचालित किया जा सके।