ब्रांचिंग और पुल रिक्वेस्ट

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · उन्नत

Pull request (PR) एक branch के commits को दूसरी branch में, आम तौर पर main में, merge करने का प्रस्ताव है। बदलाव को सीधे shared code में push करने की बजाय developer एक pull request खोलता है: साथी diff का review करते हैं, automated tests उस पर checks के रूप में चलते हैं, और branch तभी merge होती है जब दोनों शर्तें पूरी हों। GitLab इसे merge request कहता है।

उदाहरण: एक developer branch feature/CHK-231-bulk-discount पर एक discount rule और उसके unit tests commit करता है और main में pull request खोलता है। कुछ ही मिनटों में उसका page बदली हुई lines, reviewers और checks दिखाता है — build, lint, unit tests, API smoke tests — हर एक passed या failed।

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

Branching तय करती है कि कोई बदलाव बाकी team के काम से कब मिलता है, और इसलिए tester असल में बदलावों का कौन-सा combination test कर रहा है। हफ़्तों तक चलने वाली branches ऐसे conflicts जमा करती हैं जो सिर्फ़ merge के समय सामने आते हैं, अक्सर release से ठीक पहले।

Pull request वह आख़िरी जगह है जहाँ बदलाव छोटा, अलग और सस्ते में ठीक होने लायक है। उसे पढ़ना static testing है, और उसके checks हर push पर static analysis और automated regression tests चलाते हैं, इसलिए जो tester इसमें हिस्सा लेता है वह defects को main से बाहर रखने में मदद करता है।

Branching strategies: trunk-based development और feature branches

Branching strategy team का यह समझौता है कि कौन-सी branches होंगी, कितने समय तक रहेंगी और काम main branch तक कैसे पहुँचेगा — जिसे trunk या mainline भी कहते हैं।

Trunk-based development में हर कोई कम से कम रोज़ main में integrate करता है, सीधे या ऐसी छोटी branches से जो लगभग एक दिन में merge हो जाती हैं। अधूरे features merge होते हैं लेकिन feature flags के पीछे छिपे रहते हैं — ऐसे switches जो नए code को तैयार होने तक बंद रखते हैं। पिछले एक lesson में पढ़े continuous integration के पीछे यही model है: बदलाव छोटे रहते हैं और main release के लायक रहता है।

Feature branches में हर story या fix की अपनी branch होती है, जो main से बनती है और pull request के ज़रिए वापस आती है। Branch जितनी कम देर चलती है, team continuous integration के उतना क़रीब रहती है, जो उम्मीद करता है कि काम कम से कम रोज़ main तक पहुँचे; हफ़्तों खुली रहने वाली branches main से दूर होती जाती हैं, और merge एक जोखिम भरी घटना बन जाता है जिसमें कई untested बदलाव पहली बार मिलते हैं।

release/2.4 जैसी release branches किसी version को stabilise करती हैं; वहाँ किया गया fix main तक भी पहुँचना चाहिए, वरना defect अगली release में लौट आता है।
GitFlow जैसे भारी models एक long-lived develop branch और hotfix branches जोड़ते हैं। किसी भी model में पूछें: यह build किस branch और किस commit से बना है?

Pull requests और code review

Pull request file-दर-file उस बदलाव का diff दिखाता है जो source branch, target branch में लाएगी, और उसके आसपास सब कुछ इकट्ठा करता है: description, linked ticket, commits, अलग-अलग lines पर reviewers के comments और checks के नतीजे। Draft pull request अभी review के लिए तैयार नहीं है, लेकिन उसके checks अभी से चल सकते हैं।

हर reviewer comment, approve या changes request कर सकता है; author उसी branch पर नए commits push करके जवाब देता है, और checks फिर से चलते हैं। जब ज़रूरी approvals और checks पूरे हो जाते हैं, branch repository की settings के अनुसार merge commit के रूप में, एक squashed commit (सारे commits मिलाकर एक) के रूप में, या rebase (commits को target branch के ऊपर फिर से लगाकर) से merge होती है।

ISTQB की भाषा में pull request का review static testing है, आम तौर पर informal review। इसकी जानी-पहचानी कमज़ोरी rubber stamp है: बिना पढ़े दिया गया approval। छोटे pull requests और चार सवालों के जवाब देने वाला description (आम तौर पर Markdown में लिखा) ही असली review संभव बनाते हैं:

