रिमोट गिट रिपोजिटरी

Question

से परिवर्तन खींचें मैं गिट करने के लिए नया हूं। मैंने जो कुछ किया है, उसमें कई रिपॉजिटरीज़ को फंसे हुए हैं और फिर उन्हें अपने कंप्यूटर पर उनके साथ काम करने के लिए क्लोन किया गया है।

कुछ मूल परियोजनाओं को महत्वपूर्ण रूप से अपडेट किया जा सकता है क्योंकि मैंने कभी भी अपनी स्थानीय प्रतियों के साथ गड़बड़ की है, या मैं कुछ महत्वहीन परिवर्तन कर सकता हूं।

जो मैं समझता हूं, उससे मैं अपने क्लोन को मूल से परिवर्तनों में "खींचने" के लिए "पुन:" कर सकता हूं।

मेरे परिवर्तनों के साथ यह क्या करता है? उदाहरण के लिए, मान लें कि मूल से DoSomething.cpp फ़ाइल है। मैं इसे संशोधित करता हूं, शायद एक छोटी सी बग ठीक कर सकता हूं या एक सुविधा जोड़ सकता हूं। अभी व! 1 साल बाद मूल परियोजना कई संशोधनों से गुजर चुकी है और यह काफी बेहतर है। मैं अपने क्लोन में उन बदलावों को "खींच" देना चाहता हूं लेकिन मेरा परिवर्तन भी रखें! (इसलिए यह पुश के विपरीत की तरह है)

क्या यह करना आसान है? यदि हां, तो मूल विचार क्या है?

