कई समांतर रिलीज-शाखाओं के साथ गिट-फ्लो और मास्टर

Question

हम गिट-फ्लो द्वारा लागू successful Git branching model को अपनाने की कोशिश कर रहे हैं। अब, हम कम से कम दो रिलीज-शाखाओं पर काम कर रहे हैं, एक नवीनतम स्थिर रिलीज के लिए और अगले ("पूर्वावलोकन") रिलीज के लिए एक। मुझे समझ में नहीं आता है कि क्यों सभी रिलीज मास्टर पर "रैखिक" लगते हैं और वहां टैग किए जाते हैं। क्यों रिलीज शाखाओं में रिलीज टैग नहीं? मास्टर क्यों? या क्यों शाखा विकसित करें और इसके लिए मास्टर का उपयोग न करें?

Answer 1

Git प्रवाह मॉडल में: वहाँ एक नया सरकारी (और सरलीकृत) GitHub फ्लो ™ के लिए GitHub गाइड है , आपका "नवीनतम रिलीज़" संस्करण वास्तव में master पर नक्शा करता है, जबकि आपका "पूर्वावलोकन रिलीज" मानचित्र गिट-फ्लो release शाखा में मानचित्र करता है। यह develop से फोर्क किया गया है और अंततः वास्तविक रिलीज होने पर master में विलय हो गया है। फिर यह आपकी "नवीनतम रिलीज" बन जाएगा और आप आमतौर पर गिट-फ्लो hotfix शाखाओं का उपयोग करके उस रिलीज के लिए केवल बग ठीक करेंगे। इस तरह, आपका master हमेशा आपके नवीनतम रिलीज़ किए गए संस्करण की सबसे स्थिर स्थिति का प्रतिनिधित्व करता है।

आप पुराने रिलीज के लिए कीड़े को ठीक या किसी अन्य वहाँ का विकास करना चाहते हैं, तो आप एक support शाखा उचित से master में प्रतिबद्ध (आप सभी संस्करणों कभी वहाँ बनाया होगा) कांटा होगा।support शाखाएं अभी भी प्रयोगात्मक हैं (according to the docs) और अच्छी तरह से प्रलेखित नहीं हैं। लेकिन जैसा कि आप कमांड लाइन मदद से देख सकते हैं:

usage: git flow support [list] [-v] 
     git flow support start [-F] <version> <base> 

इन शाखाओं बस शुरू कर रहे हैं और न ही masterdevelop को वापस मर्ज करने का इरादा नहीं। यह आमतौर पर ठीक है, क्योंकि "प्राचीन" रिलीज या ग्राहकों को "प्राचीन" रिलीज में लागू किए जाने वाले सुविधाओं के लिए फिक्सेस master में वापस नहीं जा सकते हैं या नहीं। यदि आप अभी भी सोचते हैं, तो आप अपनी मुख्य विकास रेखा (master और develop द्वारा प्रतिनिधित्व) पर एक फिक्स पोर्ट करना चाहते हैं, बस hotfix शुरू करें, चेरी-अपने परिवर्तन चुनें और hotfix समाप्त करें।

Answer 2

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

तस्वीर सुंदर है, हालांकि। मास्टर में सबकुछ वापस विलय करना पूरे ग्राफ में संस्करण टैग को छीनने के बजाय अस्थायी क्रम में रिलीज़ का स्पष्ट संकेत देता है।

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

1. कहें कि हमने संस्करण 1.0.1 जारी किया है और बाद में सुविधाओं को जोड़ा है और 1.1.0 जारी किया है।
2. हम 1.0.1 में एक बग खोजते हैं और इसे दोनों संस्करण
3. में ठीक करना चाहते हैं, हमें मास्टर में 1.1.0 के बाद 1.0.2 जोड़ना है और फिर सीधे 1.1 (1.1) को पहले (या पहले) भी जोड़ना होगा।

