पुल रिक्वेस्ट फ्लो

docs.scrimba.com

आप अपनी स्वयं की शाखा पर एक फीचर पर काम कर रहे हैं, और यह तैयार है। प्रोजेक्ट साझा किया गया है: अन्य लोग भी इसमें योगदान देते हैं, इसलिए आप सीधे main में पुश नहीं करते और सर्वश्रेष्ठ की आशा नहीं करते। आप चाहते हैं कि परिवर्तन की समीक्षा की जाए, यदि आवश्यक हो तो चर्चा की जाए, और इसे इस तरह से मर्ज किया जाए कि बाकी टीम देख सके। वह पूरा रास्ता, आपकी मशीन पर एक शाखा से लेकर कोड main में लैंड करने तक, पुल रिक्वेस्ट फ्लो है, और यह वह तरीका है जिससे GitHub पर लगभग हर टीम परिवर्तन प्राप्त करती है। इसका Git साइड केवल पिछले अध्यायों से कमांड का उपयोग करता है, एक शाखा, एक कमिट, और एक पुश:

$ git switch -c add-five-day-forecast
Switched to a new branch 'add-five-day-forecast'
$ git add src/forecast.js
$ git commit -m "Add five-day forecast panel"
$ git push -u origin add-five-day-forecast
Branch 'add-five-day-forecast' set up to track 'origin/add-five-day-forecast'.

वह पुश आपकी शाखा को GitHub में भेजता है। अभी तक कुछ भी मर्ज नहीं हुआ है, और न ही कुछ भी समीक्षा के लिए प्रस्तावित किया गया है। अगला कदम, पुल रिक्वेस्ट खोलना, GitHub की वेबसाइट पर होता है।

जब आप पुल रिक्वेस्ट खोलते हैं तो क्या होता है

GitHub पर, ऊपर दिए गए पुश के बाद, आप आमतौर पर अपनी नई शाखा की तुलना main से करने की पेशकश करने वाला एक बैनर देखेंगे। इस पर क्लिक करें, एक शीर्षक और संक्षिप्त विवरण लिखें कि क्या बदला और क्यों, और यह पृष्ठ खोलें जो यह बनाता है। वह पृष्ठ एक पुल रिक्वेस्ट है, जिसे अक्सर PR में संक्षिप्त किया जाता है: एक शाखा को दूसरे में मर्ज करने का अनुरोध, जिसके साथ एक चलती हुई बातचीत जुड़ी होती है।

एक पुल रिक्वेस्ट एक मर्ज का प्रस्ताव देती है और अनुमोदन की प्रतीक्षा करती है। कोई, शायद आप, शायद एक टीम का सदस्य, परिवर्तन को पढ़ता है, टिप्पणियां छोड़ता है, और केवल जब यह सही दिखता है तो इसे मर्ज करता है। जब तक ऐसा नहीं होता, आपकी शाखा और main बिल्कुल वैसे ही रहते हैं जैसे वे पहले थे।

आपको एक फीचर समाप्त होने तक PR खोलने की प्रतीक्षा नहीं करनी है। कई टीमें इसे जल्दी खोलती हैं और इसे ड्राफ्ट के रूप में चिह्नित करती हैं, जो "समीक्षा के लिए तैयार नहीं" का संकेत देता है जबकि समीक्षकों को काम पूरा होने से पहले दिशा पर टिप्पणी करने के लिए एक जगह देता है। एक अच्छा विवरण किसी भी संबंधित समस्या को जोड़ता है और कहता है कि आपने क्या परीक्षण किया, इसलिए समीक्षक को अकेले diff से इसे पुनर्निर्माण नहीं करना पड़ता।

GitHub प्रत्येक पुल रिक्वेस्ट के लिए दूरस्थ पर एक संदर्भ रखता है, भले ही आप PR की शाखा को अपने स्वयं की रिपोजिटरी में जोड़ने से पहले: refs/pull/<number>/head। इसे सीधे प्राप्त करें अपनी मशीन पर एक टीम के सदस्य के PR को चेक आउट करने के लिए, बिना पहले उनके फोर्क को एक दूरस्थ के रूप में जोड़े।

$ git fetch origin pull/42/head:pr-42
From github.com:mara-chen/weather-app
 * [new ref]         refs/pull/42/head -> pr-42
$ git switch pr-42
Switched to branch 'pr-42'

