गिट वेब डेवलपमेंट वर्कफ़्लो: तत्काल सुधारों और एकाधिक मील का पत्थर प्रकाशित करने के लिए जॉगलिंग

Question

मुझे कुछ मदद की ज़रूरत है कि वर्कफ़्लो एक विशिष्ट साइट डेवलपमेंट पर्यावरण के लिए हाल ही में गिट (एसवीएन से) में परिवर्तित कैसे होगा।

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

मेरा मुख्य सवाल कर रहे हैं:

• कैसे तत्काल सुधारों को संबोधित किया जाना चाहिए
• परिवर्तन का एक मील का पत्थर का प्रकाशन कैसे करना चाहिए जाना

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

प्रत्येक डेवलपर रेपो, हब रेपो, और मंच रेपो में सभी शाखाएं हैं: मोबाइल, रीडिज़ाइन, मास्टर। लाइव रेपो में एक शाखा है: मास्टर

त्वरित फ़िक्स: डेवलपर अपनी मास्टर शाखा में परिवर्तन करता है, हब पर जाता है। फिर लाइव पर, हब से परिवर्तन खींचता है (या पहले चरण यदि उन्हें पहले परीक्षण करने की आवश्यकता है)।

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

Answer 1

"विलय" भाग को छोड़कर वर्कफ़्लो ध्वनि लगता है।

मैं हमेशा किसी भी विद्रोह के साथ किसी विलय से पहले होता हूं: डेवलपर स्थानीय रूप से किसी भी संघर्ष को हल करने के लिए मास्टर शाखा के शीर्ष पर अपने काम को दोबारा शुरू करता है (जैसा कि मैंने पहले परिदृश्य को "rebase vs. merge" में वर्णित किया है)।
इससे बाद में विलय (प्रारंभिक पुनर्जन्म के बाद) तेजी से आगे बढ़ेगा।

(Jefromi टिप्पणी है कि एक रिबेस हमेशा संभव नहीं है में उल्लेख है।
यह सच है, जब भी कुछ काम पहले से ही धक्का दिया जा चुका है/कहीं और खींच लिया, रिबेसिंग एक ही काम के लिए खतरनाक है कि।)

टैग खींचने के लिए के रूप में या लाइव पर मास्टर, मैं केवल टैग के तैनात टैग, HEAD शाखा के बजाय होगा। मतलब मैं लाइव पर ए नंगे रेपो को धक्का दूंगा, जिसमें post-receive हुक सेट एक टैग के साथ गैर-नंगे रेपो (वास्तविक लाइव साइट) को अपडेट करने के लिए सेट किया जाएगा, अगर टैग master शाखा के HEAD पर है (जो git describe कर सकते हैं आसानी से जांचें)

Answer 2

मेरी राय में आपका वर्कफ़्लो 75% ठीक है। यहां बताया गया है कि मैं इसे कैसे करूं:

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

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

वास्तव में महत्वपूर्ण बात यह है कि आपके पास लाइव साइट के लिए एक अलग शाखा है। यह आपके डेवलपर्स को लाइव शाखा लाने और साइट पर त्वरित परिवर्तन करने में सक्षम बनाता है।

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