अपडेट 2019:
इन दिनों, यह सवाल Git का उपयोग करते हुए एक संदर्भ में देखा जाएगा, और उस वितरित विकास वर्कफ़्लो का उपयोग करने के 10 साल (मुख्य रूप से GitHub के माध्यम से सहयोग करना ) सामान्य सर्वोत्तम प्रथाओं को दर्शाता है:
masterक्या शाखा किसी भी समय उत्पादन में तैनात होने के लिए तैयार है: अगली रिलीज, जिसमें सुविधा शाखाओं का एक चयनित सेट शामिल है master।dev(या एकीकरण शाखा, या ' next') वह जगह है जहाँ अगली रिलीज़ के लिए चुनी गई सुविधा शाखा का एक साथ परीक्षण किया जाता हैmaintenance(या hot-fix) शाखा वर्तमान रिलीज विकास / बग फिक्स के लिए एक है, संभव विलय के साथ वापस devयाmaster
कार्यप्रवाह इस तरह का (जहां विलय नहीं devकरने के लिए masterहै, लेकिन जहां के लिए एक ही सुविधा शाखा विलय devचयनित है, तो, करने के लिए masterGit में कार्यान्वित किया जाता है, ताकि आसानी से अगली फिल्म के लिए तैयार नहीं शाखाओं सुविधा ड्रॉप करने में सक्षम होना) रेपो खुद, गिटवर्कफ्लो (एक शब्द, यहां सचित्र ) के साथ।
पर अधिक देखें rocketraman/gitworkflow। इस लेख को ट्रंक-आधारित-विकास करने का इतिहास एडम डाइमिट्रुक द्वारा इस लेख की टिप्पणियों और चर्चाओं में नोट किया गया है ।
(स्रोत: गिटवर्कफ्लो: एक टास्क-ओरिएंटेड प्राइमर )
ध्यान दें: उस वितरित वर्कफ़्लो में, जब भी आप चाहें, तो आप व्यक्तिगत शाखा में जा सकते हैं और कुछ WIP (वर्क इन प्रोग्रेस) को बिना किसी समस्या के धकेल सकते हैं: आप उन्हें फ़ीचर ब्रांच का हिस्सा बनाने से पहले अपने कमिट को पुनर्गठित (git rebase) कर पाएंगे।
मूल उत्तर (अक्टूबर 2008, 10+ साल पहले)
यह सब आपकी रिहाई के प्रबंधन की अनुक्रमिक प्रकृति पर निर्भर करता है
पहले, क्या वास्तव में अगली रिलीज के लिए आपके ट्रंक में सब कुछ है ? आपको पता चल सकता है कि वर्तमान में विकसित कार्यों में से कुछ हैं:
- बहुत जटिल और अभी भी परिष्कृत होने की आवश्यकता है
- समय में तैयार नहीं
- दिलचस्प है, लेकिन इस अगली रिलीज के लिए नहीं
इस मामले में, ट्रंक में किसी भी वर्तमान विकास प्रयास शामिल होने चाहिए, लेकिन अगली रिलीज से पहले परिभाषित एक रिलीज शाखा समेकन शाखा के रूप में काम कर सकती है है जिसमें केवल उपयुक्त कोड (अगले रिलीज के लिए मान्य) को विलय कर दिया जाता है, फिर होमोलॉगेशन चरण के दौरान तय किया जाता है, और अंत में जमे हुए के रूप में यह उत्पादन में चला जाता है।
जब यह उत्पादन कोड की बात आती है, तो आपको यह भी ध्यान में रखते हुए अपनी पैच शाखाओं को प्रबंधित करने की आवश्यकता है:
- पैच का पहला सेट वास्तव में उत्पादन शुरू होने से पहले शुरू हो सकता है (जिसका अर्थ है कि आप जानते हैं कि आप कुछ बग्स के साथ उत्पादन में जाएंगे, जो आप समय में ठीक नहीं कर सकते हैं, लेकिन आप एक अलग शाखा में उन बग्स के लिए काम शुरू कर सकते हैं)
- अन्य पैच शाखाओं में एक अच्छी तरह से परिभाषित उत्पादन लेबल से शुरू होने वाली लक्जरी होगी
जब यह देव शाखा में आता है, तो आपके पास एक ट्रंक हो सकता है, जब तक कि आपके पास अन्य विकास के प्रयास नहीं होते हैं जैसे आपको समानांतर में बनाने की आवश्यकता होती है :
- बड़े पैमाने पर refactoring
- एक नई तकनीकी लाइब्रेरी का परीक्षण जो आपके द्वारा अन्य कक्षाओं में चीजों को कॉल करने के तरीके को बदल सकता है
- एक नए रिलीज चक्र की शुरुआत जहां महत्वपूर्ण वास्तु परिवर्तन को शामिल करने की आवश्यकता है।
अब, यदि आपका विकास-विमोचन चक्र बहुत अनुक्रमिक है, तो आप अन्य उत्तर सुझा सकते हैं: एक ट्रंक और कई रिलीज़ शाखाएँ। यह छोटी परियोजनाओं के लिए काम करता है, जहां सभी विकास अगली रिलीज में जाना सुनिश्चित करते हैं, और बस जमे हुए हो सकते हैं और रिलीज शाखा के लिए शुरुआती बिंदु के रूप में काम कर सकते हैं, जहां पैच हो सकते हैं। यह नाममात्र की प्रक्रिया है, लेकिन जैसे ही आपके पास एक अधिक जटिल परियोजना है ... यह अब पर्याप्त नहीं है।
विले एम की टिप्पणी का जवाब देने के लिए:
- ध्यान रखें कि देव शाखा का अर्थ 'प्रति डेवलपर एक शाखा' नहीं है (जो 'मर्ज पागलपन' को ट्रिगर करेगा, इसमें प्रत्येक डेवलपर को अपने काम को देखने / प्राप्त करने के लिए दूसरे के काम को मर्ज करना होगा), लेकिन प्रति विकास के लिए एक देव शाखा प्रयास है।
- जब उन प्रयासों को वापस ट्रंक (या किसी अन्य "मुख्य" या रिलीज शाखा जिसे आप परिभाषित करते हैं) में विलय करने की आवश्यकता है, तो यह डेवलपर का काम है, न कि - मैं दोहराता हूं, नहीं - एससी प्रबंधक (जो नहीं जानता कि कैसे हल करना है किसी भी परस्पर विरोधी विलय)। परियोजना का नेता मर्ज की देखरेख कर सकता है, जिसका अर्थ है कि यह समय पर शुरू / खत्म हो।
- जो भी आप वास्तव में मर्ज करने के लिए चुनते हैं, वह सबसे महत्वपूर्ण है:
- इकाई परीक्षण और / या विधानसभा वातावरण है जिसमें आप मर्ज के परिणाम को तैनात / परीक्षण कर सकते हैं।
- एक टैग को परिभाषित किया है मर्ज की शुरुआत से पहलेकरने के लिए पिछले राज्य में वापस लाने में सक्षम होने के लिए कहा जाता है अगर मर्ज खुद को बहुत जटिल या हल करने के लिए लंबे समय तक साबित होता है।
