हमारे पास एक बड़ी रेल परियोजना है जो उत्पादन और स्टेजिंग सर्वर पर चलती है। स्टेजिंग या उत्पादन के लिए हर बार टैग बनाने के लिए यह एक अच्छा विचार है (यह स्वचालित रूप से कैपिस्ट्रानो के साथ होगा)। या "devlopment" और "staging" नाम की शाखाएं बनाने के लिए बेहतर है, (मास्टर में उत्पादन की स्थिति होगी)?टैग बनाम शाखाओं में गिट
आप विकास, स्टेजिंग और उत्पादन के लिए शाखाओं का उपयोग कर सकते हैं और साथ ही साथ उत्पादन संस्करणों की पहचान करने के लिए टैग का उपयोग कर सकते हैं। मुझे git flow उन शाखाओं को संभालने का तरीका पसंद है और आपको नई सुविधाओं को विकसित करने के लिए और अधिक शाखाओं का उपयोग करने में सक्षम बनाता है। एक डेवलपर के रूप में आपको मास्टर शाखा में कोड कभी भी नहीं करना पड़ेगा, और मास्टर में विलय भी दुर्लभ होता है।
गिट में टैग बहुत लंबे समय तक रहते हैं: जब आप रिमोट रिपोजिटरी से प्राप्त करते हैं तो वे स्वचालित रूप से प्रचार करते हैं, और यदि आप उन्हें साफ़ करना चाहते हैं तो आपको प्रत्येक प्रतिलिपि में मैन्युअल रूप से ऐसा करना होगा। इसलिए, मैं स्वचालित तैनाती को चिह्नित करने के लिए शाखाओं (और संभवतः उनके रिफ्लॉग) का उपयोग करना चाहता हूं, अन्यथा मुझे शायद बहुत सारे टैग में दफन किया जाएगा।
यदि आवश्यक हो तो त्वरित पुनर्प्राप्ति के प्रयोजनों के लिए हम अपने प्रत्येक तैनाती (स्वचालित रूप से हमारी तैनाती स्क्रिप्ट में) टैग करते हैं, लेकिन वे तैनाती इतिहास के रूप में भी काम में आते हैं। उदाहरण के लिए:
deployment_stag_20120804
deployment_stag_20120823
deployment_prod_20120715
deployment_prod_20120724
आपके पास अपनी स्क्रिप्ट की तैनाती की केवल पिछले एन संख्या के लिए टैग रखने अगर आप टैग की एक बड़ी राशि से बचना चाहते हैं कर सकते हैं।
एक शाखा अधिक समझ में आता है यदि तैनाती की आपकी विधि विलय करना है, उदाहरण के लिए, एक उत्पादन शाखा में, जिस पर एक गिट हुक प्रोड सर्वर पर खींच खींच सकता है।