घर के विकास के लिए गिट उपयोग के लिए वर्कफ़्लो विवरण

Question

जिस कंपनी के लिए मैं काम करता हूं वह मासिक रिलीज करना चाहता है, और मैं उन्हें गिट पर स्विच करने के लिए मनाने की कोशिश कर रहा हूं। मेरा मानना ​​है कि इसे संभालने के लिए उचित गिट-तरीका प्रत्येक रिलीज (यानी मासिक) के लिए एकीकरण शाखा है और नए विकास और परिवर्तनों के लिए एकीकरण शाखाओं से फीचर शाखाएं हैं। पर्यावरण परस्पर निर्भरता से भरा हुआ है और कभी-कभी किसी अन्य सुविधा को अन्य बाहरी प्रणालियों से आवश्यक सुविधाओं में देरी की वजह से एक अलग महीने में स्थगित करना पड़ता है। परियोजनाओं में आम तौर पर समानांतर में 2-3 एकीकरण शाखाओं पर गतिविधि होगी और गतिविधि उन लोगों के समूह तक ही सीमित है जो काफी निकट संपर्क में हैं। (जिसका अर्थ है कि मुझे संदेह है कि हम तब तक पुन: उपयोग कर सकते हैं जब तक हम अंतिम एकीकरण शाखा में हों, जो कि आधे लोगों के लिए कम से कम आधा समय है)

इसमें शामिल लोगों की एक उचित राशि है, इसलिए मैं वास्तव में शाखा/विलय संरचना और व्यावहारिक गिट आदेशों के लॉजिकल स्पष्टीकरण दोनों को करने के लिए कुछ सरल दिशानिर्देशों की आवश्यकता है। क्या किसी को इस तरह के वर्णन के बारे में पता है जो इस तरह के वर्कफ़्लो के लिए उचित रूप से उपयुक्त है? एकीकरण शाखा, और शाखाओं विशेषताएं:

Answer 1

शाखा/मर्ज संरचना

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

कि अंतिम बिंदु (प्रकाशन) मर्ज पर एक बड़ा प्रभाव पड़ेगा आदेश, अर्थात्:

• मर्ज
• रिबेस।

जब भी कोई डेवलपर किसी भी एकीकरण शाखा पर अपने काम के विलय करने के लिए है (वह एक "केंद्रीय" रिपोजिटरी से खींच लिया), मैं सिफारिश करेंगे:

# switch back to previous release tag (from where feature branches for next release where done) 
$ git checkout previousReleaseTag 
# create one's own private 
$ git checkout -b myIntegrationBranch 
# merge or cherry-pick what we want to actually put in the next release 
$ git merge... from our feature branch 
# rebase that private integration branch on top of actual integration branch 
$ git rebase integrationBranch 

पिछले रिबेस अपने स्थानीय के इतिहास को फिर से लिखने होगा समेकन, लेकिन एक शाखा में आप वैसे भी प्रकाशित नहीं करेंगे (इसलिए कोई नुकसान नहीं हुआ)।
एक बार आपकी सभी नई सुविधाएं काम कर रही हैं, तो आप उस निजी शाखा को प्रासंगिक एकीकरण शाखा के वर्तमान HEAD में वापस कर सकते हैं।

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

सवालों में अन्य विवरण:

• git commit frequency
• git releases management (एक और मर्ज कार्यप्रवाह)
• JC Hamano articles (Jakub Narębski करने के लिए धन्यवाद)