Git-flow के बाद आपको पहले रिलीज़ के एक हॉटफ़िक्स को कैसे संभालना चाहिए?


101

यदि आप यहाँ और उपकरण के साथ प्रलेखित git-flow ब्रांचिंग मॉडल का पालन करने का प्रयास करते हैं , तो आपको इस स्थिति को कैसे संभालना चाहिए:

आपने 1.0 रिलीज़ और 2.0 रिलीज़ किया है। फिर आपको 1.0 के लिए एक हॉटफिक्स बनाने की आवश्यकता है। आप 1.0 टैग से एक हॉटफ़िक्स शाखा बनाते हैं और वहां फिक्स को लागू करते हैं। लेकिन फिर क्या?

आम तौर पर आप मास्टर में विलीन हो जाते हैं और वहां 1.1 रिलीज टैग लगाते हैं। लेकिन आप मास्टर पर 2.0 के बाद 1.1 को एक बिंदु पर विलय नहीं कर सकते।

मुझे लगता है कि आप रिलीज़ टैग को हॉटफिक्स शाखा पर रख सकते हैं, लेकिन यह मास्टर के पास एक स्थायी शाखा बनाएगा जिसमें रिलीज़ टैग होगा। क्या यह सही तरीका है?


कई समानांतर रिलीज़-शाखाओं के साथ Git-flow और मास्टर के संभावित डुप्लिकेट [हालांकि दूसरा प्रश्न नया है, इसके अधिक उपयोगी उत्तर हैं इसलिए मैंने इस प्रश्न को डुप्लिकेट के रूप में चिह्नित किया है]
danio

जवाबों:


74

ऐसा लगता है कि गिट फ्लो में एक "सपोर्ट" शाखा की अवधारणा है। यह पहले रिलीज़ के लिए एक हॉटफ़िक्स जोड़ने के लिए उपयोग किया जाता है।

इस धागे में अधिक जानकारी है , इन उदाहरणों के साथ:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... अपना सुधार करें, फिर:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

या git flowकमांड्स का उपयोग करना

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... फिर परिवर्तन करें:

git flow hotfix finish 6.0.1

इन समर्थन शाखाओं को बनाए रखें या कुछ अवधि के बाद उन्हें हटा दें
इवान हू

@EvanHu अच्छी तरह से, सुनिश्चित करें कि जब तक आपके पास उत्पादन में वह शाखा न हो, तब तक उन्हें रखें। उसके बाद यह ऐतिहासिक रिकॉर्ड की बात है। आप जानना चाह सकते हैं कि अगर वे कभी भी पुनरावृत्ति कर लें, तो कैसे तय की गई थी।
क्लॉस मेलबर्न

एक को हॉट फिक्स पर रिलीज करना चाहिए, है ना? हम वह कैसे कर सकते है?
रविंद्रनाथ अकीला

33

दिलचस्प सवाल! आपके द्वारा लिंक किए गए प्रवाह मास्टर उत्पादन को ट्रैक कर सकते हैं। यह तभी काम करता है जब उत्पादन संस्करण सख्ती से बढ़ रहे हों। यह आमतौर पर एक ऐसी वेबसाइट के लिए सही है, जिसमें केवल एक उत्पादन संस्करण है।

यदि आपको कई उत्पादन संस्करण बनाए रखने हैं, तो उत्पादन को ट्रैक करने के लिए एक शाखा पर्याप्त नहीं है। एक समाधान उत्पादन को ट्रैक करने के लिए मास्टर का उपयोग नहीं करना है। इसके बजाय, उपयोग शाखाओं की तरह release1, release2आदि

इस दृष्टिकोण में, आपको एक हॉटफ़िक्स शाखा की आवश्यकता भी नहीं हो सकती है। आप release1शाखा पर समस्या को ठीक कर सकते हैं । जब फिक्स पर्याप्त अच्छा हो, release1.1तो release1शाखा पर एक टैग बनाएं ।


आप रिलीज़ शाखाओं पर रिलीज़ टैग सेट करने के लिए git-flow को बदल सकते हैं। यह एक बहुत बड़ा बदलाव है। यह वर्तमान स्क्रिप्ट को तोड़ देगा। इसके अलावा, मास्टर में क्या होगा?
क्लेस मेलबर्न

3
git-flowआप एक से अधिक उत्पादन संस्करणों का समर्थन करने के लिए है, तो टूलींग उपयुक्त नहीं है। इस उत्तर में प्रस्तावित वर्कफ़्लो में, मास्टर का उपयोग बिल्कुल नहीं किया जाता है। आप विकास शाखा मास्टर का नाम दे सकते हैं, यह सिर्फ एक नाम है, सब के बाद।
अंदोमार


7

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

दुर्भाग्य से, आपके द्वारा उपयोग किए जा रहे किसी भी git-flow टूलींग को संभवतः संशोधित करने की आवश्यकता होगी, लेकिन उम्मीद है कि आप git-flow प्रक्रिया के साथ पर्याप्त रूप से परिचित हैं जो इस विशिष्ट मामले को सीधे git कमांड के साथ संभालते हैं।


यदि आप git flowप्रक्रिया को संशोधित करते हैं तो यह कुछ अलग होगा। यदि कुछ मॉडल को तय किया जाना चाहिए (न कि केवल विस्तारित) तो यह उतना ही सफल है जितना कि इसके लेखक कहते हैं। जिस विषय पर हम चर्चा कर रहे हैं, उसके लिए कृपया मेरे उत्तर की जाँच करें।
विक्टर यारमा

0

git config --add gitflow.multi-हॉटफिक्स सत्य यह आदेश मेरे लिए काम करता है!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.