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

--o--o--M--...--N---...--O-----o   <- upstream/master
   \        
    A------B------C----- ... --D   <- branch/master

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

--o--o--M--...--N---...--O-----o   <- upstream/master
   \        
    A---M--B----N-C------O--...--D <- master(upstream merged)

हालांकि, विलय के दौरान प्रतिबद्धताओं को अंतःस्थापित किया जाता है, अगर प्रतिबद्ध एन ने मेरी मास्टर शाखा तोड़ दी है, तो सी-डी काम करता है तोड़ा जाएगा। हालाँकि मैं एक नई प्रतिबद्धता के साथ शाखा को ठीक कर सकता था, फिर भी C-D भाग टूट जाएगा।

मैं टूटे हुए हिस्से से कैसे बचूँ? या इस तरह की स्थिति के लिए कोई सर्वोत्तम अभ्यास है?

git
0
wanwan 27 अक्टूबर 2021, 15:43
आप अपनी शाखाओं का विलय कैसे करते हैं? आमतौर पर आपको मर्ज कमिट मिलता है। और यदि आप चेकआउट सी फिर से करते हैं तो आपके पास एम के बाद अपस्ट्रीम से कोई बदलाव नहीं होता है। एक प्रतिबद्धता का पूरा बिंदु यह है कि वह जिस कोड की ओर इशारा करता है वह पूर्वव्यापी में नहीं बदलता है। यदि आपके पास एक ही प्रतिबद्ध हैश है तो यह विलय के बाद कुछ अलग नहीं कर सकता है।
 – 
maow
27 अक्टूबर 2021, 15:53

1 उत्तर

सबसे बढ़िया उत्तर

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

यदि आप इससे शुरू करते हैं:

--X-----M-----N-----O-----P   <- upstream
   \        
    A------B------C------D   <- mybranch

फिर अपस्ट्रीम का माइब्रांच में सीधा-आगे विलय एक नया "मर्ज कमिट" बनाएगा, जो:

  • दोनों शाखाओं ने अपने पिछले सामान्य पूर्वज (X के रूप में चिह्नित) के बाद से किए गए परिवर्तनों को लागू करता है
  • दो "पैरेंट" कमिट हैं, P और D, जो कि git रिकॉर्ड इतिहास है

तो परिणाम इस तरह दिखता है:

--X-----M-----N-----O-------P   <- upstream
   \                         \
    A------B------C------D----E   <- mybranch

गिट के दृष्टिकोण से, दिखाए गए सभी कमिट ई के "पूर्वज" हैं, भले ही वे किस शाखा में थे, लेकिन सी और एन के बीच कोई सीधा संबंध नहीं है।

कोड को मर्ज करने का एक तरीका है है जो पुराने परिवर्तनों को फिर से बनाता है, जिसे "रीबेसिंग" कहा जाता है, जो आपके द्वारा किए गए प्रत्येक परिवर्तन को देखता है, और एक नया कमिट बनाता है, यह दिखाते हुए कि आपने उस बदलाव को किया है एक्स के बजाय पी के शीर्ष। यह "इंटरलीव" नहीं करता है, हालांकि, यह सभी नए लोगों को उस बिंदु के बाद क्रम में रखता है जब आप "रीबेस ऑन" करते हैं, ऐसा कुछ देते हैं:

--X-----M-----N-----O-----P   <- upstream
                           \
                            A1------B1------C1------D1   <- mybranch

(यह सोचने के लिए आकर्षक है कि ए से ई तक "स्थानांतरित" हो गया है, लेकिन गिट में काम करता है अपरिवर्तनीय है, और पूरे कोड की स्थिति का प्रतिनिधित्व करता है, परिवर्तन नहीं, इसलिए ए 1 से ई 1 को "रीबेस" द्वारा नया बनाया जाना है। मशीनरी।)

2
IMSoP 28 अक्टूबर 2021, 10:02
मैं देखता हूं, यह बहुत मायने रखता है; महान स्पष्टीकरण के लिए धन्यवाद! BTW, अगर P विलय योग्य थे लेकिन mybranch टूट गए, तो मैं कहूंगा कि mybranch E पर भी विलय के बाद टूट जाएगा। क्या इस स्थिति से बचने का कोई उपाय है? (बेशक, मैं E को F द्वारा ठीक कर सकता था, हालांकि।)
 – 
wanwan
28 अक्टूबर 2021, 05:09
Git आपके कोड अर्थ को नहीं जानता या परवाह नहीं करता है, यह सिर्फ टेक्स्ट फ़ाइलों की तुलना और विलय करना जानता है। यदि P में CSS की एक अतिरिक्त पंक्ति है जो आपके होमपेज को लाल कर देती है, तो E के पास एक लाल होमपेज होगा; गिट यह नहीं जान सकता कि यह एक गलती थी, और आप इसे हरा करना चाहते थे। इसी तरह, आप "पनडुब्बी" संघर्ष कह सकते हैं - कोड के विभिन्न हिस्सों में दो परिवर्तन जो गिट नहीं जानते हैं, संबंधित हैं, लेकिन उनके बीच एक बग का कारण बनता है। वही बात बिना किसी संस्करण नियंत्रण के हो सकती है, यदि दो लोगों ने कोड संपादित किया हो; कम से कम गिट आपको यह पता लगाने देता है कि यह कब हुआ था।
 – 
IMSoP
28 अक्टूबर 2021, 10:47
फिर से धन्यवाद। तो, इस तरह के "पनडुब्बी" संघर्षों के साथ टूटे हुए मर्ज कभी-कभी अपरिहार्य होते हैं और उन्हें लगातार कमिट में तय करना पड़ता है, है ना?
 – 
wanwan
28 अक्टूबर 2021, 13:01
सही। एकमात्र उपकरण जो आपकी मदद कर सकता है वह एक व्यापक स्वचालित परीक्षण सूट है, जो आपको उन्हें जल्द से जल्द पहचानने में मदद कर सकता है, लेकिन अंततः बग जीवन का एक तथ्य है।
 – 
IMSoP
28 अक्टूबर 2021, 13:03