मैं एसवीएन के साथ शुरुआत कर रहा हूं। मैं मूल आदेशों को जानता हूं और आधार सिद्धांतों को समझता हूं। मैं सोच रहा था कि क्या किसी के पास टीम के माहौल में तोड़फोड़ के साथ काम करने के लिए कोई सुझाव या सर्वोत्तम अभ्यास है।
मैं कोड करते समय यथोचित क्रिया संदेश जोड़ने का लाभ देख सकता हूं, लेकिन क्या मुझे ध्यान में रखना चाहिए?
सभी महान उत्तरों के लिए धन्यवाद - उन्होंने बहुत मदद की है।
जवाबों:
बार-बार आने पर प्रोत्साहित करें। संस्करण नियंत्रण में टीम के साथी महसूस कर सकते हैं कि उन्हें कोड को "सही काम करने" तक भंडार से बाहर रखने की आवश्यकता है। जितनी जल्दी हो सके हर किसी को जल्दी और अक्सर कमिटमेंट सिखाना। जब तक यह काम नहीं करता, तब तक कोड रखने के बजाय, यह प्रस्ताव रखें कि आपके टीम के साथी सुविधा के लिए शाखाएँ बनाते हैं जो ट्रंक को तोड़ सकती हैं। यह होता है ...
ब्रांचिंग और टैगिंग प्रथा स्थापित करें। सुविधाओं के लिए शाखाओं के अलावा, अपने साथियों को बड़े-बग फिक्स के लिए शाखाओं का उपयोग करने के लिए प्रोत्साहित करें। कार्य की शुरुआत और अंत में प्रमुख बग फिक्स टैग करें। उत्पादन / क्यूए रिलीज के लिए टैग (और संभवतः शाखाएं) बनाए रखें।
ट्रंक के लिए एक नीति स्थापित करें और उससे चिपके रहें। एक उदाहरण हो सकता है, "ट्रंक को हमेशा त्रुटियों के बिना निर्माण करना चाहिए।" या "ट्रंक को हमेशा सभी यूनिट परीक्षणों को पास करना चाहिए"। कोई भी कार्य जो ट्रंक के मानकों को पूरा नहीं कर सकता है उसे एक शाखा में किया जाना चाहिए।
कोड परिवर्तन के साथ स्वरूपण परिवर्तन न करें
यदि आप एक विशाल फ़ाइल का व्हाट्सएप ( Control+ K+ D), ठीक करना चाहते हैं। वास्तविक तार्किक परिवर्तन से अलग स्वरूपण परिवर्तन करें। यदि आप फ़ाइलों में फ़ंक्शन को स्थानांतरित करना चाहते हैं तो समान हो जाता है। वास्तविक संपादन से अलग चल रहा है।
मुख्य अवधारणाओं में से एक मैं हमेशा एक साथ संबंधित कोड परिवर्तन करने के लिए है । कोरोलरी एक ही प्रतिबद्ध में असंबंधित कोड परिवर्तन नहीं करता है । इसका मतलब यह है कि एक बार में 2 बग को ठीक न करें (जब तक कि यह एक ही फिक्स नहीं है), और 2 में से प्रत्येक में आधा बग फिक्स न करें। इसके अलावा, अगर मुझे सिस्टम के किसी असंबंधित हिस्से में कुछ नई वृद्धि या कुछ जोड़ने की आवश्यकता है, जो मुझे तब किसी अन्य काम के लिए चाहिए, तो मैं अलग से (और पहले) एन्हांसमेंट करता हूं। यह विचार यह है कि कोई भी परिवर्तन किसी को भी अपने दम पर करना चाहिए (या अपने दम पर वापस रोल करना) एक अलग प्रतिबद्धता होनी चाहिए। मर्ज करने के लिए या वापस टूटी हुई विशेषताओं को रोल करने का समय आने पर यह आपको बहुत सारे सिरदर्द से बचाएगा।
बहुत पहले ही उल्लेख किया गया है, और यहाँ कुछ और हैं:
यदि आपके पास ऐसी फ़ाइलें हैं जो आप स्रोत नियंत्रण (जैसे कॉन्फ़िगरेशन, संकलित फ़ाइलें, आदि) में नहीं चाहते हैं, तो उन्हें अनदेखा सूची में जोड़ें । इस तरह से आप किसी भी फाइल को नोटिस करते हैं जिसे आप एसवीएन के रूप में अज्ञात दिखाने वाली फाइलों की एक खाली सूची की अपेक्षा करके जोड़ना भूल जाते हैं।
एक पोस्ट प्रतिबद्ध घटना जोड़ें जो आपके डेवलपर को मेलिंग सूची (या इस लक्ष्य के लिए एक विशिष्ट) के लिए एक ईमेल भेजेगा जो प्रतिबद्ध परिवर्तन से संबंधित है और इसके लिए आदर्श रूप से पैच है।
अपने बग ट्रैकर के साथ एकीकृत करें ताकि कमिट्स डिफरेंस लिंक के साथ बग्स / फीचर रिक्वेस्ट पर दिखें। मंटिसबीटी जैसे बग ट्रैकर इसका समर्थन करते हैं।
निरंतर एकीकरण (जैसे क्रूज़कंट्रोल.नेट ), बिल्ड के लिए NAnt और यूनिट परीक्षणों के लिए NUnit / VS को एकीकृत करने पर विचार करें । इस तरह एक बार उपयोगकर्ता चेक-इन कोड या एक निर्धारित अंतराल पर कोड संकलित हो जाता है, इकाई परीक्षण चलाए जाते हैं, और डेवलपर को प्रक्रिया की प्रतिक्रिया मिलती है। अगर रिपॉजिटरी टूट जाती है (यानी निर्माण नहीं करता है) तो यह बाकी टीम को भी सचेत कर देगा।
खैर, मूल बातें:
लोग जो जवाब दे रहे हैं वह बहुत अच्छा है। इसमें से अधिकांश SVN के लिए सर्वोत्तम प्रथाओं के लिए svn उपयोगकर्ता डॉक में संक्षेपित है ।
दोहराना:
मैं उन सर्वोत्तम प्रथाओं को संक्षेप में बताना चाहूँगा जिनसे मैं चिपकता हूँ:
रिपॉजिटरी संरचना होनी चाहिए । व्यक्तिगत रूप से मैं निम्नलिखित भंडार संरचना का उपयोग करता हूं:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(पूर्व-अल्फा), A(अल्फा), B(बीटा), AR(अल्फा-रिलीज़), BR(बीटा-रिलीज़), RC(रिलीज़ उम्मीदवार), ST(स्थिर)।मेरे द्वारा उपयोग किए जा रहे सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन दृष्टिकोण के मुख्य सिद्धांतों को दर्शाने वाले आरेख के रूप में आप मेरे तोड़फोड़ की सर्वोत्तम प्रथाओं की रूपरेखा पा सकते हैं ।
एक चीज जो मुझे बहुत उपयोगी लगी है वह है svn: बाहरी संपत्ति जिसका अर्थ है कि आप अन्य रिपॉजिटरी से निर्देशिकाओं को अपने आप में संदर्भित कर सकते हैं। यह आपके कोड और डेटा को व्यवस्थित करने के बहुत अच्छे तरीके देता है। कुछ उदाहरण निम्न हैं:
अपने बग ट्रैकिंग सॉफ़्टवेयर के साथ एकीकरण का उपयोग करें। यदि आप Bugzilla का उपयोग करते हैं , तो आप इसे सेट कर सकते हैं यदि आपकी टिप्पणी "Bug XXXX" से शुरू होती है, तो आपका SVN टिप्पणी स्वचालित रूप से दिए गए बग में एक टिप्पणी के रूप में जोड़ा जाता है, जिसमें आपको उस संशोधन में SVN वेब इंटरफ़ेस का लिंक भी शामिल है।
SVN की ब्रांचिंग और मर्जिंग टूल्स और कन्वेंशन के बारे में जानें।
टीम के अन्य सदस्यों के साथ काम करने का सबसे अच्छा तरीका पूर्ण विकास सुविधाओं / सुधारों में काम को तोड़ना है, फिर एक शाखा में प्रत्येक व्यक्ति के व्यक्तिगत परिवर्तनों पर काम करना है। फिर बदलावों को मेनलाइन शाखा / ट्रंक में तब मिला दें जब पूरा / तैयार / अनुमोदित होने के लिए तैयार हो।
इस तरह से व्यक्ति अन्य परिवर्तनों से टकराए बिना एक सामान्य लक्ष्य (एक ही शाखा या अलग शाखाओं पर) की ओर काम कर सकते हैं।
आपका लाभ भिन्न हो सकता है, और यह केवल दो या दो से अधिक लोगों के लिए ओवरकिल हो सकता है।
यदि आप अच्छे उपकरणों का उपयोग कर रहे हैं तो यह बहुत आसान हो जाता है जो SVN के साथ अच्छी तरह से एकीकृत होते हैं। इनसे यह देखना आसान हो जाता है कि क्या बदला गया है और फिर अपने सभी या अपने परिवर्तनों का हिस्सा बनाने के लिए और एसवीएन में नवीनतम संस्करण के लिए अपनी कार्यशील प्रति को बार-बार अपडेट करें।
मैं कछुआ SVN (यदि आप Windows का उपयोग कर रहे हैं) और विज़ुअल SVN (यदि आप VS का उपयोग कर रहे हैं ) की सलाह देते हैं।
यह भी देखें कि क्या आप इसे सेट कर सकते हैं ताकि आपको किसी भी समय बदलाव होने पर ई-मेल या इसी तरह की अधिसूचना मिल सके (आमतौर पर यह भी प्रतिबद्ध संदेश और परिवर्तित फ़ाइलों की सूची सहित)। CVSDude जैसी सेवाएं इसकी पेशकश करती हैं। मुझे यह जानने में मदद मिलती है कि दोनों को अपडेट किया गया है और फिर मेरी वर्किंग कॉपी को अपडेट करने से पहले उस अपडेट में क्या है, इसका कुछ अंदाजा है।
ब्रांचिंग नीतियों के अलावा एट अल। (जहां एक आकार निश्चित रूप से सभी के लिए उपयुक्त नहीं है), आपके पास अच्छे तरीके होने चाहिए:
स्रोत नियंत्रण के लिए सुनहरा नियम: चेक इन अर्ली, चेक इन अक्सर
सुझावों के लिए कि कैसे अपने भंडार को व्यवस्थित करें:
अपनी टीम के साथ उनके परिवर्तनों के बारे में परामर्श करें, या किसी भी मर्ज संघर्ष को ठीक करने से पहले, कम से कम बहुत सावधानी से अंतर देखें। उन्हें मर्ज किए गए कोड की समीक्षा करने के लिए कहें, यह सुनिश्चित करने के लिए कि मर्ज में उनके अतिरिक्त नहीं खोए गए थे।
एक चीज जो मैंने देखी है कि टूटे हुए कमिट्स को कम करना है, अच्छी प्री-कमिटेड स्क्रिप्ट। उदाहरण के लिए, परिवर्तन के प्रतिबद्ध होने से पहले आप किसी भी इकाई परीक्षण को चला सकते हैं। यह थोड़ा धीमा होने का कारण होगा, लेकिन आप किसी के पैर की उंगलियों पर कदम रखने और माफी मांगने से बचते हैं। जब आपके पास एक बड़ी विकास टीम होती है और बहुत बार कमिट करता है, तो निश्चित रूप से यह प्रबंधित करना बहुत कठिन हो जाता है।
बग-ट्रैकर और प्रतिबद्ध नीति लागू करने के साथ एकीकरण के उदाहरणों में से एक है Trac की svn प्री / पोस्ट-कमिट हुक स्क्रिप्ट, जो प्रतिबद्ध संदेश बग-ट्रैकर में किसी भी टिकट का संदर्भ नहीं देता है और वर्तमान में टिप्पणी जोड़ने के लिए मना कर सकता है संदेश सामग्री पर आधारित टिकट (यानी प्रतिबद्ध संदेश में "फिक्स # 1, # 2 और # 8" कुछ हो सकता है, जहां # 1, # 2, # 8 टिकट नंबर हैं)।
SVN का उपयोग करने के लिए सबसे अच्छा अभ्यास :
जब आप पहली बार कार्यालय में आए और अपना ग्रहण प्रोजेक्ट खोला , तो पहला कदम यह है कि आप अपनी परियोजना को अपडेट करें।
अपडेट लेने के बाद, अपना काम शुरू करें। जब आपने अपनी कोडिंग पूरी कर ली, तो इसे ठीक से जांचें, कि क्या आपका एप्लिकेशन बिना किसी अपवाद के ठीक से चलता है। एक बार जब आप सुनिश्चित हो जाते हैं कि आपका कोड ठीक काम कर रहा है, तो कोड करने का समय आ गया है।
नोट: कोड करते समय, सीधे प्रतिबद्ध न हों। सर्वर के साथ एक सिंक्रनाइज़ेशन करें और जांचें कि सभी प्रतिबद्ध होने की आवश्यकता है। नोट: एक बार पूरे फ़ोल्डर को कमिट न करें। क्योंकि आपने अपनी आवश्यकता के लिए फाइल करने के लिए कुछ बदलाव किए होंगे या हो सकता है कि आपने अपने स्थानीय सिस्टम में कुछ फाइलें हटा दी हों। लेकिन सर्वर पर सेटिंग्स अलग हैं। इसलिए व्यक्तिगत रूप से फाइलों की जांच करें और कोड करें।
संघर्ष फ़ाइलों को सीधे अपडेट / अपडेट न करें।
ओवरराइड और अपडेट कब करें?
जब आपको पूरा यकीन हो कि आपको अपने किसी स्थानीय परिवर्तन की आवश्यकता नहीं है और सर्वर कॉपी को पूरी तरह से अपडेट करना चाहते हैं। ध्यान दें कि एक बार यदि आप ओवरराइड और अपडेट करते हैं, तो आपको अपना कोई भी स्थानीय परिवर्तन नहीं मिलेगा।
नोट: प्रोजेक्ट को एक दिन से अधिक समय तक अपडेट किए बिना न रखें। साथ ही कई दिनों तक बिना कमिटमेंट के कोड न रखें।
संवाद करें जो सभी एक ही घटक में काम कर रहे हैं और चर्चा करते हैं कि उन्होंने हर दिन क्या बदलाव किए हैं।
जब तक कोई कारण न हो, तब तक संपत्तियों और कॉन्फ़िगरेशन फ़ाइल को कमिट न करें। क्योंकि सेटिंग्स एक सर्वर पर और क्लाउड में अलग-अलग होंगी।
एसवीएन में लक्ष्य फ़ोल्डर न करें, केवल स्रोत कोड और संसाधन फ़ोल्डर को एसवीएन रिपॉजिटरी में बनाए रखना होगा।
जब आप अपना कोड खो देते हैं, तो घबराएं नहीं! आप SVN इतिहास से पहले की कॉपी वापस पा सकते हैं।
प्रोजेक्ट को अपनी डिस्क के कई स्थानों पर चेकआउट न करें। इसे एक स्थान पर चेकआउट करें और इसके साथ काम करें।
SVN अपने आप में एक अच्छी शुरुआत है और कुछ अन्य पोस्टरों ने सर्वोत्तम प्रथाओं पर कुछ बेहतरीन सुझाव दिए हैं।
केवल एक चीज जो मैं जोड़ूंगा, वह यह है कि निरंतरता प्रक्रिया को चलाने के लिए आपको क्रूज़कंट्रोल या टीमसिटी के साथ एसवीएन को हुक करना चाहिए। यह बिल्ड ईमेल भेजेगा और सभी को यह बता देगा कि किसी ने निर्माण को तोड़ दिया है।
यह बहुत जल्दी बताएगा कि आपकी प्रक्रिया निम्नलिखित है और कौन नहीं। कुछ घर्षण पैदा हो सकता है लेकिन आपकी टीम लंबे समय में बेहतर होगी।
हर कमेंट के लिए सटीक कमेंट करें
(मेनलाइन) का निर्माण न करें!
जैसे ही तार्किक इकाई बदलती है, प्रतिबद्ध करें
बैकअप उपकरण के रूप में तोड़फोड़ का उपयोग करने से बचें
संभव के रूप में एक छोटी शाखा / विलय
।
अधिक विवरण एसवीएन सर्वोत्तम प्रथाओं में पाए जा सकते हैं ।
याद रखें कि जितना अधिक वृद्धिशील, मॉड्यूलर, असतत और रसीला आप अपना कमिटमेंट करते हैं, उतना ही आपके लिए (या दूसरों के लिए) आसान होगा:
टिप्पणी टेम्पलेट के लिए इसका उपयोग करें:
[कार्य / कहानी xxx] [मामूली / प्रमुख] [टिप्पणी] [टिप्पणी का पालन करें] [बग के लिए URL]