इन गिट को गलत शाखा में डुप्लिकेट कैसे किया जाता है?

Question

मैं एक सहकर्मी को यह पता लगाने की कोशिश कर रहा हूं कि हाल ही में विलय में "खाली प्रतिबद्धता" चेतावनियों का एक समूह क्या था। मैं gitk खोल दिया, और कुछ इस तरह देखा:

_o (Z) Merge branch 'new-branch'        (yesterday) 
o | (Y) Fix bad merge           (person 1) 
o_| (X) Merge branch 'master' into new-branch     (recent) 
o | (W) Last legitimate commit that belongs on new-branch  (person 1) 
| |  ... work on master ... 
o | (F) Legitimate commit that actually belongs on new-branch (person 2) 
| |  ... work on master ... 
o | (E) Legitimate commit that should have been on master  (person 2) 
o | (D') Even more work etc...        (committed by person 2) 
o | (C') More work in master         (committed by person 2) 
o | (A') Normal work in master        (committed by person 2) 
| o (D) Even more work etc...         (authored by random person) 
| o (C) More work in master         (authored by random person) 
o | (B) Starting to work on new-branch      (person 1) 
|_o (A) Normal work in master         (authored by random person) 
o Common Ancestor            (weeks ago) 

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

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

धन्यवाद!

Answer 1

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

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

1. अपने मौजूदा भंडार में, "मास्टर" शाखा से एक नया "सुविधा" शाखा बनाएँ: git checkout -b feature
2. एक नई फ़ाइल "फ़ाइल-feature.txt" जोड़ें और "सुविधा" शाखा पर यह वादा : git add . ; git commit -m "added new file on master branch"
3. "मास्टर" शाखा में स्विच करें और एक अलग नई फ़ाइल वहाँ भी जोड़ सकते हैं और प्रतिबद्ध है कि: git checkout master ; git add . ; git commit -m "added new file on master branch"
4. पुश सुविधा शाखा दूरस्थ भंडार पर: git checkout feature ; git push --set-upstream origin feature
5. अब, "मास्टर" शाखा पर "फीचर" शाखा का पुनर्जन्म करें: git rebase master
6. यदि आप अब इस "फीचर" शाखा को दूरस्थ भंडार में धक्का देने का प्रयास करते हैं, तो आपको एक त्रुटि मिलेगी जिसे आपको "git pull" करने की आवश्यकता है प्रथम। यह वह बिंदु है जहां आपको वास्तव में "डुप्लिकेट" मिल जाता है, विलय के कारण (git pullgit fetch ; git merge के लिए एक शॉर्टेंड है), यह भी याद रखें कि सामग्री की सामग्री समान है, लेकिन शाखा के पुनर्भुगतान के कारण, आईडी ' अब अलग हैं और इस प्रकार, उन्हें एक अलग चीज़ के रूप में माना जा रहा है, इसलिए: git pull
7. "git gui" (मुख्य मेन्यू पर नेविगेट करें - रिपोजिटरी - फीचर के इतिहास को विज़ुअलाइज़ करें) के साथ, अब अपनी जीआईआई में अपनी शाखा का निरीक्षण करें और आप कुछ इस तरह देखें:
8. या बस git log का उपयोग कमांड लाइन में सीधे यह देखने के लिए: