एक जीआईटी-एसवीएन डीबग-> फीचर शाखा को ट्रंक में स्थानांतरित करने का सबसे अच्छा तरीका क्या है?

Question

मुझे एक ट्रंक सेटअप मिला है जहां मेरा सभी उत्पादन कोड चला जाता है।

तब मेरे पास debug शाखा है (माता-पिता trunk है) जो मैं लॉगिंग, var डंप आदि जैसे डिबगिंग कोड जोड़ता हूं ... यह कभी भी उत्पादन में नहीं होना चाहिए। यह शाखा शायद ही कभी बदलती है।

अंत में मेरे पास feature शाखा है (माता-पिता debug) जहां मैं डिबगिंग के लाभों के साथ अपने सभी कोडिंग करता हूं। इस शाखा में लगातार काम करता है।

मैं सिर्फ यह जानना चाहता हूं कि feature कोड trunk पर ले जाने का कोई आसान तरीका है या नहीं। यह मैं वर्तमान में क्या कर रहा है:

1. अन्य devs से master और git svn rebase परिवर्तन करने के लिए मेरी feature शाखा में सभी परिवर्तन हो
2. स्विच। अन्य devs को
3. rebasemaster शाखा पर मेरी feature शाखा (git rebase --onto master debug feature)
4. merge सुविधा master को
5. git svn dcommit परिवर्तन
6. rebasedebug को master (git rebase master debug)
7. हटाना feature शाखा
8. एक बनानेसे नया शाखा।

Answer 1

मैं कहूंगा कि आपका कार्य प्रवाह बहुत इष्टतम है। मैं चेरी-पिकिंग को ओवरकिल मानता हूं (लेकिन यह काम करने की संख्या पर निर्भर करता है)।

आप क्या कर सकते हैं स्क्वैश सभी में एक काम करता है और चेरी-पिक/रीबेस बस इस पर।

और बीटीडब्ल्यू, अगर आप ऐसा कुछ करते हैं तो बस एक साधारण स्क्रिप्ट क्यों न लिखें? गिट थोड़ा कम स्तर का टूल है, इसलिए दोहराव वाले कार्यों में मदद के लिए अतिरिक्त स्क्रिप्ट लिखना एक बहुत अच्छा विचार है।

Answer 2

हमारे पास प्रत्येक सुविधा या बग फिक्स के लिए एक अलग शाखा है। इन्हें तब पर्याप्त रूप से परीक्षण किए जाने पर ट्रंक में वापस विलय किया जा सकता है।

शाखाएं अपडेट की जा सकती हैं यदि वे थोड़ी पुरानी हो जाएं।

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

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

आशा है कि मदद करता है

Answer 3

मुझे लगता है कि आप देख रहे हैं Git-चेरी पिकअप है। यह आपको बताए गए रीबेस नृत्य के बिना मास्टर पर फीचर से काम करने की अनुमति देता है।

चूंकि आप फीचर शाखा को हटाने जा रहे हैं, फिर भी आपको एक स्पष्ट विलय देखने की आवश्यकता नहीं है।

Answer 4

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

--reintegrate feature of subversion के साथ सिंक में अपने ट्रंक और डीबग शाखा को बनाए रखना आसान है। अपनी फीचर शाखा को मर्ज करने के लिए, आप ट्रंक में फीचर शाखा के सभी संशोधनों को मर्ज करेंगे। आदेशों होगा कुछ की तरह:

cd debug_branch_workcopy 
svn merge --reintegrate http://server/project/trunk . 
svn commit 

ट्रंक करने के लिए करने के लिए सुविधा शाखा मर्ज करने के लिए:

svn log --stop-on-copy http://server/project/branches/feature123 #see the last revision listed 
cd trunk_workcopy 
svn merge -r{revision_above}:HEAD http://server/project/branches/feature123 . 
svn commit 

आप पिछले मर्ज आदेश कई बार चला सकते हैं

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

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

Answer 5

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

मुझे लगता है कि आपकी भाषा में कुछ प्रकार की सशर्त संकलन तंत्र (#IFDEF प्रीप्रोसेसर निर्देश आदि) हैं। यदि आप इन में अपना डिबगिंग कोड लपेटते हैं तो आपको बहुत कम घर्षण का अनुभव होगा।

Answer 6

यदि मैं आपको सही ढंग से समझता हूं, तो आप अपनी डीबग सुविधाओं को केवल अपनी (सुंदर स्थिर) डीबग शाखा में रखना चाहते हैं, लेकिन आपकी मास्टर शाखा में नहीं। इस प्रयास करें:

मास्टर

git checkout master 
git merge --no-commit debug 
git checkout master .  # undo all changes, get the files from master again 
git add .     # stage all files 
git commit 

में इस तरह डिबग के एक "नकली मर्ज" करते हैं, डिबग मास्टर में विलय कर दिया जाएगा, लेकिन मास्टर में आपकी फ़ाइलों में से कोई भी बदल गया है जाएगा।

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

git checkout debug 
git checkout -b new_feature # create a new feature branch 
# hack, hack, hack 
git commit 
git checkout master   # All works fine... 
git merge new_feature  # ...so merge into master. Debug code will be stripped here 

आप new_feature पर तेजी से अग्रेषित कर सकते हैं डिबग शाखा है और इस के बाद new_feature शाखा को हटा दें।

ध्यान दें कि जब भी आप डीबग शाखा बदलते हैं, तो आपको नकली विलय प्रक्रिया को फिर से करना होगा।