मेरी कंपनी तर्कसंगत ClearCase से गिट तक हमारे संस्करण नियंत्रण उपकरण को बदलने की प्रक्रिया में है। हमारे पास निम्नलिखित विकास परिदृश्य है, और अगर हम क्लीयरकेस में हमारे समान व्यवहार को प्राप्त करने के लिए गिट के साथ पालन करने के लिए उचित पैटर्न रखते हैं तो हम उत्सुक हैं।क्लीयरकेस में केवल पढ़ने के लिए घटक के लिए गिट में समतुल्य क्या है?
यहाँ हमारे स्थिति के बारे में कुछ बुनियादी बिंदु हैं:
- हम असतत आवेदनों की एक संख्या है। आइए इन एपीए, एपीबी, और एपीसी को कॉल करें।
- हम भी कुछ फ़ाइलों (, लिपियों का निर्माण आदि) कि सभी परियोजनाओं के लिए आम हैं की है। आइए इन टूल्स को कॉल करें।
- अप्पा, AppB, या APPC कोड के किसी भी कटौती के लिए, हम उपकरण कोड की एक विशिष्ट कटौती की जरूरत है।
- हमारे अधिकांश डेवलपर टूल कोड को कभी भी संशोधित नहीं करते हैं।
ClearCase के लिए, हम इस तरह इस मॉडल किया है:
घटक: app_a, app_b, app_c, उपकरण
परियोजनाएं: अप्पा, AppB, APPC, उपकरण
प्रोजेक्ट ऐपए में पढ़ने-लिखने वाले घटक के रूप में एप_ए को पढ़ने/लिखने वाले घटक और टूल के रूप में शामिल किया गया है।
परियोजना AppB एक पढ़ा/घटक और उपकरणों केवल-पढ़ने के घटक के रूप में लिखने के रूप में app_b भी शामिल है।
परियोजना APPC एक पढ़ा/घटक और उपकरणों केवल-पढ़ने के घटक के रूप में लिखने के रूप में app_c भी शामिल है।
परियोजना उपकरण पढ़ने/लिखने घटक के रूप में उपकरण शामिल हैं।
अनुप्रयोग * परियोजनाओं के लिए प्रत्येक आधारभूत दोनों app_ * और उपकरणों compoments पर एक आधारभूत संदर्भ देता है। जब डेवलपर्स अनुशंसित बेसलाइन पर वापस आते हैं, तो वे दोनों घटकों में परिवर्तनों को खींचते हैं।
गिट के लिए, हमें लगता है कि सबमिड्यूल सही उत्तर की सबसे नज़दीकी चीज हो सकती है। हालांकि, जब एक संग्रह को खींच/पुन: उत्पन्न करते हैं, तो ऐसा लगता है कि इसे सबमिशन कोड को अपडेट करने के लिए एक अतिरिक्त चरण की आवश्यकता है। आदर्श रूप में, हम पारदर्शी होना चाहते हैं। साथ ही, हमें जरूरी नहीं है कि माता-पिता के भंडार के दृष्टिकोण से एक सबमिशन में क्या बदल गया है; हम केवल पूरे सबमिशन के लिए एक बिंदु के बारे में परवाह करते हैं।