मैं जानना चाहूंगा कि क्या यह उस परियोजना को विभाजित करने के लिए समझ में आता है जिसे मैं एक के बजाय दो रिपॉजिटरी में काम कर रहा हूं।
मैं क्या कह सकता हूं:
- Frontend को html + js में लिखा जाएगा
- बैकएंड में .net
- बैकएंड फ्रंटएंड पर निर्भर नहीं करता है और फ्रंटेंड बैकएंड पर निर्भर नहीं करता है
- फ्रंटएंड बैकएंड में लागू एक आरामदायक एपि का उपयोग करेगा।
- फ्रंटएंड को किसी भी स्थिर http सर्वर पर होस्ट किया जा सकता है।
अब तक, रिपॉजिटरी में यह संरचना है:
जड़:
- फ़्रंट एंड/*
- बैकएंड / *
मुझे लगता है कि दोनों प्रोजेक्ट को एक ही रिपॉजिटरी में रखना एक गलती है। चूंकि दोनों परियोजना में एक-दूसरे के बीच निर्भरता नहीं है, इसलिए उन्हें व्यक्तिगत रिपॉजिटरी में होना चाहिए और यदि आवश्यक हो तो माता-पिता के रिपॉजिटरी में जो सबमॉड्यूल्स हैं।
मुझे बताया गया है कि यह व्यर्थ है और ऐसा करने से हमें कोई लाभ नहीं होगा।
यहाँ मेरे कुछ तर्क हैं:
- हमारे पास दो मॉड्यूल हैं जो एक दूसरे के बीच निर्भर नहीं करते हैं।
- लंबे समय में दोनों परियोजनाओं के स्रोत के इतिहास में चीजों को उलझाया जा सकता है (जब आप उन कमियों के आधे हिस्से के इतिहास में खोज करने का प्रयास करें जो आपके द्वारा खोजे गए बग से पूरी तरह से संबंधित नहीं हैं)
- संघर्ष और विलय (यह नहीं होना चाहिए, लेकिन किसी को बैकएंड पर धकेलने से अन्य डेवलपर को फ्रंटएंड परिवर्तनों को आगे बढ़ाने के लिए बैकएंड परिवर्तन खींचने के लिए मजबूर होगा।)
- एक डेवलपर केवल बैकएंड पर ही काम कर सकता है, लेकिन उसे हमेशा फ्रंटेंड या दूसरे तरीके से खींचना होगा।
- लंबे समय में, जब यह तैनात करने का समय होगा। किसी तरह, बैकएंड सर्वर होने पर, फ्रंटेंड को कई स्थिर सर्वर पर तैनात किया जा सकता है। हर मामले में, लोगों को या तो इसके साथ पूरे बैकएंड को क्लोन करने के लिए मजबूर किया जाएगा या कस्टम स्क्रिप्ट बनाने के लिए सभी सर्वरों को आगे बढ़ाने के लिए या बैकएंड को हटाने के लिए धक्का दिया जाएगा। अगर केवल एक की जरूरत है तो केवल फ्रंट या बैकेंड को आगे बढ़ाने / खींचने में आसान है।
- काउंटर तर्क (एक व्यक्ति दोनों परियोजनाओं पर काम कर सकता है), सबमॉड्यूल के साथ तीसरा रेपो बनाएं और इसके साथ विकसित करें। इतिहास को अलग-अलग मॉड्यूल में अलग रखा जाता है और आप हमेशा ऐसे टैग बना सकते हैं जहां बैकएंड / फ्रंटेंड का संस्करण वास्तव में सिंक में एक साथ काम करता है। दोनों रेपो / बैकएंड एक साथ एक रेपो में होने का मतलब यह नहीं है कि वे एक साथ काम करेंगे। यह सिर्फ दोनों इतिहास को एक बड़े रेपो में विलय कर रहा है।
- यदि आप प्रोजेक्ट में एक फ्रीलांसर जोड़ना चाहते हैं, तो सबमॉड्यूल के रूप में फ्रंटएंड / बैकएंड होने से चीजें आसान हो जाएंगी। कुछ मामलों में, आप वास्तव में कोडबेस की पूरी पहुँच नहीं देना चाहते हैं। यदि आप "बाहरी लोगों" को देख / संपादित कर सकते हैं, तो एक बड़ा मॉड्यूल रखने से चीजें कठिन हो जाएंगी।
- बग परिचय और फिक्सिंग बग, मैंने फ्रंटेंड में एक नया बग डाला। फिर कोई बैकएंड में बग को ठीक करता है। एक रिपॉजिटरी के साथ, नए बग से पहले वापस रोल करने से बैकएंड भी रोलबैक हो जाएगा जिससे इसे ठीक करना मुश्किल हो सकता है। मैं एक अलग फ़ोल्डर में बैकएंड को क्लोन करना चाहता हूं, बैकएंड को बग में फिक्सिंग के दौरान काम करना है ... फिर चीजों को फिर से जोड़ने की कोशिश कर रहा है ... दो रिपॉजिटरी होने के बाद दर्द रहित होगा क्योंकि एक रेपो के सिर को जीतना 'दूसरे को मत बदलो। और बैकएंड के विभिन्न संस्करण के खिलाफ परीक्षण दर्द रहित होगा।
क्या कोई मुझे उन्हें समझाने के लिए अधिक तर्क दे सकता है या कम से कम मुझे बता सकता है कि परियोजना को दो सबमॉड्यूल में विभाजित करने के लिए यह व्यर्थ (अधिक जटिल) क्यों है। यह प्रोजेक्ट नया है और कोडबेस एक दो दिन पुराना है इसलिए इसे ठीक करना जल्द नहीं है।