अब pr-42 पुल रिक्वेस्ट संख्या 42 से बनी एक वास्तविक स्थानीय शाखा है, चलाने और परीक्षण के लिए तैयार है इससे पहले कि आप एक भी टिप्पणी छोड़ें।

Junoजब आप पुल रिक्वेस्ट खोलते हैं तो क्या होता है एक पुल रिक्वेस्ट आपकी शाखा को दूसरे में मर्ज करने का अनुरोध है, जो आप पुश करने के बाद GitHub पर खोला जाता है। कोई पहले परिवर्तन की समीक्षा करता है, और केवल तभी यह मर्ज होता है। रोज़मर्रा का लूप है शाखा, पुश, पुल रिक्वेस्ट खोलें, समीक्षा प्राप्त करें, मर्ज करें।

Junoजब आप पुल रिक्वेस्ट खोलते हैं तो क्या होता है एक PR एक मर्ज का प्रस्ताव देता है और इसके चारों ओर बातचीत रखता है, और आप काम समाप्त होने से पहले प्रतिक्रिया प्राप्त करने के लिए जल्दी ड्राफ्ट के रूप में खोल सकते हैं। विवरण लिखें जैसे कि एक समीक्षक वास्तव में इसे पढ़ेगा: क्या बदला, क्यों, और आपने क्या परीक्षण किया।

Junoजब आप पुल रिक्वेस्ट खोलते हैं तो क्या होता है GitHub प्रत्येक पुल रिक्वेस्ट के लिए एक छुपा हुआ संदर्भ रखता है, refs/pull/<number>/head, इसलिए आप एक टीम के सदस्य के PR को git fetch origin pull/42/head:pr-42 के साथ सीधे अपनी मशीन पर प्राप्त कर सकते हैं उनके फोर्क को एक दूरस्थ के रूप में जोड़ने के बजाय। आपनी पहली टिप्पणी छोड़ने से पहले परिवर्तन को स्थानीय रूप से परीक्षण करें।

फोर्क बनाम शाखा

एक शाखा से पुल रिक्वेस्ट खोलना तब काम करता है जब आपके पास रिपोजिटरी तक लिखने की पहुंच हो, जो आपकी स्वयं की टीम के प्रोजेक्ट्स पर सामान्य स्थिति है। एक प्रोजेक्ट में योगदान देने के लिए जिसमें आपके पास लिखने की पहुंच नहीं है, एक अतिरिक्त कदम की आवश्यकता है: एक फोर्क, आपके स्वयं के GitHub खाते के तहत रिपोजिटरी की आपकी स्वयं की प्रति।

आप अपने फोर्क के अंदर ठीक वैसे ही शाखा और कमिट करते हैं जैसे आप एक प्रोजेक्ट में करते हैं जिसका आप मालिक हैं, अपने फोर्क में पुश करते हैं, और फिर अपने फोर्क की शाखा से मूल रिपोजिटरी तक पुल रिक्वेस्ट खोलते हैं। GitHub एक ही तरीके से दोनों रिपोजिटरीज की तुलना करता है जैसे यह एक रिपोजिटरी के अंदर दो शाखाओं की तुलना करता है, इसलिए समीक्षा और मर्ज फ्लो दोनों तरीकों से समान दिखता है।

अगर आप एक प्रोजेक्ट के लिए एक से अधिक PR भेजने की योजना बनाते हैं जिसे आपने फोर्क किया है, तो मूल रिपोजिटरी को दूसरे दूरस्थ के रूप में जोड़ना लायक है, आमतौर पर upstream नाम दिया जाता है, जबकि origin आपके स्वयं के फोर्क की ओर इशारा करता रहता है। git fetch upstream चलाएं और upstream/main को अपनी शाखा में मर्ज करें एक प्रोजेक्ट के साथ तालमेल रखने के लिए जो आपके फोर्क करने के बाद आगे बढ़ गया है, दूरस्थ और GitHub अध्याय जो किसी भी दूरस्थ के लिए कवर करता है।

Junoफोर्क बनाम शाखा जब आपके पास रिपोजिटरी तक लिखने की पहुंच हो, तो सीधे शाखा बनाएं, आपकी स्वयं की टीम के प्रोजेक्ट्स। फोर्क करें जब आपके पास न हो: एक फोर्क किसी और की रिपोजिटरी की आपकी स्वयं की प्रति है, और आप मूल में पुल रिक्वेस्ट खोलने से पहले उस प्रति के अंदर शाखा और पुश करते हैं।

