Git में pull request: यह क्या है और GitHub पर PR कैसे बनाएँ

Pull request (PR) बदलाव को एक branch से दूसरी में मिलाने का प्रस्ताव है, जो GitHub जैसे प्लेटफ़ॉर्म पर लिखा जाता है। आप branch server पर भेजते हैं, PR खोलते हैं, टीम diff देखती है, पंक्तियों पर टिप्पणी करती है, automatic checks चलते हैं, और उसके बाद merge बटन दबता है। GitLab में यही तरीका merge request (MR) कहलाता है। "git pull request kya hai" का छोटा जवाब: यह वह जाँच-बिंदु है जो "मैंने कोड लिखा" और "कोड main में पहुँचा" के बीच होता है।

Pull request नाम कहाँ से आया

यह नाम ऐतिहासिक कारण से है। लेखक repository के मालिक से कहता है कि वह उसकी branch को "pull" कर ले, यानी अपने में मिला ले, इसलिए pull request। GitLab ने परिणाम के आधार पर इसे merge request, यानी मिलाने का अनुरोध, कहा। Bitbucket और Azure DevOps भी "pull request" का इस्तेमाल करते हैं। असल में दोनों एक ही हैं: स्रोत branch, लक्ष्य branch, विवरण, चर्चा, checks और merge बटन।

ध्यान रखें कि pull request Git का हिस्सा नहीं है। Git में "PR" नाम की कोई चीज़ नहीं है, उसे commit से नहीं बनाया जा सकता और .git फ़ोल्डर में नहीं ढूँढा जा सकता। यह प्लेटफ़ॉर्म की चीज़ है: GitHub विवरण, टिप्पणियाँ और checks की स्थिति अपने पास रखता है, और Git केवल उन branches और commits को संभालता है जो PR में शामिल हैं।

बातचीत में डेवलपर "PR" का मतलब लगभग हमेशा pull request समझते हैं: "PR भेज दो", "PR review के लिए है", "PR merge कर दिया"। GitLab के लिए वे MR कहते हैं।

Pull request और git pull में फ़र्क

इन दोनों शब्दों के मिलते-जुलते होने से लोग अक्सर उलझते हैं। git pull remote से नए commits लाकर उन्हें आपकी वर्तमान branch में तुरंत मिला देता है। यह terminal में होने वाला स्थानीय काम है। Pull request GitHub पर एक वेब पेज है, जो एक branch को दूसरी में मिलाने का प्रस्ताव रखता है।

Git में "git pull request" नाम का कोई कमांड नहीं है। एक पुरानी utility git request-pull है, लेकिन वह केवल बदलावों के सार वाला ईमेल टेक्स्ट बनाती है और GitHub के PR से उसका संबंध नहीं है।

Pull request क्यों ज़रूरी हैं

जब प्रोजेक्ट पर अकेले काम हो, तो main में सीधे commit करना ठीक है। जैसे ही टीम में दो या ज़्यादा लोग आते हैं, main में सीधे push टूटी build और खोए काम की वजह बनने लगता है। Pull request कई समस्याएँ एक साथ सुलझाता है:

• code review — दूसरा व्यक्ति बदलाव main में जाने से पहले देखता है और वे गलतियाँ पकड़ता है जो लेखक से छूट गईं;
• स्वचालित जाँच — GitHub Actions या दूसरा CI हर PR पर tests और linters चलाता है, और लाल status वाला टूटा कोड merge नहीं होने देता;
• निर्णयों का इतिहास — साल भर बाद PR से पता चलता है कि क्या बदला गया और क्यों, चर्चा के साथ;
• दूसरों के प्रोजेक्ट में योगदान — open source में आपको लिखने का अधिकार नहीं होता, और fork से PR ही सुधार भेजने का तरीका है;
• branch protection — GitHub के नियम main में सीधे push रोक सकते हैं और मंज़ूरी वाला PR माँग सकते हैं।

GitHub पर branch से pull request कैसे बनाएँ

यह मुख्य तरीका उस टीम के लिए है जहाँ सबको repository में लिखने का अधिकार है। काम feature branch में होता है और main में बदलाव केवल PR से आते हैं।

चरण 1. ताज़ा main से branch बनाएँ

