गिट-फ्लो और क्लाइंट-विशिष्ट कार्यक्षमता

Question

क्लाइंट-विशिष्ट कार्यक्षमता को प्रबंधित करने और Git-flow, या सामान्य रूप से गिट के भीतर अनुरोधों को बदलने के लिए आप कैसे अनुशंसा करेंगे? क्या ग्राहक-विशिष्ट सुविधाएं क्लाइंट को समर्पित एक अलग शाखा में होनी चाहिए? (प्रत्येक ग्राहक के पास विकास शाखा से अपनी शाखा होती है।) या वे एक अलग भंडार में होना चाहिए? (प्रत्येक क्लाइंट में एक समर्पित भंडार होता है, जिसमें मास्टर रिपोजिटरी हमारा मुख्य भंडार होता है।)

Answer 1

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

Answer 2

ऐसा लगता है कि आपके पास एक कोड आधार है जो सभी क्लाइंट उपयोग करते हैं, और फिर आपके पास क्लाइंट विशिष्ट कार्यक्षमता के लिए कुछ "हैक्स" हैं।

मेरी राय में, आपके पास मास्टर शाखा पर "बेस" कोड होगा। सभी ग्राहकों के पास एक ग्राहक विशिष्ट शाखा होगी। सावधान रहें और जानें कि आपके परिवर्तन कहां किए जा रहे हैं।

हर बार, सुनिश्चित करें कि आप अपनी क्लाइंट शाखाओं को रीबेस करें, मूल रूप से उन्हें मूल कोड पर लाएं और उसके बाद उनके सभी विशिष्ट परिवर्तनों को फिर से चलाएं।

रीबेजिंग काफी भ्रमित हो सकता है जब तक आप इसे क्रिया में नहीं देखते।

स्पष्टता के लिए क्रमिक प्रतिबद्ध संख्याओं का उपयोग करना। वास्तविक जीवन में कमियां

 
Master is at commit 10 
\ 
    Branch has commits 10, 11, 12, 13, 14, 15 (notice it has commit 10 as well) 
| 
Master commits 16, 17 


When you rebase: 
    Master has 10, 16, 17. 
    Branch has 10, 16, 17, 11, 12, 13, 14, 15 

यहां आदेश बहुत महत्वपूर्ण है। Rebase शाखा को 10 तक रिवाइंड करता है, 16 और 17 लागू होता है, और उसके बाद 11, 12, 13, 14, और 15. के

इस बिंदु पर, जब तक कोई संघर्ष नहीं होता है, तो शाखा तक मास्टर के साथ तिथि और ग्राहक विशिष्ट परिवर्तन है।