Junoफोर्क बनाम शाखा एक फोर्क आपके खाते के तहत एक रिपोजिटरी की पूरी प्रति है, जिसका उपयोग वहां योगदान देने के लिए किया जाता है जहां आपके पास लिखने की पहुंच नहीं है। आप सामान्य रूप से अपने फोर्क के अंदर शाखा, कमिट, और पुश करते हैं, और GitHub आपके फोर्क की शाखा की तुलना मूल रिपोजिटरी से ठीक वैसे ही करता है जैसे यह एक प्रोजेक्ट के अंदर दो शाखाओं की तुलना करता है।

Junoफोर्क बनाम शाखा एक फोर्क किए गए प्रोजेक्ट पर दो दूरस्थ रखें: origin आपने अपने फोर्क के लिए, upstream मूल रिपोजिटरी के लिए, इसलिए आप जब यह आगे बढ़े तो इसके परिवर्तन प्राप्त और मर्ज कर सकते हैं। PR स्वयं अभी भी आपके फोर्क की शाखा की तुलना मूल रिपोजिटरी की आधार शाखा से करता है।

अपनी पुल रिक्वेस्ट को समीक्षा के माध्यम से प्राप्त करना

एक बार PR खुलने के बाद, यह diff के बारे में एक चलती हुई बातचीत बन जाता है। एक समीक्षक परिवर्तन को पढ़ता है, विशिष्ट पंक्तियों पर टिप्पणियां छोड़ता है, और इसे अनुमोदित करता है या परिवर्तन का अनुरोध करता है। जब परिवर्तन का अनुरोध किया जाता है, तो उसी शाखा में कमिट और पुश करते रहें: प्रत्येक पुश एक ही PR को अपडेट करता है बजाय एक नया बनाने के। एक बार समीक्षक अनुमोदित करता है और कोई भी आवश्यक जांच पास होती है, PR मर्ज करने के लिए तैयार होता है।

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

एक PR को कितने अनुमोदन की आवश्यकता है, और क्या हर टिप्पणी थ्रेड को मर्ज बटन अनलॉक होने से पहले हल के रूप में चिह्नित किया जाना है, आमतौर पर एक अच्छी तरह से चलाए जाने वाले प्रोजेक्ट पर आधार शाखा से जुड़ा एक नियम होता है।

Junoअपनी पुल रिक्वेस्ट को समीक्षा के माध्यम से प्राप्त करना एक समीक्षक आपकी पुल रिक्वेस्ट पर टिप्पणी करता है और परिवर्तन मांग सकता है। इसे संबोधित करने के लिए उसी शाखा में अधिक काम कमिट और पुश करें, और PR अपने आप अपडेट होता है। मर्ज करना तब होता है जब कोई अनुमोदित करता है।

Junoअपनी पुल रिक्वेस्ट को समीक्षा के माध्यम से प्राप्त करना समीक्षाएं तीन राज्यों में से एक में आती हैं: अनुमोदित, परिवर्तन का अनुरोध किया गया, या टिप्पणी की गई। PR को अपडेट करने के लिए उसी शाखा में फिक्स पुश करें, जैसे-जैसे आप उन्हें हल करते हैं टिप्पणियों का जवाब दें, और एक लंबे थ्रेड में समीक्षक को उन्मुख रखें।

Junoअपनी पुल रिक्वेस्ट को समीक्षा के माध्यम से प्राप्त करना समीक्षा राज्य यह चलाते हैं कि मर्ज बटन अनलॉक होता है या नहीं, लेकिन सटीक बार, कितने अनुमोदन, क्या हर टिप्पणी थ्रेड को हल किया जाना चाहिए, आमतौर पर एक अच्छी तरह से चलाए जाने वाले प्रोजेक्ट पर आधार शाखा से जुड़ा एक नियम है।

पुल रिक्वेस्ट मर्ज क्यों नहीं होगी

कभी-कभी PR पर मर्ज बटन ग्रे आउट होता है, और GitHub इसके बजाय एक संदेश दिखाता है: "इस शाखा के पास ऐसे संघर्ष हैं जिन्हें हल किया जाना चाहिए" या "यह शाखा आधार शाखा से पुरानी है।" दोनों संदेश एक सामान्य, ठीक किए जाने वाली स्थिति का वर्णन करते हैं: main आपकी शाखा के बाद से आगे बढ़ गया है, आमतौर पर क्योंकि किसी और का PR इस बीच मर्ज हो गया है, और आपकी शाखा को GitHub को दोनों को स्वच्छ रूप से संयोजित करने में सक्षम करने से पहले पकड़ना होगा। यह एक से अधिक योगदानकर्ता वाले किसी भी प्रोजेक्ट पर होता है, इसलिए इससे डरने के बजाय इसकी अपेक्षा करें।

