क्या स्क्वैश पुल अनुरोधों को गिट के विलय के एल्गोरिथ्म को तोड़ देता है?

Question

मैं वर्तमान में एक कंपनी के लिए काम कर रहा हूँ जो GST कोड के प्रबंधन के लिए VSTS का उपयोग करती है। किसी शाखा को मर्ज करने का Microsoft का "अनुशंसित" तरीका "स्क्वैश मर्ज" करना है, जिसका अर्थ है कि उस शाखा के लिए आने वाले सभी परिवर्तनों को शामिल करते हुए एक नई प्रतिबद्ध में स्क्वैश हो जाता है।

मुसीबत यह है कि अगर मैं एक बैकलॉग आइटम के लिए एक शाखा में कुछ बदलाव करता हूं, तो तुरंत एक और बैकलॉग आइटम के लिए किसी अन्य शाखा में परिवर्तन करना शुरू करना चाहता हूं, और वे परिवर्तन पहली शाखा के परिवर्तन के सेट पर निर्भर करते हैं?

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

तो मेरा सवाल यह है कि क्या इसके आस-पास जाने का कोई तरीका है (केवल एक फीचर ब्रांच को दूसरे से बंद करने के अलावा, जो मेरे वर्कफ़्लो को सीमित करता है) या स्क्वैश मर्जिंग को सिर्फ गैट के मर्जिंग एल्गोरिथम को तोड़ता है?

Answer 1

गिट के साथ, करता है

• अपरिवर्तनीय हैं,
• और एक निर्देशित चक्रीय ग्राफ बनाते हैं।

स्क्वैशिंग कम्बाइंड नहीं करता है। इसके बजाय, यह कई अन्य कमिट्स से हुए बदलावों के साथ एक नई प्रतिबद्धता दर्ज करता है। रिबासिंग समान है, लेकिन कमिट नहीं जोड़ती है। एक मौजूदा प्रतिबद्ध के रूप में एक ही बदलाव के साथ एक नई प्रतिबद्ध रिकॉर्डिंग इतिहास पुनर्लेखन कहा जाता है । लेकिन जैसा कि मौजूदा कमिटमेंट अपरिवर्तनीय हैं, इसे "वैकल्पिक इतिहास लिखने" के रूप में समझा जाना चाहिए।

विलय एक सामान्य पूर्वजों से शुरू होने वाले दो प्रतिबद्ध इतिहास (शाखाओं) के परिवर्तनों को संयोजित करने का प्रयास करता है।

तो आइए अपने इतिहास को देखें:

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

A सामान्य पूर्वज है, 1-5 मूल सुविधा शाखा, F नई सुविधा शाखा, और S स्क्वैश प्रतिबद्ध जिसमें 1-5 के समान परिवर्तन होते हैं। जैसा कि आप देख सकते हैं, एफ और एस का सामान्य पूर्वज ए है। जहां तक ​​गिट का संबंध है, एस और 1-5 के बीच कोई संबंध नहीं है। तो एक तरफ एस के साथ मास्टर विलय और दूसरे पर 1-5 के साथ फीचर 2 संघर्ष करेगा। इन संघर्षों को हल करना मुश्किल नहीं है, लेकिन यह अनावश्यक, थकाऊ काम है।

इन बाधाओं के कारण, विलय / स्क्वैशिंग से निपटने के लिए दो दृष्टिकोण हैं:

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

                                   F  feature2 (old)
                                  /
                 1---2---3---4---5    feature1 (old)
                /
  -o---o---o---A---o---o---S          master
                            \
                             F'       feature2
  

• या आप इतिहास पुनर्लेखन का उपयोग नहीं करते हैं, जिस स्थिति में आपको अतिरिक्त मर्ज कमिट मिल सकता है:

                                   F  feature2
                                  /
                 1---2---3---4---5    feature1 (old)
                /                 \
  -o---o---o---A---o---o-----------M  master
  

  जब फीचर 2 और मास्टर को मिला दिया जाता है, तो आम पूर्वज 5 प्रतिबद्ध होंगे।

दोनों मामलों में आपके पास कुछ विलय का प्रयास होगा। यह प्रयास आपके द्वारा चुनी गई उपरोक्त दो रणनीतियों में से बहुत पर निर्भर नहीं करता है। लेकिन यह सुनिश्चित करें

