गिट फीचर शाखाएं और मामूली कोड सुधार

Question

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

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

हमारे पास यह मुद्दा है कि एक सुविधा पर नियमित विकास के दौरान, डेवलपर सिस्टम को बेहतर बनाने या कुछ तकनीकी ऋण को साफ करने के लिए कुछ सामान्य कोड को संशोधित/दोबारा संशोधित करना चाहता है। यह परिवर्तन मूल्यवान है, लेकिन विकास के तहत सुविधा से सीधे बंधे नहीं है।

हमारे वर्कफ़्लो के आधार पर, इसे वास्तव में एक अलग शाखा पर किया जाना चाहिए जो इसे विकसित करने से पहले अपने स्वयं के पुल अनुरोध और कोड समीक्षा के माध्यम से हो। अगर हमने उन्हें ऐसा किया है, तो वे इस दौरान अपनी फीचर शाखा में बदलाव कैसे प्राप्त कर सकते हैं, जबकि वे पूर्ण कोड समीक्षा होने की प्रतीक्षा करते हैं और कोड को विकसित करने में विलय हो जाता है।

विचारों हमारे पास हैं:

1) हमारे सुविधा शाखा में 'refactorX' शाखा से परिवर्तन चेरी लेने। विकास जारी रखें और गिट (उम्मीदपूर्वक) समझें जब हम यह समझने के लिए विलय करते हैं कि इसमें पहले से ही रिफैक्टर शाखा से परिवर्तन है।

2) हमारी फीचर शाखा में 'refactorX' शाखा को मर्ज करें और विकास जारी रखें। (नोट: 'refactorX' के लिए विकसित शाखा बंद हो सकती है बाद में विकास के इतिहास में हो सकता है, इसलिए हमें लगता है कि इसमें समस्याएं हो सकती हैं)

3) कुछ अन्य स्मार्ट विकल्प जिन्हें हम अभी तक नहीं जानते हैं। :)

हम जो खोज रहे हैं वह वर्कफ़्लो के इस हिस्से को संभालने के तरीके पर कुछ सर्वोत्तम अभ्यास मार्गदर्शन है। इसके बारे में बात करने के बाद हम जानते हैं कि यह अक्सर आ जाएगा और हम अपने वर्कफ़्लो में इसे संभालने के लिए एक आसान और कुशल तरीका खोजना चाहते हैं।

कोई सिफारिशें?

Answer 1

ऐसा लगता है कि आप विकास शाखा सुविधा शाखा में वापस मर्ज होने से रोकने की कोशिश कर रहे हैं। इस कदम से बचने के लिए फायदेमंद है, लेकिन कभी-कभी यह आवश्यक है, खासकर इस तरह की स्थितियों में।

एक तकनीक जिसे हम उपयोग करना शुरू कर रहे हैं वह भी git rebase --onto है। फीचर शाखा में विकास शाखा को विलय करने के बजाय, फीचर शाखा को नई सुविधाओं को हासिल करने के लिए विकास शाखा के अंत में स्थानांतरित किया जा सकता है।

जब आप केंद्रीय भंडार का उपयोग कर रहे हैं, तो शायद यह एक नया फीचर शाखा नाम बनाने के लिए सबसे उपयोगी है। उदाहरण के लिए हम नई शाखा नाम पर -v2 संलग्न करते हैं।

ठेठ ले जाने की प्रक्रिया की तरह लग सकता है

git checkout feature 
git branch -m feature-v2 
git rebase --onto develop develop 
git push -u origin feature-v2 

अब आप अपने सुविधा शाखा में नए कोड है, लेकिन सुविधा शाखा में विकसित शाखा नहीं किए हैं।

Answer 2

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

ASCII आर्ट में, की समीक्षा करने पुनर्रचना करने से पहले:

--- development 
       \ 
       --- refactoring 
           \ 
           --- feature1 
           --- feature2 

और बाद में:

------ development|refactoring 
           \ 
           --- feature1 
           --- feature2 

तब, यदि आप feature1 समाप्त करने और में यह विलय:

------ refactoring --- development|feature1 
        \ 
        --- feature2 

आप rebase फीचर 2 फिर से विकास पर:

------ refactoring --- development|feature1 
              \ 
              --- feature2 

और फिर आप के रूप में हमेशा की तरह में feature2 विलय कर सकते हैं:

------ refactoring --- feature1 --- development|feature2