इसे स्थानीय रूप से ठीक करें उसी तरीके से जैसे आप कोई भी दो शाखाओं को एक साथ लाएंगे:

$ git switch add-five-day-forecast
$ git fetch origin
From github.com:mara-chen/weather-app
   9f8e7d6..b7c9e21  main       -> origin/main
$ git merge origin/main

अगर कुछ भी ओवरलैप नहीं होता है, तो मर्ज अपने आप पूरा हो जाता है और आप पुश करते हैं, और PR अपडेट होता है और बटन अनलॉक होता है। अगर एक ही पंक्तियां दोनों तरफ बदल गईं, तो Git आपको फ़ाइल में संघर्ष को चिह्नित करता है जिसे आप ठीक वैसे ही हल कर सकते हैं जैसे मर्ज करना और संघर्ष में कवर किया गया है: फ़ाइल खोलें, संघर्ष मार्कर को आप चाहते हैं परिणाम के लिए संपादित करें, फिर git add और git commit मर्ज को समाप्त करने के लिए, और फिर से पुश करें।

एक अटकी हुई पुल रिक्वेस्ट को पकड़ने या इसके संघर्ष को हल करने की आवश्यकता है।

एक PR पर जो एक या दो दिन से अधिक समय तक खुली रहती है, यह हर कुछ समय में main को आपकी शाखा में मर्ज करने के लिए लायक है बजाय बटन को ब्लॉक करने की प्रतीक्षा करने के। एक शाखा जो एक दिन पुरानी है आमतौर पर कोई संघर्ष के बिना मर्ज करती है; एक जो तीन सप्ताह पुरानी है, दो परिवर्तनों के लिए समान पंक्तियों पर टकराने के लिए बहुत अधिक सतह है। GitHub के अपने "Update branch" बटन PR पेज पर यह कर देता है जब कुछ भी हाथ से हल करने के लिए नहीं होता है।

कुछ टीमें एक फीचर शाखा को main पर रीबेस करती हैं बजाय इसे मर्ज करने के, अंतिम इतिहास को रैखिक रखने के लिए बजाय प्रत्येक PR के लिए एक मर्ज कमिट दिखाने के। वह ट्रेड-ऑफ मर्ज करना और संघर्ष में कवर किया गया है: रीबेसिंग आपकी शाखा की कमिट को फिर से लिखता है, जो जब तक आप केवल यह करते हैं तब तक सुरक्षित है, इसलिए एक एकल फीचर शाखा जो केवल आपकी मशीन पर रहती है और इसका PR एक उचित उम्मीदवार है। एक शाखा को रीबेस करना कि अन्य लोग पहले से ही खींच चुके हैं और उस पर निर्मित हैं, नहीं है, क्योंकि यह इतिहास को फिर से लिखता है कि वे भरोसा कर रहे हैं।

Junoपुल रिक्वेस्ट मर्ज क्यों नहीं होगी एक ग्रे आउट मर्ज बटन का मतलब है कि आपकी शाखा main के पीछे है या इसके साथ एक संघर्ष है। कुछ भी टूटा नहीं है। अपनी शाखा को स्विच करें, प्राप्त करें, और main को मर्ज करें, किसी भी संघर्ष को हल करते हुए जैसे आप अन्यत्र करते हैं, फिर फिर से पुश करें।

Junoपुल रिक्वेस्ट मर्ज क्यों नहीं होगी GitHub को मर्ज बटन को ब्लॉक करने की प्रतीक्षा करने के बजाय हर इतने समय में main को लंबे समय तक चलने वाली शाखा में मर्ज करें। छोटे, अधिक बार पकड़ने का मतलब छोटे संघर्ष हैं, और GitHub के "Update branch" बटन आपके लिए बिना संघर्ष के मामले को कर सकते हैं।

Junoपुल रिक्वेस्ट मर्ज क्यों नहीं होगीmain पर अपनी शाखा को मर्ज करना या रीबेस करना दोनों एक अटकी हुई PR को ठीक करते हैं, और एक एकल फीचर शाखा रीबेस करने के लिए सुरक्षित है क्योंकि किसी और के पास इसकी कमिट की प्रति नहीं है। एक बार अन्य लोगों ने एक शाखा को खींच लिया, इसे मर्ज करने के बजाय मर्ज करते रहें।