• शाखाएँ अल्पकालिक हैं, यह सीमित करने के लिए कि वे मास्टर शाखा से कितनी दूर तक बहाव कर सकते हैं, और
• आप नियमित रूप से अपनी फीचर शाखा में मास्टर को मर्ज करते हैं, या शाखाओं को सिंक में रखने के लिए मास्टर पर फीचर शाखा को फिर से बनाते हैं।

एक टीम में काम करते समय, यह समन्वय करना सहायक होता है कि वर्तमान में कौन काम कर रहा है। यह विकास की सुविधाओं की संख्या को कम रखने में मदद करता है, और मर्ज संघर्षों की संख्या को कम कर सकता है।

Comments

आपके जवाब से यह नहीं लगता है कि क्या होता है यदि आप पहले feature1मास्टर में स्क्वैश-मर्ज करते हैं , तो feature2बाद में विलय करना चाहते हैं । उस स्थिति में, संघर्ष में पहला दृष्टिकोण परिणाम नहीं होगा क्योंकि गिट feature1स्क्वैश कमिट के शीर्ष पर कमिट्स को फिर से लागू करने की कोशिश करता है , जबकि दूसरा गिट को यह निर्धारित करने की अनुमति देता है कि उन कमियों को विलय करने की आवश्यकता नहीं है?

— Jez

@ जज जब आप पीआर स्क्वैश करते हैं तो ठीक यही होता है। मुझे हाल ही में एक OSS प्रोजेक्ट पर मैन्युअल रूप से एक PR को फिर से लिखना पड़ा ( git cloneरेपो द्वारा आईएनजी और मेरी बदली हुई फाइलों को कॉपी करके!) क्योंकि मैंने एक ब्रांच से ब्रांच किया और फिर मेंटेनर ने पहली ब्रांच को स्क्वैश किया। मेरी नौकरी पर वे स्क्वैश मर्ज भी करते हैं। इसका मतलब है कि मैं bउस फीचर पर काम नहीं कर सकता जो aफीचर aके विलय होने तक फीचर पर निर्भर करता है।

— थ्रू अवे अकाउंट

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

— Jez

@ जेजे मूल परिदृश्य में, हाँ, आपको फीचर 2 को मास्टर में विलय करते समय टकराव होगा क्योंकि 1-5 को मर्ज करने से एस में समान बदलावों के साथ संघर्ष होगा। समाधान 2 (समाधान 1) को रीबेस करने के लिए है या स्क्वैशिंग या रिबासिंग का उपयोग न करें सभी (समाधान 2)।

— आमोन

स्क्वैश मर्ज आपके लिए एक अच्छा फिट है या नहीं, यह इस बात पर निर्भर करता है कि आप संस्करण नियंत्रण इतिहास में क्या रिकॉर्ड करना चाहते हैं। यदि सुविधा शाखाओं में कई WIP हैं, तो स्क्वैशिंग मास्टर शाखा पर संपूर्ण सुविधा के साथ एक बड़ी प्रतिबद्ध लगाती है। यदि आप सुविधा शाखा के सभी मध्यस्थ कमानों को संरक्षित करना पसंद करते हैं, तो रिबासिंग या विलय का उपयोग करें।

— आमोन

Answer 2

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

इसीलिए यहाँ हमारा अलिखित नियम है, जब तक आपकी सुविधा शाखा पर निर्भर कोई और नहीं हो जाता है, तब तक स्क्वैश करना ठीक है, जो कि शायद इस समय 90% है। अन्यथा, एक सीधा मर्ज हर किसी को मुद्दों से बचने में मदद करता है।

Comments

मास्टर इतिहास में एक स्क्वैस्ड कमिटमेंट और एक फीचर ब्रांच दोनों को अलग स्क्वैश-ओनली ब्रांच बनाने का एक तरीका है। मान लीजिए कि आपकी एक feature-xyzशाखा है। आप feature-xyz-squashedशाखा के रूप में एक ही प्रतिबद्ध पर शुरू होने वाली शाखा बना सकते हैं feature-xyz, git cherry-pickवहां से feature-xyzआने feature-xyz-squashed, उन्हें स्क्वैश करने और विलय feature-xyz-squashedकरने के लिए कर सकते हैं master। आपको feature-xyzतब विलय नहीं करना चाहिए । कभी-कभी उपरोक्त समझ में आता है (जैसे कि आप पासवर्ड स्नैक के साथ कमिट को शामिल नहीं करना चाहते हैं), लेकिन यह वर्कअराउंड है, शायद ही सबसे अच्छा अभ्यास।

— 9000