गिट: मास्टर को किसी विषय शाखा में विलय करना अक्सर बाद में संघर्ष से बचें?

Question

तर्क के लिए कहें कि हमें इतिहास के बारे में ज्यादा परवाह नहीं है।

अगर मैं एक मास्टर शाखा है कि कुछ हद तक अक्सर अपडेट किया जा रहा है और मैं एक साझा विषय शाखा है कि नहीं बल्कि लंबे समय तक रहते थे है, नियमित रूप से master- विलय होगा> विषय शाखा (और संघर्ष को हल करने के रूप में वे उत्पन्न होती हैं) एक के लिए अनुमति विषय शाखा के चिकनी विलय -> बाद में मास्टर?

Answer 1

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

बेशक, है ना? समय के साथ, आपकी शाखाएं अलग हो जाती हैं। और आज आप अपना कोड कैसे लिखते हैं इस पर निर्भर करता है कि आपने कल इसे कैसे लिखा था। जितनी अधिक आपकी शाखाएं आज अलग हो गई हैं, उतनी ही अधिक कल वे अलग हो जाएंगी।

कहें कि मुख्य शाखा में आप कुछ कोड दोबारा प्रतिक्रिया देते हैं। कहें कि साइड शाखा में आपको एक नई सुविधा लागू करना है जो कि कोड का उपयोग करता है जिसे दोबारा किया गया था। यदि आप रीफैक्टरिंग परिवर्तनों को विलय (बैकपोर्ट) में विलय करने से पहले उस नई सुविधा को लिखते हैं, तो, जब आप मुख्य सुविधा को नई सुविधा में पोर्ट करना चाहते हैं, तो आपको या तो ए को प्री-रिफैक्टर कोड या मुख्य में वापस जोड़ना होगा) नई सुविधा refactor। जबकि अगर आप पहले ही विलय (बैकपोर्टेड) ​​रिफैक्टरिंग कर चुके थे, तो आपकी नई सुविधा को उस काम के बिना मुख्य रूप से विलय किया जा सकता है।