रिबेस की गई शाखाओं के गिट सिंक्रनाइज़ेशन

Question

मेरे पास हाल ही में एक बहु-कंप्यूटर गिट विकास सेटअप के बारे में question answered था, और जिस समाधान में मैंने वहां पहुंचा, master शाखा के साथ मेरी स्थिति को हल किया, लेकिन मास्टर के आधार पर साइड शाखाएं नहीं थीं।

यहाँ मेरी मौजूदा सेटअप है:

A--B--C--D master 
      \ 
      E--F--G--H BUG_37 

BUG_37 एक शाखा है कि प्रणाली में एक सुविधा का अनुरोध के लिए एक वैकल्पिक ट्रैक किए गए बग करने के लिए एक ठीक विकसित कर रहा है है, और अंततः मास्टर लाइन में विलय हो जाएगा, लेकिन है समय के लिए अलग है।

A--B--C--D--I--J--K master 
      \ 
      E--F--G--H BUG_37 

मैं तो master पर BUG_37 शाखा रिबेस, सुनिश्चित करने के लिए है कि यह सबसे वर्तमान परिवर्तन करने के लिए एक वृद्धि के रूप में काम कर रहा है: इस राज्य में भंडार के साथ, एक के बाद एक मशीन, मैं master शाखा में कुछ परिवर्तन किए:

A--B--C--D--I--J--K master 
        \ 
        E1--F1--G1--H1 BUG_37 

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

मैं मूल स्थिति और तीसरे राज्य में रिमोट रिपोजिटरी में स्थानीय भंडार कैसे ले सकता हूं, और स्थानीय भंडार को रिमोट रिपोजिटरी से बिल्कुल मिलान करने के लिए अद्यतन किया जा सकता है (ईएच को बदलना और BUG_37 के सिर को नए में ले जाना स्थान)?

Answer 1

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

master को BUG_37 में मर्ज करना बहुत आसान होगा; फिर मर्ज प्रतिबद्ध (जहां आपने संघर्ष तय किए हैं) को अन्य मशीनों पर धक्का दिया जा सकता है, और शाखाओं को हटाने की आवश्यकता नहीं होगी।

Answer 2

शाखा हटाएं, फिर दोनों शाखाओं को रिमोट रिपोजिटरी से खींचें।

git branch -D BUG_37 
git pull origin master 
git pull origin BUG_37:BUG_37 

आप यकीन है कि यह काम करता है होने से पहले अपने स्थानीय BUG_37 शाखा हटाना नहीं चाहते हैं, तो एक और स्थानीय शाखा में दूरदराज के शाखा खींच:

git pull origin BUG_37:NEW_BUG_37 

Answer 3

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

सरल उत्तर, बस गिट का उपयोग नहीं करते हैं, इसके बजाय rsync का उपयोग अपने रिपोस को सिंक्रनाइज़ करने के लिए करते हैं। यदि आप जानते हैं कि आप केवल एक ही काम कर रहे हैं, तो यह समझ में आता है।

ठीक है, मैं उस समाधान का बड़ा प्रशंसक नहीं हूं। तो, यह थोड़ा "क्लीनर" हो सकता है।लैपटॉप, डेस्कटॉप के रेपो से रिबेस शाखाओं खींच पर:

git co topic 
git fetch origin/topic 
git reset --hard origin/topic 

यह बाहर फेंक होगा किसी भी डेस्कटॉप रेपो पर नहीं करता है, तो सुनिश्चित करें कि आप वास्तव में ऐसा करना चाहते हैं हैं।

इसके अलावा, आप शायद git pull लैपटॉप की master शाखा कर सकते हैं, क्योंकि यह हमेशा तेजी से आगे होना चाहिए, क्योंकि आपको इसे पुन: पेश करने की आवश्यकता नहीं होगी। मुझे लगता है कि विषय शाखाओं को फिर से लिखना समझ में आता है, अन्यथा इसे अंत में मास्टर में वापस लाने की कोशिश करना एक दर्द है।

Answer 4

मैंने अभी इसका प्रयोग किया है और git pull --rebase का उपयोग कर एक पुनर्निर्मित शाखा से खींचते समय काम करता है। --rebase ध्वज के बिना, काम डुप्लीकेट किया जाएगा, लेकिन --rebase के साथ कामों को डुप्लिकेट नहीं किया जा रहा है।