पुल रिक्वेस्ट क्या है, हुड के नीचे

एक पुल रिक्वेस्ट एक Git ऑब्जेक्ट नहीं है, और कोई git कमांड नहीं है जो एक को बनाता है। Git और GitHub एक ही चीज़ नहीं हैं: Git केवल कमिट, शाखाओं, और अन्य रेफ्स के बारे में जानता है (एक रेफ एक नाम है जो एक कमिट की ओर इशारा करता है)। GitHub दो रेफ्स की तुलना करके पूरे PR पृष्ठ, टिप्पणियां, और मर्ज बटन बनाता है: आपकी शाखा (head) और जिस शाखा में आप मर्ज कर रहे हैं (base, आमतौर पर main)। यह तुलना है कि आप GitHub की वेबसाइट पर (या GitHub के अपने कमांड-लाइन टूल या API के माध्यम से) पुल रिक्वेस्ट खोलते हैं, और कभी भी एक सादे git कमांड के साथ नहीं।

क्योंकि एक PR GitHub पर रहता है, रिपोजिटरी के इतिहास से अलग, इसकी टिप्पणियां और समीक्षा बातचीत कमिट के साथ यात्रा नहीं करती है। अगर आप कभी भी एक प्रोजेक्ट को एक अलग होस्ट में स्थानांतरित करते हैं, तो हर कमिट आपके साथ अपरिवर्तित होता है, लेकिन पुल रिक्वेस्ट और उनकी चर्चाएं GitHub पर पीछे रह जाती हैं, क्योंकि वे कभी Git डेटा का हिस्सा नहीं थीं।

GitHub मर्ज बेस को खोजकर PR के अंतर की गणना करता है, सबसे हाल की कमिट जो head रेफ और base रेफ दोनों साझा करते हैं, और इसके बजाय head की तुलना उस बिंदु के विरुद्ध करते हैं कि main अभी कैसा दिखता है। शाखा के लिए प्रत्येक पुश एक ही PR के लिए एक नया संस्करण जोड़ता है बजाय एक नई तुलना बनाने के। शाखा सुरक्षा सब कुछ के ऊपर बैठी नीति परत है: एक नियम जिसे आप (या आपका संगठन) एक शाखा के लिए संलग्न करते हैं, अक्सर main, जो अतीत की स्थिति जांच की आवश्यकता कर सकता है, अनुमोदन समीक्षाओं की एक निर्धारित संख्या की आवश्यकता कर सकता है, और सीधी पुश को ब्लॉक कर सकता है ताकि हर परिवर्तन एक पुल रिक्वेस्ट के माध्यम से मजबूर हो। Git स्वयं इसमें से कोई भी लागू नहीं करता है। यह आपको अपने टर्मिनल से सीधे main में पुश करने देगा जब तक GitHub का नियम अनुरोध को अस्वीकार नहीं करता।

Junoपुल रिक्वेस्ट क्या है, हुड के नीचे एक पुल रिक्वेस्ट Git के ऊपर परतदार एक GitHub सुविधा है: Git कमिट और शाखाओं को ट्रैक करता है, और GitHub PR पृष्ठ और मर्ज बटन जोड़ता है उनमें से दो की तुलना करके। Git और GitHub को अलग रखना आपके सिर में बहुत कुछ समझाता है जो अन्यथा जादू की तरह दिखता है।

Junoपुल रिक्वेस्ट क्या है, हुड के नीचे एक PR आपकी शाखा की तुलना एक आधार शाखा के विरुद्ध करता है और पूरी तरह GitHub पर रहता है, इसलिए इसकी टिप्पणियां और समीक्षा इतिहास नहीं चलती है अगर रिपोजिटरी कभी भी होस्ट बदलता है। कमिट स्वयं ही एकमात्र हिस्सा है जो वास्तव में Git है।

Junoपुल रिक्वेस्ट क्या है, हुड के नीचे एक PR GitHub उनके साझा मर्ज बेस से एक head रेफ की तुलना एक base रेफ के विरुद्ध करता है, प्रत्येक पुश के साथ अपडेट होता है। शाखा सुरक्षा शीर्ष पर लागू नीति है, मर्ज से पहले जांच या समीक्षा की आवश्यकता होती है। Git स्वयं इसमें से कोई भी लागू नहीं करता है: यह आपको सीधे main में पुश करने देगा जब तक GitHub का नियम इसे नहीं रोकता।