क्या गितुब पर अपने पुल अनुरोधों को वापस करने के लिए योगदानकर्ताओं से पूछना सही है

मैं अपेक्षाकृत लोकप्रिय गीथूब रेपो बनाए रखता हूं।

जब एक पुल अनुरोध मर्ज करने के लिए अच्छा होता है, तो मैं आमतौर पर लेखक से कहता हूं कि मैं इसे मर्ज करने से पहले इसे एक ही प्रतिबद्ध करने के लिए (विशेषकर जब कई छोटे संपादन किए गए हों)।

क्या यह अच्छा अभ्यास है? क्या यह स्वीकार्य / मानक GitHub शिष्टाचार है?

तो कुछ लाभ:

मुझे कमिट्स में एक अच्छा क्लीन कमिट हिस्ट्री मिलता है
मुझे खुद को कमिट करने की जरूरत नहीं है
यह कुछ काम को दर्शाता है

कुछ संभावित कमियां:

मुझे यकीन नहीं है कि यह अच्छा शिष्टाचार है
मुझे यकीन नहीं है कि यह एक अच्छा अभ्यास है
मैंने आमतौर पर पहले से ही कुछ अन्य बदलावों के लिए कहा है - यह एक और है और मैं योगदानकर्ताओं को हतोत्साहित नहीं करना चाहता।

github etiquette

— Pablojim
स्रोत

क्या आप इस तरह से इस प्रक्रिया को करने में दिखाई देने वाले कुछ लाभों और कमियों का वर्णन कर सकते हैं?

— एलेक्स फीमैन ने

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

— गैंकरो

मानक स्थापित करने में कुछ भी गलत नहीं है। बस यह स्पष्ट करें कि क्या अपेक्षित है। उदाहरण: symfony.com/doc/current/contributing/code/patches.html नीचे चरण 3 तक स्क्रॉल करें: अपना पैच सबमिट करें

— Cerad

@Granko: "रिबेस" और "एक कमिट में रीबेज़" दो अलग-अलग मुद्दे हैं।

— मैथ्यू शार्ले

यदि एक योगदानकर्ता को ऐसा करने के लिए कहा जाता है, तो क्या उन्हें इसके साथ पुल अनुरोध की शाखा को अधिलेखित करना चाहिए git push -f?

— फ्लिम्म

जहां तक गिट की बात है, तो यह एक पवित्र युद्ध की बात है कि क्या आपको केवल शाखाओं का विलय करना चाहिए या जिस शाखा में आप विलय कर रहे हैं, उसके नवीनतम संस्करण पर रिबास शुरू होता है। यदि आप Programmers.SE पर त्वरित खोज करते हैं तो बहुत सारी बातचीत बेहतर है ।

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

इसके अलावा, विशेष रूप से GitHub (न्यूनतम पर) के लिए, वे CONTRIBUTINGकिसी भी पीआर प्रयासों के ऊपर आपकी फ़ाइल के लिए एक लिंक प्रदर्शित करेंगे ताकि आपकी अपेक्षाओं को रेखांकित करने के लिए एक अच्छी जगह बने और कई परियोजनाओं में यह शामिल है कि वे केवल तारीख शाखाओं में विलय कर देंगे।

— मैथ्यू शार्ले
स्रोत

चर्चा में व्यावहारिकता लाने के लिए +1। हां, यह पूरा मामला है। बड़े पुल अनुरोधों में जटिल संघर्षों को हल करना काफी कठिन हो सकता है, खासकर जब निश्चित संख्या में कमिट शामिल होते हैं। यही वह बिंदु है जहां मूल लेखक को झंकार करने के लिए कहा जाना चाहिए। आसान संघर्ष मुद्दा नहीं हैं, वे कभी नहीं थे और कभी नहीं होंगे।

— जेन्सजी

+1 वास्तव में एक उत्तर देने के लिए और सिर्फ टिप्पणियां नहीं देने के लिए!

— पाब्लोझिम