उत्पाद द्वारा ग्राहक द्वारा गिट "ट्रंक"/"रिलीज"

मैं लंबे समय से एसवीएन का उपयोग कर रहा हूं और अब मैं सिर्फ "फैशन में" होने के लिए गिट में जा रहा हूं।

मेरी परेशानी यह है कि कैसे गिट प्रोजेक्ट मैनेजर/सॉफ्टवेयर डेवलपर्स प्रोग्राम के संस्करणों का प्रबंधन करते हैं: कोड के परिप्रेक्ष्य से नहीं, बल्कि ग्राहक के परिप्रेक्ष्य से।

मेरे पास कुछ परियोजनाएं हैं जो प्रत्येक ग्राहक से संबंधित हैं। एक अलग फ़ोल्डर के तहत प्रत्येक ग्राहक के पास "प्रोजेक्ट" फ़ोल्डर होता है और संभवतः एक "समर्थन" फ़ोल्डर होता है। प्रोजेक्ट का कोड प्रत्येक "प्रोजेक्ट" फ़ोल्डर के अंतर्गत मौजूद है। "समर्थन" के तहत कुछ सहायक दस्तावेज/स्क्रिप्ट इत्यादि हैं।

ऐसा भी मामला है जहां कुछ ग्राहक उत्पाद साझा करते हैं। उनमें से प्रत्येक कोड या कॉन्फ़िगरेशन के मामले में संस्करण हैं। लेकिन यह एक ही उत्पाद का है।

अब, बस हार्ड डिस्क पर ऐसा करने की कोशिश कर रहा हूं, मैं इसमें फंस गया हूं कि मेरे पास प्रत्येक प्रोजेक्ट के तहत .git है। एक ग्राहक फ़ोल्डर के तहत नहीं। मुझे यह पसंद नहीं है, जैसा कि मुझे लगता है कि इसका मतलब है कि मुझे याद रखने के लिए विकी (या एक टेक्स्ट फ़ाइल?) होना चाहिए (!) जहां गिट रिपॉजिटरीज हैं (उदाहरण के लिए, यदि कोई लैपटॉप बस्ट हो जाता है ... और मैं सभी गिट भंडारों को प्राप्त करने की आवश्यकता है। मुझे किसी भी तरह से डिस्क पर रिपॉजिटरीज़ वापस लेना होगा)।

दूसरी ओर ग्राहक फ़ोल्डर के तहत गिट भंडार होना बेहतर होगा? लेकिन उस स्थिति में, अगर मुझे "स्टैश/शाखा/मर्ज" करने की ज़रूरत है तो क्या यह "ग्राहक-छतरी-गिट" निर्देशिका के तहत बाकी परियोजनाओं को "नुकसान पहुंचाएगी"?

मैं कल्पना नहीं कर सकता कि क्या किसी ग्राहक को उत्पाद वाई के लिए फीचर एक्स की आवश्यकता होती है और साथ ही मुझे प्रोजेक्ट बी के लिए एक बग ठीक करने की आवश्यकता होती है। ग्राहक के फ़ोल्डर के नीचे गिट रिपॉजिटरीज मुझे डराता है।

या क्या कहीं गिट प्रॉपर्टी डालने का कोई तरीका है और ग्रहण/विचार/विंडोज एक्सप्लोरर (हाँ यकीन है ...) इसे पढ़ेगा और मुझे ग्राहक के तहत कौन सी परियोजनाओं के बारे में त्वरित स्वीकृति देगी?

आप इसका प्रबंधन कैसे करते हैं?

0
जोड़ा संपादित
विचारों: 5
आप निश्चित रूप से यह सुनिश्चित नहीं कर सकते कि क्या होगा। ऐसी परियोजनाएं हैं जो कोड 99% समान है। लेकिन भिन्नता है। मेरा मानना ​​है कि हम सभी को इस अस्पष्टता का सामना करना पड़ता है।
जोड़ा लेखक Ant, स्रोत
प्रश्न - जब ग्राहक कोई उत्पाद साझा करते हैं, तो अंततः दोनों ग्राहकों को प्रदान किए गए सभी कोड परिवर्तन होते हैं, या कुछ ग्राहक-विशिष्ट रहते हैं?
जोड़ा लेखक Sarov, स्रोत

2 उत्तर

मुझे यकीन नहीं है कि आपको यह विचार कहां मिला कि "गिट प्रोजेक्ट मैनेजर/सॉफ्टवेयर डेवलपर किसी प्रोग्राम के संस्करणों का प्रबंधन करते हैं [...] ग्राहक के परिप्रेक्ष्य से"। मैं गिट का उपयोग करता हूं और मेरे पास निश्चित रूप से प्रत्येक ग्राहक के लिए एक अलग रेपो नहीं है ...

वैसे भी, निम्नलिखित मेरी टीम के लिए अच्छा काम करता है:

उन उत्पादों के लिए जिनमें भिन्नताएं हैं, लेकिन अंततः विलय हो जाएंगी

