git - कोड समीक्षा के बाद पुल अनुरोध अपडेट करने के लिए पसंदीदा गीथब वर्कफ़्लो




version-control github (2)

मैंने गीथूब पर एक ओपन सोर्स प्रोजेक्ट में बदलाव जमा कर दिया है, और कोर टीम के सदस्यों में से एक से कोड समीक्षा टिप्पणियां प्राप्त की हैं।

मैं समीक्षा टिप्पणियों को ध्यान में रखते हुए कोड अपडेट करना चाहता हूं, और इसे पुनः सबमिट कर दूंगा। ऐसा करने के लिए सबसे अच्छा वर्कफ़्लो क्या है? गिट / गीथूब के सीमित ज्ञान से, मैं निम्न में से कोई भी कर सकता हूं:

  1. कोड को एक नई प्रतिबद्धता के रूप में अपडेट करें, और मेरे पुल अनुरोध में प्रारंभिक और अद्यतन दोनों प्रतिबद्धता जोड़ें।

  2. किसी भी तरह (??) मेरे भंडार से पुरानी प्रतिबद्धता को रोलबैक करता है, और सबकुछ युक्त एक नया प्रतिबद्ध बनाता है, उसके लिए एक पुल अनुरोध उठाएं?

  3. git commit में एक संशोधन सुविधा है, लेकिन मैंने सुना है कि आपके स्थानीय भंडार के बाहर प्रतिबद्धता को धक्का देने के बाद आपको इसका उपयोग नहीं करना चाहिए? इस मामले में मैंने अपने स्थानीय पीसी पर बदलाव किया है और परियोजना की मेरी जिथब शाखा में धक्का दिया है। क्या 'संशोधन' का उपयोग करना ठीक होगा?

  4. कुछ और?

ऐसा लगता है कि विकल्प 2/3 अच्छा होगा, क्योंकि ओपन सोर्स प्रोजेक्ट में केवल उनके इतिहास में एक प्रतिबद्धता होगी जो सब कुछ लागू करेगी, लेकिन मुझे यकीन नहीं है कि यह कैसे करें।

नोट: मुझे नहीं पता कि यह जवाब को प्रभावित करता है या नहीं, लेकिन मैंने एक अलग शाखा में बदलाव नहीं किए, मैंने अभी मास्टर के शीर्ष पर एक प्रतिबद्धता की है


पुल अनुरोध को अपडेट करने के लिए

पुल अनुरोध (बिंदु # 1) को अपडेट करने के लिए, केवल एक चीज जो आपको करने की ज़रूरत है वह चेक शाखा है जो पुल अनुरोध से है और इसे फिर से दबाएं:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

वैकल्पिक - सफाई प्रतिबद्ध इतिहास

आपको अपने कामों को एकसाथ स्क्वैश करने के लिए कहा जा सकता है ताकि रिपोजिटरी इतिहास साफ़ हो, या आप अपने पुल अनुरोध (बिंदु # 2) में "संदेश" से विचलित मध्यस्थ कामों को हटाना चाहते हैं। उदाहरण के लिए यदि आपका प्रतिबद्ध इतिहास इस तरह दिखता है:

$ git remote add parent [email protected]:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

चीजों को एक साथ स्क्वैश करना एक अच्छा विचार है ताकि वे एक ही प्रतिबद्धता के रूप में दिखाई दें:

$ git rebase -i parent/master 

यह आपको आपके पुल अनुरोध के इतिहास को फिर से लिखने का तरीका चुनने के लिए प्रेरित करेगा, निम्नलिखित आपके संपादक में होगा:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

किसी भी प्रतिबद्धता के लिए आप पिछली प्रतिबद्धता का हिस्सा बनना चाहते हैं - स्क्वैश में बदलाव करें:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

और अपने संपादक को बंद करें। गिट फिर इतिहास को फिर से लिख देगा और आपको एक संयुक्त प्रतिबद्धता के लिए प्रतिबद्ध संदेश प्रदान करने के लिए प्रेरित करेगा। तदनुसार संशोधन करें और आपका प्रतिबद्धता इतिहास अब संक्षिप्त होगा:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

अपने कांटा को पुश करें:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To [email protected]:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

और आपके पुल अनुरोध में एक ही प्रतिबद्धता होगी, जिसमें पहले से ही कई बदलावों में विभाजित सभी परिवर्तन शामिल होंगे।

सार्वजनिक repos पर इतिहास बदलना एक बुरी बात है

इतिहास को पुनर्लेखन करना और एक शाखा पर git push -f का उपयोग करना, संभावित रूप से, किसी और ने पहले से ही क्लोन किया है, यह एक बुरी चीज है - यह भंडार के इतिहास और चेकआउट को अलग करने का कारण बनती है।

हालांकि, उस परिवर्तन को सही करने के लिए अपने कांटा के इतिहास में संशोधन करना जिसे आप एक भंडार में एकीकृत करने का प्रस्ताव कर रहे हैं - एक अच्छी बात है। चूंकि आपके पुल अनुरोधों से "शोर" स्क्वैशिंग कोई आरक्षण नहीं है।

शाखाओं पर एक नोट

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

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets

पुल अनुरोध में उपयोग की जाने वाली शाखा में बस एक नई प्रतिबद्धता जोड़ें और शाखा को गिटहब पर दबाएं। पुल अनुरोध स्वचालित रूप से अतिरिक्त प्रतिबद्धता के साथ अपडेट किया जाएगा।

# 2 और # 3 अनावश्यक हैं। अगर लोग केवल तभी देखना चाहते हैं जहां आपकी शाखा को विलय कर दिया गया था (और अतिरिक्त काम नहीं करता), तो वे git log --first-parent में विलय प्रतिबद्धता को देखने के लिए git log --first-parent का उपयोग कर सकते हैं।





pull-request