मुझे क्या चाहिए कि मूल क्लोन (मेरे द्वारा बदली गई चीज़ों) से मेरे क्लोन में कोई भी परिवर्तन ओवरराइट नहीं किया गया है, लेकिन मैं वास्तव में अपने परिवर्तनों और मूल (मेरे कांटे पर) को विलय कर सकता हूं और क्षमता प्रदान कर सकता हूं वास्तव में परिवर्तनों की जांच और स्वीकार करने के लिए। (उदाहरण के लिए, यदि DoSomething.cpp मूल पर बदला गया था तो मुझे यह सुनिश्चित करने के लिए परिवर्तनों की तुलना करने की आवश्यकता है कि वे संगत हैं।

मुझे लगता है कि यह मुश्किल नहीं है क्योंकि मैं कांटा का मालिक हूं, मैं इसे रीबेस कर सकता हूं या इसे रीसेट कर सकता हूं तो (यकीन नहीं अगर यह हालांकि काम करेंगे के बाद से वहाँ वर्ज़निंग मुद्दों के लिए एक विशाल क्षमता है) मेरी कांटा करने के लिए अपने स्थानीय परिवर्तन धक्का?

Answer 1

1. पता लगाएं कि कौन शाखा जिस पर आप हैं, इस git status साथ किया जाता है, यह आपको पहली या दूसरी पंक्ति पर शाखा का नाम दिखाएगा।

2. परीक्षण के लिए , मैं एक अलग शाखा में अपने परिवर्तन बंद पहली शाखा करने के लिए सुझाव चाहते हैं:

   git checkout -b my-patches 
   

3. अब सुनिश्चित करें कि आपके सभी परिवर्तनों के लिए प्रतिबद्ध हैं बनाते हैं। इसके लिए, आप फिर से git status का आह्वान करते हैं। आदर्श रूप से यह कार्य निर्देशिका को साफ़ करना चाहिए, लेकिन यदि ऐसा नहीं है, तो सूचकांक में अपने परिवर्तन जोड़ने के लिए git add का उपयोग करें और git commit अंततः उन्हें प्रतिबद्ध करें। यदि आप अपने परिवर्तन को कई अलग-अलग पैचसेट में विभाजित करना चाहते हैं (संघर्ष होने पर आसान हो सकता है), तो मैं सुझाव देता हूं कि आप git commit -p का उपयोग कैसे करें। आप तब तक ऐसा करते हैं जब तक कि आपके सभी परिवर्तन git status में सूचीबद्ध नहीं होते हैं। ऐसी कुछ फाइलें होंगी जिन्हें आपने git status में सूचीबद्ध स्पर्श नहीं किया था, संभवतः निर्माण के परिणाम। यदि कोई बदलाव नहीं है तो आप वहां रहना चाहते हैं, तो आप ठीक हैं।

   यदि कोई मेकफ़ाइल या ऐसी निर्देशिका है जो निर्देशिका को साफ करने का समर्थन करती है (make clean उदाहरण के लिए), तो उन्हें अभी चलाएं।

4. बाद, अपने वास्तविक शाखा में वापस स्विच (स्थानापन्न master जो कुछ भी शाखा नाम के साथ आपने चरण 1 में पता चला) का उपयोग:

   git checkout master 
   

   क्या आप वाकई सब कुछ बनाना चाहते हैं काम किया, चलाएँ:

   git diff my-patches 
   

   यह आपके फोर्क में परिवर्तित लाइनों को सूचीबद्ध करना चाहिए।यदि नहीं, तो कुछ गलत हो गया।

5. अब डरावना हिस्सा आता है। आप अब इस शाखा में किए गए किसी भी बदलाव को फेंक देंगे। ध्यान दें कि, यदि आपने चरण 3 में वर्णित अनुसार अलग-अलग शाखाओं में अपने सभी परिवर्तन किए हैं, तो वे ठीक होंगे। यदि आप अनिश्चित हैं, तो आप संपूर्ण भंडार फ़ोल्डर की प्रतिलिपि बनाकर बैकअप बना सकते हैं। तो फिर तुम चलाने (फिर से, स्थानापन्न जो कुछ भी साथ master आप पहले था):

   git fetch 
   git reset --hard origin/master 
   

6. आदर्श रूप में, अपनी शाखा अब origin/master शाखा की सटीक राज्य होना चाहिए। सुनिश्चित करें कि सबकुछ ठीक दिखता है। तो फिर तुम का उपयोग कर अपने परिवर्तनों को मर्ज:

   git merge my-patches 
   

   Git यह परेशानी से मुक्त संभव के रूप में इसे बनाने के लिए सबसे अच्छा है क्या करेंगे, लेकिन वहाँ संभवतः संघर्ष किया जाएगा। गिट उन संबंधित फाइलों में >>>> और `<<<< मार्करों को चिह्नित करेगा। संघर्षों को हल करने के लिए, मेरा सुझाव है कि आप कुछ इंटरनेट शोध करें या the section about Basic Merge Conflicts in the open Git Book पर पढ़ लें। बाद में मर्ज करने के लिए सुनिश्चित करें।

7. कठिन हिस्सा खत्म हो गया है।

   git branch -d my-patches 
   

   कारण मैं अस्थायी शाखा इस्तेमाल किया आसानी से मर्ज प्रयास करने से पहले एक के लिए भंडार की स्थिति वापस लौटने के लिए सक्षम होने के लिए है: अब आप अस्थायी शाखा हटा सकते हैं। एक निश्चित रूप से एक अलग शाखा में रिमोट स्टेटस की जांच भी कर सकता था, लेकिन मैं इसे पसंद करता हूं।

Answer 2

आप सही हैं, रिबेसिंग एक तरीका है जिससे आप अपना कोड अद्यतित रख सकते हैं, और ऐसा करने के लिए आमतौर पर उपयोग किया जाता है।

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

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

Answer 3

क्या आपने अपने फोर्क वाले रेपो को अपस्ट्रीम रिमोट जोड़ दिया था? अपने फोर्क को इसके मास्टर के साथ सिंक में रखने का यह सबसे आसान तरीका है। यह चरण 3 here है।

Answer 4

सबसे पहले आपको पता होना चाहिए कि कि क्या आप "मर्ज" या "rebase" आप अपने परिवर्तन खो देंगे नहीं और Git आप अपने परिवर्तन & संघर्ष (यदि हो तो) को हल करने का मौका दे देंगे और फिर अपने संशोधनों को धक्का रिमोट रेपो पर वापस आप खींच रहे हैं।

जब आप git pull आप Git कह रहे हैं यह करने के लिए:

दूरदराज से फाइल की नवीनतम प्रति खींच, उन्हें अपने स्थानीय परिवर्तन & अगर साथ विलय (पुल डिफ़ॉल्ट उपयोग करने के लिए "मर्ज" है) एक संघर्ष है कि आप स्वचालित रूप से हल नहीं कर सकते हैं तो मुझे सूचित करें ताकि मैं इसे मैन्युअल रूप से हल कर सकूं; यह सीधा है।

जब आप git pull --rebase आप Git कह रहे हैं यह करने के लिए:

अस्थायी निकालें * अपने स्थानीय प्रतिलिपि से परिवर्तन (मेरे संशोधित फ़ाइलों), रिमोट से नवीनतम प्रतिलिपि खींच पर अपने परिवर्तनों को मर्ज इसके ऊपर & यदि कोई ऐसा संघर्ष है जिसे आप स्वचालित रूप से हल नहीं कर पा रहे हैं तो मुझे सूचित करें ताकि मैं इसे मैन्युअल रूप से हल कर सकूं। (तकनीकी रूप से कुछ भी नहीं निकाल दिया जाता है, यह इस अन्यथा अस्पष्ट तर्क स्पष्ट करने के लिए बस है।)

अंतर सूक्ष्म है, दूसरे मामले में, अपने परिवर्तन के रूप में अगर तुम सिर्फ पर ये बदलाव कर लें प्रतीत रिमोट से खींची गई सबसे हालिया प्रतिलिपि के शीर्ष ... लेकिन जैसा कि आप देख सकते थे, दोनों मामलों में आपके परिवर्तन निश्चित रूप से रखे जाते हैं (अन्यथा गिट का उपयोग क्या होता है!)।

क्या आप मर्ज या रीबेस करना चाहिए? यह लंबी चर्चा है & ऐसे स्थान हैं जहां एक दूसरे से बेहतर है और इसके लिए सर्वोत्तम अभ्यास हैं; कुछ उपयोगी टिप्पणियों का पहले से ही इस पृष्ठ में उल्लेख किया गया है और अधिक जानकारी के लिए आप ऑनलाइन खोज सकते हैं, बस "गिट मर्ज बनाम रीबेस" टाइप करें और आप इसके बारे में कई पेज देखेंगे:)

उम्मीद है कि इससे मदद मिलती है।