क्या अलग-अलग परियोजनाओं को एक ही भंडार में रखना अच्छा विचार है यदि वे घनिष्ठ रूप से संबंधित हैं?

Question

मैं एक वेब एप्लिकेशन के शुरुआती चरणों में हूं जिसमें क्लाइंट साइड जावास्क्रिप्ट एप्लिकेशन होगा जो क्लाइंट के ब्राउज़र पर तैनात किया गया है और सर्वर साइड आरईएसटी टाइप एपीआई जो मेरे सर्वर पर रहेगी। दोनों अजाक्स और जेएसओएन डेटा का उपयोग करके संवाद करेंगे।

अब यह बात है; वे पूरी तरह अलग से विकसित किए जा रहे हैं, कोड या एक संसाधन की एक पंक्ति भी साझा नहीं कर रहे हैं। दोनों node.js अनुप्रयोग हैं। सर्वर पक्ष सभी सर्वर साइड स्टफ के लिए एक्सप्रेस और अनुक्रमित करता है, और क्लाइंट साइड स्टाइलस और कॉफी-स्क्रिप्ट के साथ हेम डेवलपमेंट सर्वर का उपयोग करके विकसित किया जाता है और इसे 3 फाइलों (index.html, application.js और application.css पर संकलित किया जाएगा)) जो आखिरकार सर्वर द्वारा स्थैतिक डेटा के रूप में तैनात किया जाएगा।

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

मैं किसी को भी यह बताना नहीं चाहता कि मुझे क्या करना है, लेकिन विकल्पों के पेशेवरों और विपक्षों के बारे में मुझे सूचित करें। आपके अनुभव में कार्रवाई का सबसे अच्छा तरीका और क्यों होगा। यदि आप उन्हें अच्छे मानते हैं तो कृपया कार्रवाई के अन्य पाठ्यक्रमों का भी सुझाव दें।

धन्यवाद!

Answer 1

अंगूठे का सामान्य नियम है, "एक ही समय में जो चीजें बदलती हैं उन्हें एक साथ संस्करणित किया जाना चाहिए।"

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

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

Answer 2

मेरे दृष्टिकोण से मैं root के तहत दो मुख्य फ़ोल्डरों में client और server विभाजित कर दूंगा। इस के लिए कई कारण हैं:

1. क्लाइंट और सर्वर विज्ञप्ति (शारीरिक रूप से) एक दूसरे से संबंधित होगा। जैसा कि वे वैसे भी करते हैं क्योंकि आपका ग्राहक आपके सर्वर सॉफ़्टवेयर द्वारा प्रदान की गई एपीआई से काफी संबंधित होगा। तो यदि आप रिपोजिटरी को रिलीज के रूप में टैग करते हैं तो आप सुनिश्चित होंगे कि दोनों कलाकृतियों को आसानी से मिलकर काम करना है।

2. भारी एकीकरण परीक्षण को लागू करने के साथ-साथ निरंतर एकीकरण बुनियादी ढांचे को लागू करने के लिए आपको कम दर्द होगा। अन्य विकल्पों के साथ इसे जगह में लाने के लिए भी संभव है लेकिन आपको अधिक ओवरहेड प्रदान करना होगा।

जनरल शाखा उपयोग:

• मास्टर आम तौर पर अपने आवेदन के अनुरूप स्थिर "स्नैपशॉट" के रूप में प्रयोग किया जाता है (ग्राहक, सर्वर सहित)
• एक शाखा एक नया प्रतिनिधित्व करने के लिए इस्तेमाल किया जा सकता सुविधा विकास। आमतौर पर वे इस तरह से उपयोग किया जाता है। तो आप 1..n शाखाओं को अपने सॉफ़्टवेयर में जोड़कर समाप्त कर सकते हैं। यदि आप इससे खुश महसूस करते हैं तो आपके मास्टर को वापस विलय कर दिया जाएगा।

Answer 3

शाखाओं एक आम कोड आधार के समानांतर संस्करण बनाने के लिए कर रहे हैं ("When should you branch" देखें)।
तो यह दो अलग-अलग, लेकिन बारीकी से संबंधित, मॉड्यूल का ट्रैक रखने के लिए एक अच्छा फिट नहीं है।

आपके गिट रेपो के भीतर सरल निर्देशिका पर्याप्त होगी, और यह सुनिश्चित करेगा कि आप जिस रेपो पर सेट करेंगे, वह दोनों मॉड्यूल दोनों का संदर्भ देगा।