अपने प्रश्न का उत्तर देने के लिए: मुझे लगता है कि यह नियमों का एक सेट है जो कुछ मामलों में एक साधारण मानसिक मॉडल बनाता है। सभी नियम पूरी तरह तकनीकी दृष्टि से समझ में नहीं आते हैं, लेकिन इससे उन्हें बुरा नहीं लगता है। मानसिक मॉडल 'इंसानों के लिए अच्छा हो।

Answer 3

मुझे व्यक्तिगत रूप से लगता है कि उल्लिखित गिट-फ्लो अतिसंवेदनशील है।

यदि आप गिटहब का उपयोग कर रहे हैं तो GitHub flow (स्कॉट चेकॉन द्वारा वर्णित) का प्रयास करें।

यह विशेष रूप से एकाधिक सुविधाओं, कोड-समीक्षा पर सहयोग के लिए उपयोगी है और आप इसे Commit Status API का उपयोग करके अपने निरंतर एकीकरण समाधान के साथ जोड़ सकते हैं।

अद्यतन: वहाँ है एक नया official website of The GitHub Flow™

अद्यतन 2: https://guides.github.com/introduction/flow/

Answer 4

मास्टर शाखा हमेशा आपके उत्पादन कोड आधार का प्रतिनिधित्व करनी चाहिए, इसलिए आप हमेशा उत्पादन रिलीज के बाद कोड को मास्टर में वापस मर्ज कर देते हैं।

टैगिंग का उपयोग सटीक कोड को "याद रखना" करने के लिए किया जाता है जो उत्पादन रिलीज में चला जाता है ताकि आप बाद में वापस जा सकें और कुछ गलत होने पर कोड का विश्लेषण कर सकें।

सैद्धांतिक रूप से इससे कोई फर्क नहीं पड़ता कि अगर आप रिलीज शाखा पर या मास्टर शाखा में वापस लौटने के बाद मास्टर कोड पर अपना कोड टैग करते हैं तो इससे कोई फर्क नहीं पड़ता। मैं व्यक्तिगत रूप से रिलीज शाखा पर कोड टैग करना पसंद करता हूं क्योंकि यह वास्तव में कोड है जो निर्माण/रिलीज में चला गया है (माना जाता है कि विलय के साथ कुछ गलत हो सकता है)।

विकास शाखा अवधारणा के साथ मुद्दा यह है कि यह एकल धागा है। इस धागे में ब्रेंडन ने एक रणनीति का उल्लेख किया जिसका उपयोग विकास शाखा अवधारणा को शामिल करने में किया जा सकता था।

Answer 5

मेरे मामले में, मेरे पास एक ही सॉफ्टवेयर का दो संस्करण है जो मूल बातें समान हैं लेकिन प्रत्येक संस्करण में कुछ अलग-अलग विशेषताएं हैं।

तो मैं दो worktree बनाता हूं जिसका अर्थ है, मास्टर के बगल में दो प्रासंगिक लंबी दौड़ वाली शाखाएं बनाएं।

$git worktree add -b version-silver ..\version-silver master 
$git worktree add -b version-gold ..\version-gold master 

तो मेरे पास है:

$git branch 
master # base stuff here 
version-silver # some normal features 
version-gold # some better features 

वहाँ एक भंडार है, लेकिन मैं इसके बाद के संस्करण प्रत्येक शाखा के लिए एक दूसरे के बगल में 3 अलग फ़ोल्डर है। और मास्टर में आम परिवर्तन करें। फिर इसे अन्य संस्करणों के साथ विलय करें।

cd master 
vim basic.cpp 
git add . 
git commit -m "my common edit on basic.cpp" 
cd ..\version-silver 
vim silver.cpp 
git add . 
git commit -m "my specific edit on silver.cpp" 
git merge master # here i get the basic.cpp latest changes for silver project 
cd ..\version-gold 
git merge master # here i get the basic.cpp latest changes for gold project 

प्रत्येक संस्करण के विशिष्ट परिवर्तन के रूप में अच्छी तरह से इसी फ़ोल्डर में जाना होगा, और प्रत्येक परियोजना पर काम करता है अलग कर रहे हैं और आईडीई उलझन में नहीं होगा।

उम्मीद है कि मदद करता है।