git - एक बुनियादी गिट वर्कफ़्लो को समझने/निर्धारित करने की कोशिश करना



github merge (1)

आपका सारांश सटीक है: आप इस धोखाधड़ी में सचित्र पा सकते हैं।

इस बात से अवगत रहें कि अन्य लोगों के साथ अपनी सुविधा का परीक्षण करने के लिए, आपको उन्हें विकसित करने के लिए मर्ज करना होगा ( git flow feature finish MYFEATURE )।
एक और वर्कफ़्लो ( Git वर्कफ़्लो ) है जो एक बेहतर फीचर प्रमोशन (विकसित करने, फिर रिलीज़ करने) की अनुमति देता है

अंतर यह है:

  • गिट प्रवाह के साथ, कई feature शाखाओं को मृग में विलय कर दिया जाता है (जहां उन्हें पता चलता है कि क्या वे एक साथ काम कर सकते हैं या नहीं), तो फिर release (जिस बिंदु पर हटाने की विशेषताएं जटिल हो जाती हैं) से उत्पन्न होती है, वापस devel (और master ) में विलय होने से पहले।
  • gitworkflow के साथ :
    • feature शाखाओं को एक " public " "अल्फ़ा" शाखा में मिला दिया जाता है, जो प्रत्येक रिलीज़ के बाद रीसेट हो जाती है (मतलब, नई रिलीज़ के शीर्ष पर हटा दी गई / फिर से बनाई गई)
    • तब उन्हीं feature शाखाओं के एक सबसेट को एकीकरण / स्वीकृति परीक्षण के लिए " next " ("बीटा") शाखा में विलय कर दिया जाता है। उस " next " ("बीटा") शाखा को प्रत्येक नए रिलीज के बाद master शीर्ष पर फिर से बनाया गया है।
    • तब अगली शाखाओं को तैयार करने के लिए, feature शाखाओं के एक उप-उपसमुच्चय का विलय कर दिया जाता है।

" public " और " next " (उर्फ ' devel ') शाखाओं को कभी भी master विलय नहीं किया जाता है। वे "क्षणिक" या "अल्पकालिक" हैं, हमेशा हटाए गए / फिर से बनाए गए।
केवल feature शाखाओं को जीवनचक्र शाखाओं ( public , next , master ) में विलय कर दिया जाता है। इसका मतलब है कि किसी भी समय आप विकास जीवनचक्र के एक चरण और अगले के बीच एक feature को छोड़ने का विकल्प चुन सकते हैं।

मैं अपने स्वयं के गिट वर्कफ़्लो का मसौदा तैयार करने के लिए इस लोकप्रिय दस्तावेज़ को बार-बार पढ़ रहा हूं।

मुझे लगता है कि मुझे यह मिल गया है, लेकिन मैं अभी भी थोड़ा खो गया हूं। यहां मेरी वर्तमान समझ है ...



हमारी दो शाखाएँ हैं जो हमेशा सक्रिय रहेंगी।

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


हमारे पास कई विषय शाखाएं हैं जिन्हें विकास शाखा (मुझे लगता है) से विभाजित किया जाएगा। विषय तय होने के बाद, बग को तय किए गए उदाहरण के रूप में, हम उस शाखा को विकास शाखा में वापस मिला देते हैं। कुछ उदाहरण:

  • विषय शाखा 1: फीचर-अजाक्सिफाई-शॉपिंग-कार्ट
  • विषय शाखा 2: बगफिक्स-नावबार-फ़ॉन्ट-ओवरलैपिंग


रिलीज तैयार करें

  • हमारे पास एक समय में 1 रिलीज शाखा है जिसे सुविधा शाखा से शाखा दी जाएगी।
  • अब हम सभी विशेषताओं, बग फिक्स आदि को खींचते हैं / मर्ज करते हैं जिसे हम अगली रिलीज़ में धकेलना चाहते हैं।
  • हम कुछ सुविधाओं को छोड़ सकते हैं जो हम उस पर काम कर रहे हैं जो अगली रिलीज में होगी (मुझे लगता है)।


रिलीज हो रही है

  • एक बार रिलीज से संतुष्ट होने के बाद, हम उस रिलीज ब्रांच को मास्टर ब्रांच में मर्ज कर सकते हैं, और कमिट को 'v1.2.0' की तरह नाम दे सकते हैं।
  • हम 'v1.2.0' के साथ टैग करना चाहते हैं ताकि हम आसानी से समय पर वापस जा सकें और रिलीज़ देख सकें।


साइड नोट्स मैंने सीखा है

मास्टर ब्रांच हमेशा अच्छी और साफ होती है, और इसमें केवल कमिट्स होते हैं जो रिलीज़ होते हैं (मुझे लगता है कि क्यों हमारे पास एक अलग रिलीज़ ब्रांच है, सही?)।

कृपया मुझे बताएं कि मैंने कहां गड़बड़ की है या कुछ गलत व्याख्या की है आदि। धन्यवाद!








version-control