छोटी टीम के लिए गिट विकास रणनीति

Question

हमारे पास एक छोटी डिजिटल टीम (3 डिजाइनर, 3 डेवलपर) हैं और हमारे सिस्टम में गिट को एकीकृत करने की तलाश में हैं।

फिलहाल, हमारी अधिकांश साइटों के लिए हमारे पास एक स्टेजिंग साइट (dev.example.com) और एक उत्पादन साइट (example.com) है। हमारे डेवलपर आमतौर पर स्थानीय संस्करण में कोड परिवर्तन करते हैं, उन परिवर्तनों को स्टेजिंग साइट पर ले जाते हैं और फिर, एक बार स्वीकृत होने पर, वे परिवर्तन लाइव स्थानांतरित होते हैं। दूसरी तरफ, हमारे डिजाइनर छोटे संपादन (जब डेवलपर्स बहुत व्यस्त होते हैं) सीधे स्टेजिंग साइट पर करते हैं और फिर एक बार अनुमोदित रहते हैं। इसके अलावा, कुछ मामलों में, हमारे पास एक स्टेजिंग साइट नहीं है और संपादन सीधे उत्पादन साइट पर धकेल दिए जाते हैं।

मुझे पता है कि विभिन्न वर्कफ़्लो आदर्श नहीं हैं लेकिन इस वर्तमान प्रणाली में गिट को एकीकृत करने और वर्कफ़्लो को काफी सरल (डिजाइनरों के लिए) के लिए सबसे अच्छा तरीका क्या होगा? क्या गिट को शामिल करने से पहले हमारे वर्तमान वर्कफ़्लो को पहले मानकीकृत किया जाना चाहिए (यानी स्टेजिंग साइट अनिवार्य है और डिजाइनरों को स्टेजिंग पर धक्का देने से पहले स्थानीय रूप से विकसित होना चाहिए) या गिट लचीला है जो काम करने के लिए पर्याप्त है?

मैं गिट के लिए बिल्कुल नया हूं लेकिन पढ़ा है कि एक धक्का केवल एक नंगे भंडार में किया जाना चाहिए। क्या यह आवश्यक है? यदि हां, तो क्या यह स्टेजिंग साइट हो सकता है? या यह अपनी खुद की इकाई होनी चाहिए (यानी एक इन-हाउस सर्वर पर उदाहरण.लोकल)?

एक अच्छा कार्यप्रवाह के रूप में ऐसी होगी:

1. उपयोगकर्ता को हासिल करेगा और स्थानीय भंडार में नंगे भंडार विलीन हो जाती है।
2. उपयोगकर्ता स्थानीय रूप से विकसित होता है और स्थानीय भंडार में परिवर्तन करता है।
3. उपयोगकर्ता example.local (या कुछ इसी तरह)
4. उपयोगकर्ता भंडार dev.example.com
5. मंचन जब अनुमोदित करने के लिए नंगे रिपोजिटरी से परिवर्तन खींचती है पर नंगे भंडार में परिवर्तन धक्का, उपयोगकर्ता उत्पादन भंडार करने के लिए नंगे रिपोजिटरी से परिवर्तन खींचती example.com

इस वर्कफ़्लो के साथ मेरा एकमात्र मुद्दा यह है कि नंगे भंडार अनावश्यक लगता है ... नहीं? और आखिरकार, मैं समझता हूं कि स्थानीय भंडार (उपयोगकर्ता बदलता है, काम करता है, आदि) पर लॉग इन किया जाएगा, लेकिन मैं अस्पष्ट हूं कि नंगे भंडार (धक्का के बाद) पर क्या लॉग किया जाएगा, स्टेजिंग (खींचने के बाद)) और उत्पादन (पुल के बाद); क्या उपरोक्त सभी चरणों को ट्रैक किया जा सकता है और आसानी से लॉग इन किया जा सकता है?

