कई परियोजनाओं के साथ सर्वर के लिए जीआईटी रिपोजिटरी लेआउट

Question

मेरे द्वारा सबवर्सन सेट अप करने के तरीके में से एक चीज यह है कि मेरे पास एकाधिक परियोजनाओं के साथ एक मुख्य भंडार हो सकता है। जब मैं किसी प्रोजेक्ट पर काम करना चाहता हूं तो मैं सिर्फ उस परियोजना को देख सकता हूं। इस

\main 
    \ProductA 
    \ProductB 
    \Shared 

तो

svn checkout http://.../main/ProductA 

एक नया उपयोगकर्ता के रूप में की तरह git करने के लिए मैं एक विशिष्ट कार्यप्रवाह करने से पहले क्षेत्र में सबसे अच्छा अभ्यास का एक सा पता लगाने के लिए चाहते हैं। जो मैंने अभी तक पढ़ा है, उससे गिट प्रोजेक्ट पेड़ की जड़ पर एक ही .git फ़ोल्डर में सबकुछ स्टोर करता है। तो मैं दो चीजों में से एक कर सकता था।

1. प्रत्येक उत्पाद के लिए एक अलग परियोजना सेट अप करें।
2. उप फ़ोल्डरों में एक विशाल परियोजना और स्टोर उत्पादों को सेट करें।

उत्पादों के बीच निर्भरताएं हैं, इसलिए एकल विशाल परियोजना उचित लगती है। हम एक सर्वर का उपयोग करेंगे जहां सभी डेवलपर अपना कोड साझा कर सकते हैं। मुझे पहले ही यह एसएसएच & HTTP पर काम कर रहा है और वह भाग जिसे मैं प्यार करता हूं। हालांकि, एसवीएन में रिपोजिटरी पहले से ही बहुत से जीबी आकार में हैं, इसलिए प्रत्येक मशीन पर पूरे भंडार के चारों ओर खींचना एक बुरा विचार है - खासकर जब से हमें अत्यधिक नेटवर्क बैंडविड्थ के लिए बिल भेजा जाता है।

मैं कल्पना करता कि लिनक्स कर्नेल परियोजना खजाने समान रूप से बड़े तो वहाँ Git के साथ इस से निपटने में उचित तरीके से किया जाना चाहिए रहे हैं, लेकिन मैं सिर्फ यह अभी तक पता लगा नहीं किया है।

वहाँ किसी भी दिशा-निर्देश या बहुत बड़ी बहु परियोजना खजाने के साथ काम करने के लिए सर्वोत्तम प्रथाओं हैं?

Answer 1

दिशानिर्देश Git limits के संबंध में, सरल है:

• एक submodules के साथ इस परियोजना
• एक मुख्य परियोजना प्रति रेपो।

विचार एक विशाल Git रेपो में सब कुछ स्टोर करने के लिए नहीं है, लेकिन एक परियोजना या के आम घटक का प्रतिनिधित्व करने के लिए एक मुख्य परियोजना, अन्य रेपोस के अधिकार करता दर्शाएंगे जो, हर एक के रूप में एक छोटे से रेपो का निर्माण होता है अपना ही है।

---

OP Paul Alexandercomments:

यह तोड़फोड़ द्वारा प्रदान की "बाहरी" समर्थन के लिए इसी तरह लग रहा है।
हमने कोशिश की और बाहरी लोगों में संस्करण संदर्भों को लगातार अद्यतन करने के लिए यह बेहद बोझिल पाया क्योंकि परियोजनाओं को एक-दूसरे पर निर्भरताओं के साथ समवर्ती रूप से विकसित किया गया है। क्या कोई और विकल्प है ??

@Paul: हाँ, बजाय मुख्य परियोजना से संस्करण का अद्यतन करने के लिए आपको या तो:

• अपने उप सीधे मुख्य परियोजना के भीतर से बढ़ने लगता है (के रूप में "True Nature of submodules" में समझाया गया है),
• या आप उप-रेपो में origin में उसी उप-रेपो की तरफ विकसित होने की दिशा में संदर्भित करते हैं: वहां से आपको उस सब-रेपो को कहीं और किए गए परिवर्तनों से खींचना होगा।

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

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

मैंने जवाब दिया:

सच में, तुम सही हो सकता है ... कि नवीनतम तक Git release 1.7.1 है।
git diff और git status दोनों मुख्य परियोजना से निष्पादित किए जाने के बावजूद खाता सबोडोड्यूल राज्यों को ध्यान में रखना सीखा।
आप बस सबमिशन संशोधन को याद नहीं कर सकते हैं।

कहा कि जा रहा है:

• submodules SVN बाहरी से अलग हैं: देखें "Why are git submodules incompatible with svn externals?"
• प्रबंध submodules मुश्किल हो सकता है: देखें "How exactly does git submodule work?"।

Answer 2

गिटस्लेव आपको एक के रूप में कई स्वतंत्र प्रतिनिधि प्रबंधित करने की अनुमति देता है। प्रत्येक रेपो को नियमित गिट कमांड द्वारा छेड़छाड़ की जा सकती है, जबकि गिटस्लेव आपको अतिरिक्त रूप से सभी रिपोज़ पर कमांड चलाने की अनुमति देता है।

super-repo 
+- module-a-repo 
+- module-b-repo 

gits clone url-super-repo 
gits commit -a -m "msg" 

रेपो-प्रति-प्रोजेक्ट में मैकेन जैसे टूल के साथ घटकीकरण और सरलीकृत निर्माण के फायदे हैं। रेपो-प्रति-प्रोजेक्ट कचरे के गलत कामों के मामले में डेवलपर क्या बदल रहा है, इस दायरे को सीमित करके सुरक्षा जोड़ता है।