गिथूब परियोजना को पैथ सबमिट करें बिना गिथब को भंडार क्लोनिंग?

Question

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

मैं गीथूब पर अपनी परियोजना को पुनः लोड किए बिना यह कैसे कर सकता हूं? मुझे नहीं लगता कि एक मुद्दा खोलने के लिए सही रास्ता है ..

मैं How can I contribute a patch to github? में देखा था कि मैं कांटा परियोजना, लेकिन जब से अपने स्थानीय भंडार मूल Github रिपॉजिटरी के लिए "लिंक किए गए" है, मैं नहीं करना चाहिए इसे गड़बड़ करना चाहते हैं।

इसलिए, यह है अगर वास्तव में किसी भी तरह से, लेकिन कांटा में पैच साझा करने के लिए हतोत्साहित, कैसे मैं बस, मूल परियोजना कांटा कर सकते हैं अपने परिवर्तनों को मर्ज करते हैं, और फिर उन्हें मूल भंडार के साथ साझा?

यदि मैं परिवर्तन को "प्रतिबद्ध" करने के बाद कांटा हटा देता हूं लेकिन यह अभी तक स्वीकार नहीं किया गया है, तो क्या मेरी प्रतिबद्धता गायब हो जाती है?

Answer 1

आपको परियोजना को फोर्क करना चाहिए, हां। हालांकि, इसका मतलब यह नहीं है कि आपको पूरी सामग्री को फिर से स्थानीय रूप से क्लोन करने की आवश्यकता है।

स्पष्टीकरण: गिट भंडार को देखने का एक आसान तरीका काम का एक ग्राफ है (यह निर्देशित और विश्वकोश है लेकिन यह इस चर्चा के लिए अप्रासंगिक है); और इस ग्राफ के सभी नोड्स, यानी काम करता है, दुनिया में सभी गिट भंडारों में में एक अद्वितीय पहचानकर्ता है। शाखाओं के रूप में, वे सिर्फ प्रतीकात्मक संदर्भ एक प्रतिबद्धता के लिए हैं (गिट पैरालांस, एक शाखा - या टैग में - रेफस्पेक कहा जाता है)।

इसके अलावा, आप कभी भी किसी भी तरह से रिमोट रिपोजिटरी से जुड़े नहीं हैं। एकमात्र चीज जिसे आप वास्तव में "लिंक" करते हैं वह प्रतिबद्ध ग्राफ है। रिमोट रिपोजिटरी में केवल रेफस्पेक्स (शाखाएं, टैग) का एक सेट होता है ... जो एक प्रतिबद्ध ग्राफ को इंगित करता है, जो उनके पास है - किसी को भी संदर्भों को लटकाना पसंद नहीं है। जब आप एक भंडार क्लोन करते हैं, तो आपको प्रतिबद्ध ग्राफ (और संबंधित पेड़) और रीफस्पेक्स (यानी शाखाएं, टैग) का सेट मिलता है। एक पेड़ के लिए एक refspec अंक। और यह इसके बारे में है।

इसका मतलब यह है निम्नलिखित:

• आप मूल GitHub रेपो है: प्रतिबद्ध और संबद्ध पेड़, refspecs का एक सेट का ग्राफ;
• आपने इसे स्थानीय रूप से क्लोन कर दिया है: काम करता है और संबंधित पेड़ों का एक ही ग्राफ, रेफस्पेक्स का एक ही सेट;
• आपने स्थानीय रूप से सामान किया है: आपने इस ग्राफ और संबंधित पेड़ों पर जोड़ा है, और रेफस्पेक्स का एक नया सेट जोड़ा है।
  • क्लोन GitHub पर मूल रेपो:

  ठीक है, अब निम्न कार्य करता है और मूल रूप में पेड़ों की ही ग्राफ; रेफस्पेक्स यहां हैं, केवल रिमोट नाम से पहले, जो डिफ़ॉल्ट रूप से origin है। और अब क्या?

• अपने स्थानीय भंडार पर, अपने फोर्क को रिमोट के रूप में जोड़ें;
• उस कांटा को धक्का दें (यह रेफस्पेक्स और पेड़ों को धक्का देगा);
• एक पुल अनुरोध सबमिट करें।

अपने कांटा जोड़ना एक रिमोट के रूप में के रूप में "सरल" है:

git remote add myfork git@github.com:youruser/theproject 

यह करने के लिए अपने refspec (शाखा) पुश:

git push myfork mybranch 

और फिर के लिए एक पुल का अनुरोध सबमिट करें मूल लेखक

यह ध्यान दिया जाना चाहिए कि सिद्धांत रूप में, आप एक गिट रिपोजिटरी में रिमोट जोड़ सकते हैं जिसमें "मूल" रेपो के साथ कोई प्रासंगिकता नहीं है: यह केवल इतना है कि दो प्रतिबद्ध ग्राफ पूरी तरह से एक दूसरे से अलग हो जाएंगे - हालांकि, इसके लिए उपयोग के मामले दुर्लभ हैं

Answer 2

आप हमेशा ई-मेल द्वारा रखरखाव को पैच फ़ाइल भेज सकते हैं। लिनक्स कर्नेल को बहुत लंबे समय तक इस तरह से तैयार किया गया है।

Answer 3

हां, आपको परियोजना को फोर्क करना चाहिए, लेकिन कुछ भी क्लोन/पुल/मर्ज करने की आवश्यकता नहीं है। आप कांटा बटन क्लिक करने के बाद,

git remote add yourfork git@github.com:<yourname>/<project>.git 

करते हैं और

git push yourfork branchname 

के साथ अपने कांटा करने के लिए अपने शाखा धक्का तो एक पुल अनुरोध जारी करते हैं।

यदि आप फोर्क के बाद हटाते हैं तो पैच अपस्ट्रीम द्वारा विलय किया जाता है, कोई समस्या नहीं होनी चाहिए। मुझे यकीन नहीं है कि जब ऐसा होता है तो आप अपने कांटा को हटाते हैं तो क्या होता है।

कुछ भी मर्ज करने की कोई आवश्यकता नहीं है।

Answer 4

भंडार की अपनी वर्तमान प्रतिलिपि के बिना झुकाव के बिना।

• format-patch के साथ पैच बनाएं।
• फोर्क अपस्ट्रीम और इसे क्लोन करें, लेकिन अपनी कार्यशील प्रति को प्रतिस्थापित न करें।
• नए फोर्क किए गए प्रोजेक्ट में git am के साथ पैच लागू करें, उन्हें धक्का दें और मर्ज अनुरोध बनाएं।

यह सबसे अच्छा समाधान नहीं है, लेकिन यह आपको अपने परिवर्तनों को गलती से खोने से रोकता है।