किसी भी और सभी सलाह/उत्तरों के लिए धन्यवाद!

Answer 1

यहाँ एक interestion Git कार्यप्रवाह है: http://nvie.com/posts/a-successful-git-branching-model/

अगर आपके डेवलपर्स और डिजाइनरों कमांड लाइन अंतरावस्था से परिचित नहीं हैं, एक जीयूआई Git आवरण का उपयोग करें, वहाँ कई हैं: gitx, gitbox, git tower, बस उन्हें करने के लिए गूगल अपनी साइटें प्राप्त करें। एक उपकरण या उपकरण ढूंढें जो आपकी टीम आरामदायक है।

सबसे अच्छा वर्कफ़्लो वह है जो आपकी टीम की आवश्यकताओं को पूरा करता है, और यह समय के साथ बदल सकता है।

Answer 2

क्या गिट लचीला काम करने के लिए पर्याप्त है?

बहुत कुछ।

जिस तरह से मैं इसे करने के लिए उपयोग करता था, डिजाइनरों को design शाखा या कुछ समान नाम पर काम करने दें और हमेशा धक्का देने के लिए एक ही कमांड रखें।

डेवलपर जब भी सर्वर अपडेट करता है तो डिज़ाइन शाखा से सामग्री विलीन करता है। वास्तव में, ऑटो परिनियोजन स्क्रिप्ट में विलय एक आदेश होगा।

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

कहा जा रहा है कि, डिजाइनरों को धीरे-धीरे और धीरे-धीरे गिट का उपयोग करने के लिए प्रोत्साहित करें। सबसे पहले उन्हें stash कमांड पर हुक करें। और खींचो। फिर, उन्हें विभिन्न शाखाएं बनाने के लिए कहें।

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

Answer 3

मुझे नंगे भंडार का उपयोग करने का कारण दिखाई नहीं देता है। मैंने एक साधारण डेवलपर प्रक्रिया के बारे में एक छोटी सी पोस्ट लिखी: A simple developer process with Git

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

अगर मैं ऐसा किया, यह मैं क्या कर सकता है:

1. स्थापित Gitorious। आवश्यक नहीं है लेकिन चीजों का ट्रैक रखने में मदद करता है,
2. गिटोरियस में अपना उत्पादन भंडार बनाएं।
3. उत्पादन भंडार में एक पोस्ट-हुक जोड़ें, जब अपडेट प्राप्त होते हैं, तो स्वचालित रूप से उत्पादन सर्वर अपडेट हो जाता है (शायद अगली रात में देरी हो सकती है, जो आपको सबसे अच्छा लगता है)।
4. गिटोरियस में एक विकास भंडार बनाएँ।
5. विकास रिपॉजिटरी को एक समान पोस्ट-हुक जोड़ें जो विकास सर्वर को अद्यतन करता है।

इस सेटअप कई लाभ हैं:

• डेवलपर साइट अपडेट करने के बारे में चिंता करने की जरूरत नहीं है। देव रेपो को धक्का देना उन्हें बस इतना करना है।
• परीक्षण पास के बाद उत्पादन सर्वर को अद्यतन करना बहुत आसान है, केवल धक्का पर्याप्त है (उत्पादन भंडार विकास सर्वर की तुलना में कहीं और से अपडेट नहीं किया जाता है)। आप पोस्ट-हुक में भी एक सेक्शन जोड़ सकते हैं जो टैग को धक्का दिया जाता है। तो आप एक टैग का उपयोग कर एक संस्करण संख्या के साथ रिलीज करने योग्य संस्करण को चिह्नित कर सकते हैं और यह स्वचालित रूप से उत्पादन सर्वर को अपडेट करेगा।
• बहुत कम अंक हैं जहां कोई गड़बड़ कर सकता है ("ओह! मेरा मतलब देव को धक्का देना था, बल्कि इसके बजाय प्रोडक्ट करना पड़ा।")।