.NET समाधान

Question

के लिए गिट रिपॉजिटरी सेट अप करना मेरे पास 15 सी # प्रोजेक्ट्स का समाधान है और मैं उनके लिए एक कुशल गिट भंडार स्थापित करने की कोशिश कर रहा हूं। क्या मुझे उस स्तर पर या समाधान के तहत प्रत्येक परियोजना के लिए एक भंडार बनाना चाहिए?

WebServices/ 
|- WebServices.sln 
|- WebService1/ 
`- WebService1.csproj 
|- WebService2/ 
`- WebService2.csproj 

समाधान ../framework/framework.csproj के लिए एक परियोजना संदर्भ जो एक अलग भंडार है और सभी अन्य परियोजनाओं के लिए एक संदर्भ है है। समाधान के तहत परियोजनाएं किसी भी तरह से जुड़ी नहीं हैं, लेकिन वे सभी ढांचे का उपयोग करते हैं।

मुझे लगता है कि ढांचे में कोई भी बदलाव परियोजनाओं को पारित किया जाएगा।

क्या आपके पास मेरे लिए कोई मार्गदर्शिका है कि इसे सर्वोत्तम तरीके से कैसे प्राप्त किया जाए?

Answer 1

कैसे अपने भंडार स्थापित करने के लिए करने के लिए कोई भी जवाब नहीं है। यह आपकी विशिष्ट जरूरतों पर निर्भर करता है।

कुछ सवाल आप अपने आप को पूछना चाहिए में शामिल हैं:

1. सभी परियोजनाओं रिलीज होने जा रही हैं और अलग से संस्करणीकृत?
2. क्या परियोजनाएं वास्तव में एक-दूसरे से स्वतंत्र हैं?
3. आपकी विकास टीम कैसे संरचित की जाती है? क्या व्यक्तिगत डेवलपर्स एक परियोजना से चिपके रहते हैं?
4. क्या आपकी ढांचा परियोजना स्थिर है?
5. क्या आपकी बिल्ड प्रक्रिया प्रत्येक परियोजना को अलग से बनाती है?

यह मानते हुए कि है ऊपर के सभी के लिए जवाब "हाँ", तो मैं इसे स्थापित करेगा ताकि तरह:

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

आप "हाँ" सभी # 5 (और # 1 संभवतः), इसके बाद के संस्करण को छोड़कर के लिए कह सकते हैं, तो मैं एक और भंडार है कि अलग-अलग परियोजनाओं और एक वैश्विक समाधान फ़ाइल में से प्रत्येक के submodules के होते हैं जोड़ना होगा कि आपका निर्माण सर्वर उपयोग कर सकते हैं। यदि आप एक नई परियोजना जोड़ते हैं, तो आपको इस भंडार को भी अपडेट करना याद रखना होगा!

यदि आपको # 2 को "नहीं" कहना है, तो बस एक ही संग्रह बनाएं।

यदि आपको # 3 पर "नहीं" कहना है, तो आपको कोड को अलग करने और डेवलपर्स को रिपोज़ के बीच स्विच करने की आवश्यकता के बीच एक निर्णय कॉल करना होगा। आप submodules सहित एक अलग भंडार बना सकते हैं, लेकिन यदि आपके सभी डेवलपर्स उस रेपो का उपयोग करके उड़ते हैं, तो आप वास्तव में केवल छोटे लाभ के साथ नए रखरखाव को पेश कर रहे हैं।

यदि आपका ढांचा स्थिर नहीं है (# 4), तो आप इनमें से किसी भी मामले में एक सबमिशन के रूप में शामिल करना चाहेंगे। मैं अनुशंसा करता हूं कि एक बार यह स्थिर हो जाए, तो आप उस समय सबमिशन को हटाने और NuGet पर स्विच करने में लग रहे हैं।

Answer 2

आपकी प्रत्येक परियोजना के लिए "कितना स्वतंत्र" विकास होने के आधार पर आप दो विकल्प पर विचार कर सकते हैं।

• आप ज्यादातर पूरे समाधान पर काम कर रहे हैं मामले में - पूरे समाधान

• मामले में कुछ परियोजनाओं वास्तव में स्वतंत्र हैं के लिए एक रेपो बनाने उन परियोजनाओं के लिए अलग रेपोस बना सकते हैं और एक तरफ प्रत्येक परियोजना के लिए समाधान फ़ाइल बनाने प्रोजेक्ट फ़ाइल, फिर मुख्य समाधान के रेपो में उन रेपो को संदर्भित करने के लिए गिट सबमिड्यूल का उपयोग करें, जो उन परियोजनाओं का उपयोग करते हैं।

Git Submodules Tips

Answer 3

मैंने ऐसी स्थिति के लिए क्या किया है, निम्नलिखित था। ध्यान दें कि मेरे मामले में 2-3 डेवलपर्स थे।

तो मैं इस में 3 बातें हैं:

1. खाली परियोजना संरचना है कि मैं [वैकल्पिक]
2. आम लाइब्रेरी प्रोजेक्ट
3. वास्तविक अंत परियोजनाओं है कि आम लाइब्रेरी प्रोजेक्ट का उपयोग को दोहराने के लिए चाहते हैं

1) मैं बस अपना पाड़ विकास निर्देशिका संरचना बना सकते हैं और मैं एकडाल रहा हूँ गिट के लिए प्रत्येक मेंफ़ाइल और उनमें से प्रत्येक को शामिल करने के लिए। इस तरह जब मैं खुद को एक नए पीसी में स्थापित करना चाहता हूं तो मैं इसे क्लोन करता हूं और मेरे पास मेरा खाली विकास "ब्रह्मांड" संरचना है। फिर मैं उन परियोजनाओं के साथ (गिट क्लोन) पॉप्युलेट करता हूं।

2) आम पुस्तकालय परियोजना सिर्फ एक सामान्य रेपो है।

3) मेरी अंत परियोजनाएं संदर्भ सामान्य पुस्तकालय परियोजनाओं। इसके बारे में prons और विपक्ष हैं और आपकी स्थिति पर निर्भर करता है, लेकिन मैं जो हासिल करता हूं वह यह है कि मैं आम पुस्तकालयों को सीधे सामान्य पुस्तकालय परियोजना से या अंत परियोजना से संदर्भित कर सकता हूं जो इसका संदर्भ देता है। दोनों तरीकों से मुझे गिट में बदलाव मिलते हैं और सामान्य रूप से और अलग से प्रतिबद्ध होते हैं।

आपके मामले में मेरे पास मेरी खाली संरचना होगी और फिर 2 अलग क्लोन करें। सही जगह में ढांचे परियोजना और फिर पूरे webservices repo।

यदि आप प्रत्येक वेब सेवा के लिए एक अलग रेपो चाहते हैं या सभी के लिए यह आपके ऊपर है। यह आपके व्यक्ति की गिनती और कार्य प्रवाह पर निर्भर करता है।

एक उचित .gitignore यहाँ भी भूल नहीं है: LINK

Answer 4

तो

• तुम सच में ही समाधान
• आम परियोजना "की रूपरेखा" में सभी परियोजनाओं करना चाहते हैं सक्रिय विकास में है (और कुछ संशोधनों के लिए एक परियोजना के लिए दूसरों को तोड़ सकता है ...)

मुझे लगता है कि आप submodule ही फ्रेमवर्क परियोजना के बारे में उनकी स्वयं की प्रतिलिपि के साथ एक Git परियोजना के रूप में प्रत्येक WebService होना चाहिए:

WebServices/ 
|- WebServices.sln 
|- WebService1/ 
`|-.git 
    |-WebService1.csproj 
    |-Framework (as submodule) 
|- WebService2/ 
`|-.git 
    |-WebService2.csproj\ 
    |-Framework (as submodule) 

इस तरह प्रत्येक WebService फ्रेमवर्क संस्करण के साथ संगत है का उपयोग करेगा।

(! बेशक आप Git submodule कामकाज के बारे में पता होना चाहिए ... आप उदाहरण this के लिए पढ़ सकते हैं, विशेष रूप से अनुभाग "submodules के साथ मुद्दे")

महत्वपूर्ण: इस विन्यास के साथ प्रत्येक तैनात वेब सेवा चाहिए फ्रेमवर्क लाइब्रेरी को वास्तविक संस्करण के साथ संदर्भित करें जिसका उपयोग कर रहा है!