गिट फ्लो

Question

में रिलीज से फीचर्स को हटाकर मैं एक बड़े जावा कोड बेस (300k + कोड की लाइन) के साथ एक टीम पर काम करता हूं, जिसने हाल ही में गिट को स्रोत नियंत्रण (क्लीयरकेस से माइग्रेट किया) के रूप में अपनाया है। हम अपनी शाखा रणनीति के रूप में Git Flow का उपयोग कर रहे हैं। कुछ उपयोग मामले हैं जो हम काफी बार आते हैं जिनके साथ हम संघर्ष कर रहे हैं।

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

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

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

इन स्थितियों को संभालने के लिए सबसे अच्छी विधियां क्या हैं? इन दोनों परिदृश्यों में, शाखाओं को कई डेवलपर्स द्वारा प्रकाशित और खींचा गया है, इसलिए इतिहास के साथ गड़बड़ी कठिनाइयों को पैदा कर सकती है। मुझे पता है कि ये आदर्श से कम हैं, लेकिन दुर्भाग्यवश स्थितियां हमारे नियंत्रण से बाहर हैं।

Answer 1

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

आप इन दोनों संबंधों में गिट को चालित कर सकते हैं जो आपको ऐसा करने की ज़रूरत है। वहाँ मर्ज इतिहास बनाने के दो तरीके में परिवर्तन

git merge --strategy=ours 

और

git merge 
git revert -m 1 MERGE_SHA 

पूर्व बनाता है किसी मर्ज के लिए प्रतिबद्ध (और इतिहास विलय) रखने के बिना कर रहे हैं, लेकिन सभी परिवर्तनों कि सामान्य रूप से हो गया होता बाहर छोड़ देता है बाद में विलय हो गया। बाद में एक विलय प्रतिबद्धता (और इतिहास विलय) बनाता है और परिवर्तनों में विलीन हो जाता है, लेकिन फिर पहले इतिहास को संरक्षित करते समय तुरंत सभी परिवर्तनों को हटा देता है।

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

तो कल्पना करें कि आप एक शाखा trouble कि 6 प्रतिबद्ध (1-6) शामिल है, और आप गुरु में trouble मर्ज करने के लिए की जरूरत है, लेकिन आप परिवर्तनों में 4. git merge trouble तुम करोगी के बजाय प्रतिबद्ध शुरू की विलय करने के लिए नहीं करना चाहते हैं

git merge 3 # merges 1/2/3 
git merge -s ours 4 # creates merge history for 4, but does NOT merge any changes from 4 
git merge trouble # merges 5/6