git switch main
git pull
git switch -c feature/login-form

Branch का नाम सार्थक रखें: feature/…, fix/…, या task नंबर। Reviewer को तुरंत समझ आ जाता है कि बात किस पर है।

चरण 2. commit करें

git add src/login.js
git commit -m "लॉगिन फ़ॉर्म जोड़ें"

एक PR में एक task। 100–300 पंक्तियों का छोटा PR जल्दी और ध्यान से देखा जाता है, जबकि 3000 पंक्तियों पर reviewer बिना देखे मंज़ूरी दे देता है।

चरण 3. branch server पर भेजें

git push -u origin feature/login-form

-u स्थानीय branch को remote branch से जोड़ता है, और उसके बाद सादा git push काफ़ी है। GitHub जवाब में PR बनाने का लिंक खुद दिखाता है:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

चरण 4. वेब पर PR खोलें

Terminal में दिए लिंक पर जाएँ, या GitHub पर repository खोलें। ताज़ा push के बाद वहाँ "Compare & pull request" बटन वाली पट्टी दिखती है। एक और रास्ता Pull requests टैब और New pull request बटन है।

1. जोड़ी जाँचें: base — कहाँ मिलाना है (आमतौर पर main), compare — आपकी branch।
2. शीर्षक लिखें: क्या किया गया, संक्षेप में या आदेश के रूप में।
3. विवरण में बताएँ कि क्यों, कैसे जाँचें और क्या बाकी है। अगर repository में PR का टेम्पलेट है, तो खाने अपने आप भर जाते हैं।
4. दाईं ओर reviewers, assignee और labels चुनें, अगर टीम उनका उपयोग करती है।
5. Create pull request दबाएँ, या draft चुनें (इसके बारे में आगे)।

Terminal से PR बनाना: GitHub CLI

अगर browser में जाने का मन न हो, तो GitHub का आधिकारिक tool gh है। यह Git कमांड नहीं, GitHub का अलग प्रोग्राम है, पर PR के लिए सुविधाजनक है:

gh pr create --base main --title "लॉगिन फ़ॉर्म जोड़ें" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

"git pull request कमांड" वाले सवाल का सच्चा जवाब यह है: Git branches, commits और push संभालता है, और PR प्लेटफ़ॉर्म पर बनता है, browser में, gh से, या API से।

Fork से दूसरे की repository में pull request

खुले प्रोजेक्ट में आपको लिखने का अधिकार नहीं होता। इसलिए पहले आप fork बनाते हैं, यानी GitHub पर repository की अपनी प्रति, उसमें काम करते हैं, और मूल प्रोजेक्ट को बदलाव भेजते हैं।

1. प्रोजेक्ट के पेज पर "Fork" दबाएँ, तो आपके खाते में github.com/you/project बन जाएगा।
2. अपना fork clone करें और मूल प्रोजेक्ट को दूसरे remote के रूप में जोड़ें, जिसे आमतौर पर upstream कहते हैं।
3. branch बनाएँ, commit करें और branch अपने fork पर भेजें।
4. GitHub पर PR खोलें: base repository — मूल प्रोजेक्ट, head repository — आपका fork और आपकी branch।

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "README में टाइपो सुधारें"
git push -u origin fix/typo-readme

काम शुरू करने से पहले CONTRIBUTING.md फ़ाइल पढ़ें: वहाँ अक्सर commit लिखने के नियम, tests और यह लिखा होता है कि पहले issue बनाना है या नहीं। Fork को अद्यतन रखें: git fetch upstream और अपनी branch में git rebase upstream/main, ताकि PR मूल प्रोजेक्ट से पीछे न रहे।

GitLab में merge request: क्या है और कैसे बनाएँ

GitLab का merge request, GitHub के pull request का पूरा समकक्ष है। नाम और इंटरफ़ेस का विवरण अलग है, पर प्रक्रिया वही है: branch, push, मिलाने का अनुरोध, review, merge।

MR बनाने के कुछ तरीके:

• नई branch को git push करने के बाद terminal में GitLab का दिया लिंक;
• प्रोजेक्ट के Merge requests भाग में "New merge request" बटन से स्रोत और लक्ष्य branch चुनकर;
• push के समय push options से — browser खोले बिना।

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

GitLab की शब्दावली थोड़ी अलग है: मंज़ूरी को approve कहते हैं, merge की ज़िम्मेदारी वाले व्यक्ति को assignee, और GitHub Actions की जगह GitLab CI/CD है, जो .gitlab-ci.yml फ़ाइल से चलता है। Draft MR भी होते हैं।

Pull request का review

Reviewer "Files changed" टैब खोलकर diff देखता है। किसी भी पंक्ति पर टिप्पणी लिखी जा सकती है, या तैयार बदलाव सुझाया जा सकता है (suggestion), जिसे लेखक एक बटन से लागू कर सकता है। टिप्पणियाँ एक review में इकट्ठी होकर एक साथ भेजी जाती हैं, किसी एक निर्णय के साथ:

• Comment — केवल सुझाव या सवाल, कोई निर्णय नहीं;
• Approve — बदलाव मंज़ूर;
• Request changes — काम और चाहिए, merge न करें।

अच्छा review तर्क, पठनीयता, tests और edge cases देखता है, न कि पसंद-नापसंद पर बहस करता है। फ़ॉर्मेटिंग का काम linter को सौंपें, जो CI में चलता है। लेखक हर टिप्पणी का जवाब दे: ठीक कर दिया, चर्चा की, या कारण के साथ जैसा है वैसा ही रखा।

किसी और का PR स्थानीय रूप से जाँचना (git checkout pull request)

कभी-कभी कोड अपने कंप्यूटर पर चलाकर देखना पड़ता है। अगर branch उसी repository में है, तो git fetch और git switch काफ़ी हैं। Fork से आए PR के लिए GitHub विशेष संदर्भ pull/<नंबर>/head देता है:

git fetch origin pull/57/head:pr-57
git switch pr-57

GitLab में समान संदर्भ merge-requests/<नंबर>/head कहलाते हैं। या GitHub CLI हो तो सीधे gh pr checkout 57।

Review के बाद pull request कैसे अपडेट करें

PR branch से जुड़ा होता है, किसी खास commit से नहीं। उसी branch में नए commits करके भेजें, और PR अपने आप अपडेट हो जाएगा; नया PR बनाना ज़रूरी नहीं।

git commit -am "Review की टिप्पणियाँ लागू करें"
git push

Git rebase pull request: ताज़ा main लाना

जब PR review में हो, तब main आगे बढ़ सकता है। अगर GitHub बताए कि branch पुरानी है या conflict है, तो उसे अपडेट करें। Rebase से इतिहास सीधी रेखा में रहता है:

git fetch origin
git rebase origin/main
# conflicts सुलझाएँ, git add, git rebase --continue
git push --force-with-lease

Rebase के बाद commit के hashes बदल जाते हैं, इसलिए सामान्य push रद्द होगा और force push चाहिए। --force-with-lease का उपयोग करें: यह तब तक overwrite नहीं करेगा जब तक branch पर किसी और के नए commit न आए हों। अगर उस branch पर आप अकेले नहीं हैं, तो इतिहास बदले बिना git merge origin/main से main मिलाना सुरक्षित है।

Pull request merge करना: merge, squash और rebase

जब review मंज़ूर हो और checks हरे हों, तब PR merge किया जा सकता है। GitHub तीन तरीके देता है, और repository का admin उनमें से कुछ ही चालू रख सकता है।

इंटरफ़ेस से merge वास्तव में git merge ही है, बस server पर होता है। Merge के बाद GitHub branch हटाने को कहता है, हटा दें, वह अब ज़रूरी नहीं। स्थानीय सफ़ाई:

git switch main
git pull
git branch -d feature/login-form

PR को terminal से भी merge किया जा सकता है: branch को स्थानीय रूप से main में मिलाकर push करें। GitHub पहचान लेता है कि commits base में आ गए और PR को merged दिखा देता है। लेकिन इससे checks और branch protection छूट जाते हैं, इसलिए टीमें आमतौर पर बटन से merge करती हैं।

Auto-merge और merge queue

अगर checks में समय लगता है, तो auto-merge चालू किया जा सकता है: सारी शर्तें पूरी होते ही PR अपने आप merge हो जाता है। बड़ी repositories में merge queue इस्तेमाल होती है, जो हर PR को queue के आगे वाले बदलावों के ऊपर जाँचती है, ताकि असंगत बदलावों से main न टूटे।

Draft pull request

Draft वह PR है जो अभी review के लिए तैयार नहीं है। उसे merge नहीं किया जा सकता, और reviewers को review का अनुरोध नहीं जाता। Draft इसलिए उपयोगी है कि जल्दी दिशा दिखाई जा सके, CI चलाया जा सके, या architecture पर राय ली जा सके। GitHub पर PR बनाते समय बटन के मेनू से draft चुनें, या gh pr create --draft चलाएँ। काम पूरा होने पर "Ready for review" दबाएँ। GitLab में MR के शीर्षक से पहले Draft: लिखा जाता है।

Pull request और issues का संबंध

PR के विवरण में कीवर्ड और issue नंबर लिखें, तो merge के बाद GitHub उस issue को अपने आप बंद कर देता है:

Closes #42
Fixes #17
Resolves #8

Close, fix और resolve के अलग-अलग रूप (closes, fixed, resolves) काम करते हैं। केवल #42 लिखने से लिंक बनता है, पर issue बंद नहीं होता। GitLab में Closes #42 जैसे वाक्य समान रूप से काम करते हैं।

क्या pull request या merge request हटाया जा सकता है

GitHub पर साधारण सदस्य PR को हटा नहीं सकता, केवल "Close pull request" बटन से बंद कर सकता है। बंद PR इतिहास में रहता है और फिर से खोला जा सकता है। Branch को बंद होने के बाद अलग से हटाएँ। PR को पूरी तरह हटाने का काम केवल GitHub सहायता टीम कर सकती है, जैसे किसी ने PR में secret डाल दिया हो।

GitLab में MR को लेखक या उचित अधिकार वाला सदस्य बंद कर सकता है, और हटाना प्रोजेक्ट के मालिक या admin का काम है। अगर PR में पासवर्ड या token चला गया है, तो केवल बंद करना काफ़ी नहीं: उसे तुरंत रद्द करें, क्योंकि commits server पर पहुँच चुके हैं।

Pull request की आम गलतियाँ

• main से PR। आपने अपने main में commit करके उसी से PR खोला। अगला PR पुराने बदलाव भी लेकर आएगा। हमेशा अलग branch में काम करें।
• गलत base branch। PR develop में खुला, जबकि main में होना था, या उल्टा। Base को PR के शीर्षक के पास Edit बटन से बदला जा सकता है।
• diff में फ़ालतू फ़ाइलें। Builds, node_modules, .env। इन्हें .gitignore में डालें और git rm --cached से index से हटाएँ।
• बहुत बड़ा PR। काम को कई क्रमिक PR में बाँटें।
• rebase के बाद सामान्य push। त्रुटि rejected (non-fast-forward)। --force नहीं, git push --force-with-lease चाहिए।
• conflicts। उन्हें web editor में आँख बंद करके न सुलझाएँ। main स्थानीय रूप से खींचें, सुलझाएँ और tests चलाएँ।

Git flow और दूसरी प्रक्रियाओं में pull request

Pull request किसी भी टीम प्रक्रिया में बैठता है। GitHub Flow में सीधा तरीका है: main से branch, PR, review, merge, deploy। Git flow में PR feature branches से develop में खुलते हैं, और release तथा hotfix branches भी main में PR से जाती हैं। Trunk-based विकास में PR छोटे होते हैं और कुछ घंटे चलते हैं, दिनों तक नहीं। प्रक्रिया कोई भी हो, नियम एक है: साझा branches में बदलाव केवल pull request से।

निष्कर्ष

Pull request प्लेटफ़ॉर्म की सुविधा है, Git का कमांड नहीं: server पर भेजी गई branch, और उसके साथ चर्चा, review और checks वाला पेज। GitLab में यह merge request है, बातचीत में PR और MR। PR हमेशा अलग branch से बनाएँ, उसे छोटा रखें, उसी branch में push करके अपडेट करें, और merge का तरीका प्रोजेक्ट के इतिहास के अनुसार चुनें। Forks, feature branches और pull requests इस कोर्स में व्यवहार में विस्तार से सिखाए गए हैं।