इसके लिए गिट की शाखा प्रणाली का प्रयोग करें; प्रत्येक के लिए एक अलग शाखा है। इसके लिए एक दृष्टिकोण निम्न शाखा प्रणाली का उपयोग करना है:

  • एक मास्टर शाखा जो कोड के एकल 'लाइव' संस्करण का प्रतिनिधित्व करती है
  • प्रति ग्राहक एक बीटा शाखा। एक बार उस ग्राहक द्वारा एक सुविधा को मंजूरी मिलने के बाद, इसे मास्टर शाखा में विलय कर दिया जाता है और अन्य बीटा शाखाओं को परिवर्तन प्राप्त करने के लिए मास्टर पर छूट दी जाती है।
  • प्रति सुविधा एक सुविधा शाखा। एक बार यह सुविधा बीटा के लिए तैयार हो जाने के बाद, यह सही बीटा शाखा (एसएस) में विलय हो गई।

अलग-अलग उत्पादों के लिए जो समान हैं लेकिन कभी विलय नहीं किए जाएंगे

तीन भंडार हैं। ग्राहक/उत्पाद ए के लिए एक ग्राहक/उत्पाद बी के लिए एक और साझा कोड के लिए एक सबमिशन/सबट्री (अस्वीकरण: मैंने कभी भी उपट्री का उपयोग नहीं किया है)।

इस तरह, दो "एक ही उत्पाद पर भिन्नता" वास्तव में पूरी तरह अलग उत्पादों/भंडारों के रूप में माना जाता है; वे सिर्फ उनके बीच कोड साझा करते हैं।

केवल एक ग्राहक द्वारा उपयोग किए जाने वाले उत्पादों के लिए

सीधा। एक उत्पाद, एक ग्राहक, एक रेपो।


इस तरह, प्रत्येक उत्पाद में हमेशा एक और केवल एक गैर-सबमिशन रिपोजिटरी होती है।

1
जोड़ा
पूरा विचार बहुत दिलचस्प है। पहली बुलेट के लिए आप हमेशा प्रत्येक ग्राहक को मास्टर शाखा प्रदान करते हैं? क्या आपके पास यह मामला नहीं है कि एक शाखा स्थिर है और ग्राहक-ए के लिए अच्छा है लेकिन आप ग्राहक-बी को उसी कोड पर नहीं पहुंच सकते हैं? उदाहरण के लिए अनुबंध के अंत। या अन्य कानूनी बाधा। या आप प्रौद्योगिकी अंतर के कारण नहीं कर सकते हैं। .. की कमी का कहना है ... तो आपको एक शाखा (नया अपडेट किया गया कोड) और मास्टर (उन ग्राहकों के लिए जो अपग्रेड नहीं करते हैं) को बनाए रखने की आवश्यकता है। या आप शाखा को एक और नए पूरी तरह से नए मास्टर गिट में विभाजित करेंगे?
जोड़ा लेखक Ant, स्रोत
मैं आपके दृष्टिकोण पर विचार करूंगा और "पालतू" परियोजनाओं पर इसका परीक्षण करने की कोशिश करूंगा। और मुझे यह जानने के लिए "मानचित्र" जैसा कुछ होना चाहिए कि कौन सी परियोजना ग्राहक और शायद अन्य निर्भरताओं से संबंधित है ... आपके समय के लिए धन्यवाद।
जोड़ा लेखक Ant, स्रोत
@hephestos आप शाखा प्रणाली का उपयोग कैसे करते हैं संगठन-विशिष्ट होगा। जो कुछ भी आपके लिए सबसे ज्यादा समझ में आता है। एक दृष्टिकोण संकेत की एक और परत हो सकता है; पूरी तरह से तैयार कोड, ग्राहक-विशिष्ट 'लाइव' शाखाओं, ग्राहक-विशिष्ट 'बीटा' शाखाओं के लिए मास्टर शाखा, और उसके बाद फ़ीचर शाखाएं। एक सामान्य दिशानिर्देश के रूप में: जब यह एक उत्पाद शाखा का उपयोग करता है, जब यह कई उत्पाद अलग-अलग रिपोज का उपयोग करते हैं।
जोड़ा लेखक Sarov, स्रोत

मुझे लगता है, आपको अपनी दृष्टि बदलनी चाहिए। यह ग्राहक के संस्करण और शाखा नहीं है, लेकिन उत्पाद करता है। खासकर, अगर कुछ उत्पादों को ग्राहकों में साझा किया जाता है। तो, आपके पास उत्पाद फ़ोल्डरों के तहत अपना ".git" फ़ोल्डर्स होना चाहिए।

यदि आपको ग्राहकों के लिए अलग-अलग उत्पाद कॉन्फ़िगरेशन की आवश्यकता है, तो अपने उत्पाद फ़ोल्डर के अंतर्गत "कॉन्फ़िगरेशन" फ़ोल्डर बनाएं।

ऐसे मामले में आप उत्पाद और कॉन्फ़िगरेशन में नई सुविधाएं जोड़ सकेंगे, और समानांतर में बग ठीक कर पाएंगे।

गिट फ्लो संस्करण डिजाइन मॉडल भी उपयोगी हो सकता है तुम्हारे लिए।

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