क्या बदला और क्यों, ticket के link के साथ।
कौन-से tests जोड़े, बदले या हटाए गए, और हाथ से क्या जाँचा गया।
जोखिम: migrations, configuration, feature flags, shared code।
इसे कैसे आज़माएँ: test data, flags, preview environment।

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: Markdown फ़ॉर्मेटर

Pull request checks के रूप में tests

Pull request पर हर push CI pipeline चला सकता है, और हर job एक status check भेजता है: pending, passed या failed। Repository के rules — GitHub पर branch protection, GitLab और Bitbucket पर merge checks — checks और approvals को ज़रूरी बना सकते हैं, और तब वे main के रास्ते पर एक quality gate बन जाते हैं।

बदलाव एक छोटी branch से pull request में जाता है, जहाँ required checks और code review साथ-साथ चलते हैं, और main branch तक तभी पहुँचता है जब दोनों पूरे हों।

1main से branchहर story या fix के लिए एक छोटी branchfeature/CHK-231-bulk-discount
2Commit और pushबदलाव, उसके tests के साथ
3Pull request खोलेंmain के मुक़ाबले diff, description, linked ticket, reviewers
4Required checksmain के साथ merge किए गए बदलाव पर build, lint, unit और API smoke tests
साथ-साथ
- 5Code reviewReviewers, tester समेत, comment, approve या request changes करते हैं
दोहराता है: Check fail या changes requested: उसी branch पर fix push करें, और checks फिर चलते हैं
गेट: सारे required checks pass और approvals पूरे
6main में mergeRepository setting के अनुसार merge commit, squash या rebase
7main पर testऐसे build पर जिसमें merged बदलाव शामिल है; उसका commit दर्ज करें

उदाहरण के तौर पर: कौन-से checks और कितने approvals ज़रूरी हैं, यह हर repository में अलग तय होता है।

Pull request checks को मिनटों में ख़त्म होना चाहिए: build, lint, unit और component tests, और कुछ API या end-to-end smoke tests। पूरा regression आम तौर पर merge के बाद या schedule पर चलता है; एक आगे का lesson यह बँटवारा समझाता है।

Tester के लिए दो बातें अहम हैं। Checks अक्सर pull request को मौजूदा target branch के साथ merge करके चलते हैं (GitHub Actions का pull_request run एक अस्थायी merge commit checkout करता है); अगर main आगे बढ़ जाए तो नतीजा पुराना पड़ सकता है, इसीलिए कुछ teams merge queue इस्तेमाल करती हैं, जो हर pull request को queue में उससे आगे खड़े pull requests के साथ मिलाकर test करती है और फिर merge करती है। और हरा check सिर्फ़ वही साबित करता है जो tests assert करते हैं: skip किया गया test, या नए output से मिलाने के लिए बदली गई expected value, हरी ही रहती है।

Discount pull request का पहला run: एक unit test fail हुआ, इसलिए merge blocked है।

Pull request #482   feature/CHK-231-bulk-discount -> main
Head commit 9f3c2e1, first run

Required checks
  passed   build                  1m 12s
  passed   lint and type check    48s
  failed   unit tests             211 passed, 1 failed
  passed   API smoke tests        18 passed

Reviews    0 of 2 required approvals

Merging is blocked: 1 required check failed, 2 approvals missing.

Worked example: review के लिए एक हरा pull request

Story CHK-231: "जिन orders का subtotal 500.00 SAR या उससे ज़्यादा है, उन्हें subtotal पर 10% discount मिलता है।" Fix के बाद pull request #482 के चारों required checks हरे हैं, एक developer approve कर चुका है, और tester दूसरा reviewer है।

Pull request #482   feature/CHK-231-bulk-discount -> main
Required checks: 4 of 4 passed     Approvals: 1 of 2

Description
  क्या बदला: subtotal 500.00 SAR से ऊपर होने पर 10% discount।
  Tests: 600.00 और 400.00 के unit tests। API tests में कोई बदलाव नहीं।
  Risk: कोई नहीं।

src/pricing/discount.ts
+  if (subtotal > 500) {
+    return round2(subtotal * 0.9);
+  }

tests/api/checkout.api.test.ts
-  expect(body.total).toBe(540.00);
+  expect(body.total).toBe(486.00);

Tester के review comments

Tester description, tests और diff पढ़ता है, संबंधित lines पर comment करता है और "request changes" चुनता है:

discount.ts पर: story कहती है "500.00 या उससे ज़्यादा", लेकिन description कहता है "ऊपर" और code कहता है subtotal > 500, इसलिए ठीक 500.00 वाले order को discount नहीं मिलता। पढ़कर मिला defect।
Unit tests पर: 600.00 और 400.00 pass होते हैं चाहे operator > हो या >=। Boundary values 499.99 (कोई discount नहीं) और 500.00 (discount के बाद 450.00) माँगें, जैसा boundary value analysis वाले lesson में था।
API test पर: expected total 540.00 से 486.00 हो गया, लेकिन description कहता है कि API tests नहीं बदले। Value नए rule के हिसाब से सही है (540.00 में से 10% कम), लेकिन हर बदली हुई expected value की वजह बतानी चाहिए।
"Risk: कोई नहीं" पर: pricing का असर totals, invoices और refunds पर पड़ता है। पूछें कि discount delivery fee और VAT से पहले लगता है या बाद में, और 500.05 का 10% कैसे round होता है।
Merge के बाद, story को main के ऐसे build पर test करें जिसमें merged बदलाव शामिल है, और उसका commit दर्ज करें।

आज़माएँ: बाउंड्री वैल्यू एनालिसिस आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

आम गलतियाँ

हरे pull request को tested मान लेना: skip किया गया test या बदली गई expected value हरी ही रहती है।
Diff और tests पढ़े बिना pull request approve कर देना, जिससे review एक rubber stamp बन जाता है।
यह जाने बिना build test करना कि वह किस branch और commit से बना है, और फिर ऐसा defect report करना जो main पर पहले ही ठीक हो चुका है।
Fail हुए check को pass होने तक re-run करते रहना, बजाय वजह पता करने के; flaky नतीजे की वजह test, environment या product में timing से जुड़ा असली defect हो सकती है।
Feature branches को हफ़्तों खुला रखना, जिससे merge release से ठीक पहले कई untested बदलाव एक साथ जोड़ देता है।

QA का नज़रिया

जिन stories को आप test करेंगे, उनके pull requests पर reviewer बनाए जाने को कहें। पहले description पढ़ें, फिर tests, फिर code: क्या हर acceptance criterion covered है, क्या boundaries और negative cases मौजूद हैं, क्या कोई test skip, delete या बदला गया, क्या description diff से मेल खाता है? Changes सिर्फ़ असली समस्याओं के लिए request करें, ताकि आपके reviews का वज़न बना रहे।

Team के साथ तय करें कि कौन-से tests required checks होंगे और किसी के fail होने पर कौन कार्रवाई करेगा। Merge के बाद मिले defect के लिए branch, commit और pull request number दर्ज करें और defect को pull request से link करें; review में मिला defect आम तौर पर merge से पहले resolve होने वाला review comment होता है।

अभ्यास

Pull request का review करें और merge का फ़ैसला लें

आपका काम

Required checks हैं build, unit tests और API smoke tests। Story CHK-245 कहती है: "User किसी order को तब तक cancel कर सकता है जब तक उसका status Placed या Paid है। Paid order cancel करने पर पूरी राशि refund होती है।" नीचे वाले pull request ने अपने सभी required checks pass किए हैं।

अपने review comments लिखें, तय करें कि approve करेंगे या नहीं, और बताएँ कि merge के बाद क्या test करेंगे।

सामग्री

Pull request #517   fix/CHK-245-cancel-order -> main
Required checks: 3 of 3 passed

Description
  क्या बदला: Placed और Paid orders cancel करने की अनुमति; Paid orders का refund।
  Tests: Placed order cancel करने का unit test।

src/orders/cancel.ts
-  if (order.status !== 'Placed') throw new CancelNotAllowed();
+  if (!['Placed', 'Paid', 'Shipped'].includes(order.status)) {
+    throw new CancelNotAllowed();
+  }
+  if (order.status === 'Paid') refund(order, order.total - order.deliveryFee);

tests/orders/cancel.test.ts
+  it('cancels a Placed order', ...);
-  it('rejects cancelling a Shipped order', ...);

चरण

Description की तुलना story और diff से करें।
लिखें कि story की कौन-सी ज़रूरतें tests cover नहीं करते।
हर बदले या हटाए गए test को जाँचें।
फ़ैसला करें, comments लिखें और नोट करें कि main पर क्या test करेंगे।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Request changes: checks सिर्फ़ इसलिए हरे हैं क्योंकि tests वह cover नहीं करते जो बदला है। Description story से मेल खाता है, diff से नहीं: उसमें न Shipped का ज़िक्र है, न हटाए गए test का, न refund से बाहर रखी गई delivery fee का।

