2011-03-23 12 views
23

मैं गिट और गिथब का उपयोग कर रहा हूं, और मैंने अभी अपने आईओएस ऐप के 1.0 संस्करण को समाप्त कर दिया है। यहां से, मैं सोच रहा हूं कि कैसे गिट मेरी सेवा कर सकता है।गिट: मेरे ऐप के प्रत्येक संस्करण को प्रबंधित करें?

मैं वास्तव में यहां एक सर्वोत्तम अभ्यास की तलाश में हूं, और अन्य प्रमुख संस्करणों के प्रबंधन के लिए क्या सलाह देते हैं।

क्या मुझे प्रत्येक नए संस्करण के लिए एक नई शाखा बनाना चाहिए, जैसे 1.1, 1.5, 2.0, आदि? या क्या मुझे मास्टर शाखा में धक्का देना चाहिए? यदि हां, तो मैं यह कैसे करूँ?

उत्तर

26

मैं tags (tag tutorial)

का उपयोग कर अपने गुरु शाखा से के बाद से आप कर चुके हैं v1.0 एक टैग v1.0 बुलाया जोड़ने की सिफारिश करेंगे।

git tag -a -m "Tagging release 1.0" v1.0 

इस तरह आप हमेशा बुला git checkout [tag_name]

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

git checkout -b [feature-branch] 
कि नाम की एक नई शाखा जो कुछ [feature-branch] में है और इसे बाहर की जाँच करता है बनाता है

। यह सुनिश्चित करना सुनिश्चित करें कि आप इस सुविधा पर काम करना शुरू करना चाहते हैं (आमतौर पर master से)।

एक बार स्थिर होने पर उन्हें master में सुरक्षित रूप से विलय किया जा सकता है। master रन से:

git merge [feature-branch] 

इस तरह अपने master शाखा हमेशा कार्यशील राज्य में रहता है और केवल पूर्ण किए गए आइटम एक बार तैयार जोड़े जाते हैं। यह आपको परीक्षण के लिए हर समय (आदर्श रूप से वैसे भी) ऐप की एक कार्य प्रति रखने की अनुमति देगा, आदि

आप एप्लिकेशन के प्रत्येक संस्करण के लिए शाखाओं का उपयोग कर सकते हैं हालांकि टैग का उपयोग करके इसे बनाता है ताकि आप विलय नहीं कर सकें दुर्घटना से एक और शाखा संस्करण।

+2

सहमत हुए। अपने 1.0 बिल्ड और डीएसआईएम फाइलों में जांचें और एक टैग जोड़ें। यदि भविष्य में आप संस्करण 2.0 पर काम कर रहे हैं और पता चलता है कि आपको 1.1 के रूप में कुछ बदलाव जारी करने की आवश्यकता है तो आप हमेशा उस टैग से एक बैंच बना सकते हैं।प्रति रिलीज शाखा की कोई आवश्यकता नहीं है, लेकिन जब भी आप विज्ञापन बनाते हैं तो आप अपनी मुख्य विकास शाखा को एक ही रिलीज शाखा में विलय करना चाहेंगे ताकि आप प्रगति पर अस्थिर कार्य बनाम परीक्षण के लिए जारी किए गए कोड का स्पष्ट इतिहास प्राप्त कर सकें। – Jonah

+0

ठीक है, तो एक बार जब मैं 1.0 टैग जोड़ता हूं, तो मैं 1.1 पर कैसे काम करना शुरू कर सकता हूं? क्या मैं एक और टैग सेट करूं? इस अवधारणा के बारे में उलझन में। –

+1

जोना की टिप्पणी पर निर्माण करने के लिए, आप केवल एक संस्करण के लिए एक शाखा चाहते हैं यदि आप इसे अलग से बनाए रखते हैं। उदाहरण के लिए, यदि मास्टर संस्करण 3.0 की ओर काम कर रहा है लेकिन आपको संस्करण 2.0 में कुछ बग मिलती हैं, तो आप 2.0 टैग से शुरू होने वाली रखरखाव शाखा बना सकते हैं, अंततः उस पर संस्करण 2.1 संस्करण टैग कर सकते हैं, और संभावित रूप से उस शाखा को अपनी मास्टर शाखा में विलय करने के लिए आने वाले संस्करण 3 में बगफिक्सेस भी। – Cascabel

1

यह इस बात पर निर्भर करता है कि क्या आप पुराने संस्करणों को केवल बग फिक्स के साथ बनाए रखना चाहते हैं। यदि आप 2.0 में नई सुविधाओं को जोड़ने के दौरान 1.0 पर बग फिक्स जोड़ना चाहते हैं, तो आप 2.0 शाखा बनाते हैं, सभी बग फिक्स को दोनों शाखाओं में और 2.0 में सुविधाओं को मर्ज करते हैं। लेकिन प्रत्येक शाखा के भीतर प्रत्येक रिलीज के लिए आपको केवल एक टैग चाहिए। बस से शाखा को याद रखना सबसे पुरानी शाखा है जिसे आप वापस विलय करना चाहते हैं।

6

व्यक्तिगत रूप से, बड़ी परियोजनाओं के लिए मैं अपनाया है इस लेख में दर्शाये तरीकों में से सबसे:

http://nvie.com/posts/a-successful-git-branching-model/

यह मेरे लिए वास्तव में अच्छी तरह बाहर काम किया है, और अब भी पुस्तकालयों और उपकरण मदद करने के लिए कर रहे हैं आप पद्धति के साथ पालन करते हैं: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

1

आप नए GitHub releases तंत्र का भी उपयोग कर सकते हैं। यह गिटहब के साथ सॉफ्टवेयर संस्करणों का प्रबंधन करने का एक तरीका है।

संबंधित मुद्दे