Defect 1: allowed statuses में Shipped जोड़ दिया गया, जिसकी story इजाज़त नहीं देती, और test rejects cancelling a Shipped order इसी pull request में हटा दिया गया, इसलिए checks अब भी pass हैं। Refund सिर्फ़ Paid के लिए चलता है, इसलिए cancel किए गए Shipped order का कोई refund नहीं होगा। Shipped हटाने और test वापस लाने को कहें।

Defect 2: refund order.total - order.deliveryFee है, पूरी राशि नहीं। Product owner से पूछें कि delivery fee refundable है या नहीं, फिर code या story ठीक करें।

छूटे हुए tests: Paid order cancel करना और refund की राशि; Shipped और उसके बाद के हर status पर cancel reject होना (सिर्फ़ Placed और Paid से Cancelled में जाया जा सकता है); पहले से cancelled order को cancel करना।

Merge के बाद, main के ऐसे build पर जिसमें यह बदलाव शामिल है: एक Placed और एक Paid order cancel करें, refund जाँचें, Shipped order आज़माएँ, और commit व PR #517 दर्ज करें।

अक्सर पूछे जाने वाले सवाल

क्या pull request Git का feature है?

नहीं। Git में branches, commits और merges होते हैं; pull request Git पर बने hosting platforms का feature है, जैसे GitHub, GitLab (जहाँ इसे merge request कहते हैं), Bitbucket और Azure DevOps। Git में खुद एक git request-pull command है, लेकिन वह सिर्फ़ एक text request print करता है जो बदलावों का सार और उन्हें कहाँ से pull करना है बताता है, और जिसे आम तौर पर email से भेजा जाता है।

क्या tester को pull requests approve करने चाहिए?

अगर team testers को reviewer बनाती है, तो हाँ, उन चीज़ों के लिए जिन्हें आप परख सकते हैं: tests acceptance criteria को कितना cover करते हैं, tests की quality, testability और risk। Production code की हर line परखना ज़रूरी नहीं। Review में लिखें कि आपने क्या जाँचा, ताकि आपके approval को उससे ज़्यादा न समझा जाए जितना वह है।

Testing के लिए क्या बेहतर है: trunk-based development या feature branches?

दोनों तब ठीक काम करते हैं जब बदलाव छोटे हों, लगभग एक दिन में merge हों, और हर merge अपने-आप test हो। Trunk-based development मज़बूत automated checks और feature flags पर टिका है, इसलिए testers features को flag on और flag off दोनों हालत में test करते हैं। लंबी चलने वाली branches दोनों models में जोखिम वाला मामला हैं, क्योंकि integration और उसकी testing देर से होती है।

संदर्भ

About pull requestsGitHubpull request क्या है: एक branch के बदलावों को दूसरी में merge करने का प्रस्ताव, जहाँ merge से पहले चर्चा, review और checks होते हैं।
Pro Git, 2nd Edition (Scott Chacon and Ben Straub)Apress · 2014Pro Git किताब, ऑनलाइन मुफ़्त पढ़ने के लिए: Git की बुनियादी बातें, branching और merging, distributed workflows, और Git अपना डेटा कैसे स्टोर करता है।
Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
Code Review Developer GuideGoogle (eng-practices)Google की प्रकाशित code review प्रथाएँ: reviewer क्या देखते हैं, बदलाव मंज़ूर करने का मानक और review टिप्पणियाँ कैसे लिखें।

ब्रांचिंग और पुल रिक्वेस्ट

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

Branching strategies: trunk-based development और feature branches

Pull requests और code review

Pull request checks के रूप में tests

Worked example: review के लिए एक हरा pull request

Tester के review comments

आम गलतियाँ

QA का नज़रिया

अभ्यास

Pull request का review करें और merge का फ़ैसला लें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

टेक्स्ट डिफ़

बाउंड्री वैल्यू एनालिसिस

रिग्रेशन सिनेरियो जनरेटर

Markdown फ़ॉर्मेटर

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Branching strategies: trunk-based development और feature branches

Pull requests और code review

Pull request checks के रूप में tests

Worked example: review के लिए एक हरा pull request

Tester के review comments

आम गलतियाँ

QA का नज़रिया

अभ्यास

Pull request का review करें और merge का फ़ैसला लें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics