जब मैं पहले से ही कमिट के बीच बहुत लंबा इंतजार कर चुका हूं तो मुझे क्या करना चाहिए?

Question

मैं शरारती था ... बहुत "काउबॉय कोडिंग," पर्याप्त कमिटिंग नहीं। अब, यहाँ मैं एक भारी प्रतिबद्धता के साथ हूँ। हां, मुझे सभी के साथ प्रतिबद्ध होना चाहिए था, लेकिन अब बहुत देर हो चुकी है।

क्या बेहतर है?

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

नोट: जैसा कि अभी मैं इस परियोजना पर काम करने वाला एकमात्र प्रोग्रामर हूं; एकमात्र व्यक्ति जो इन प्रतिबद्ध टिप्पणियों में से किसी पर भी गौर करेगा, वह कम से कम तब तक है, जब तक हम अधिक प्रोग्रामर नहीं रखते।

वैसे: मैं SVN और Subclipse का उपयोग कर रहा हूं। मैंने इनमें से कोई भी परिवर्तन करने से पहले एक नई शाखा बनाई थी।

अधिक जानकारी : मैंने पहली बार इस स्थिति में आने से संबंधित एक अलग सवाल पूछा: आवेदन के गोंद को फिर से लिखने की तैयारी कैसे करें

Comments

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

— एलेक्सिस

कम से कम शाखा पर इसकी जाँच करें, ताकि आप अपने परिवर्तनों को न खोएँ।

— रोरी हंटर

आप अपने आप को सवाल पूछते रह सकते हैं और अधिक समय तक प्रतीक्षा कर सकते हैं, या वास्तव में प्रतिबद्ध कर सकते हैं और जो भी गड़बड़ पैदा करता है उससे निपटें ... और फिर ... फिर से ऐसा न करें!

— केश विन्यास

# 1, माफी के लिए प्रार्थना करें, और फिर आगे

— बढ़ें

अधिक महत्वपूर्ण सवाल जो आपको खुद से पूछना चाहिए: "मैं इसे रोकने के लिए अपनी बुरी आदतों को कैसे बदलूं"। दिन में कम से कम एक बार नहीं करने का कोई कारण नहीं होना चाहिए , अधिक बार बेहतर।

— डॉक ब्राउन

Answer 1

जवाब देने के लिए, आपको अपने आप से पूछना होगा कि आप भविष्य में इन कमिट के परिणामों का उपयोग करने की अपेक्षा कैसे करते हैं। सबसे आम कारण हैं:

• यह देखने के लिए कि किस बग को जारी किया गया था।
• यह देखने के लिए कि कोड की एक निश्चित रेखा क्यों मौजूद है।
• दूसरी शाखा में विलय करने के लिए।
• किसी समस्या या समस्या के निवारण के लिए पिछले संस्करण की जांच करने में सक्षम होना उस संस्करण में देख रहा है।
• एक रिलीज से कुछ हिस्सों को शामिल करने या बाहर करने में सक्षम होना।

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

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

अपनी स्थिति के बारे में मेरी समझ से जैसा कि आपने इसे वर्णित किया है, ऐसा लगता है कि इस बिंदु पर अपनी प्रतिबद्धता को विभाजित करने का कोई लाभ नहीं है।

Comments

बहुत बढ़िया जवाब! जबकि मैं छोटे कमिट नहीं करने के बारे में कोई कम खेद महसूस नहीं करता हूं, मैं बहुत अच्छा महसूस करता हूं कि मुझे यथासंभव अच्छे व्यवहार पर वापस आने के लिए क्या करना चाहिए।

— डुर्रोन 597

3 और 5 के बारे में दूसरी बात यह है कि आप उन्हें करने की अनुमति देने के लिए अब जो भी काम करते हैं, आप तब तक इंतजार कर सकते हैं जब तक आपको वास्तव में इसकी आवश्यकता न हो और फिर वही काम करें। यह शायद भविष्य में कुछ कठिन होगा क्योंकि आपने जो किया उसकी याददाश्त चली गई है। लेकिन फिर, आपको शायद कभी इसकी आवश्यकता नहीं होगी।

— स्टीव जेसोप

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

— हंस-पीटर स्टॉर

@hstoerr - यदि आप 1.5 या बाद के संस्करण पर हैं, तो आप मर्ज के लिए --reingrgrate विकल्प के साथ इतिहास को संरक्षित कर सकते हैं।

— डस्टिन केंडल

git add -p यहाँ आपका सबसे अच्छा दोस्त है। मुझे उस फीचर से प्यार हो गया। इस तरह मैं अलग-अलग कमिट में अपने कोडिंग मानक संशोधन कर सकता हूं, और संबंधित कोड परिवर्तनों को अलग रख सकता हूं।

— स्पाइडी

Answer 2

मुझे लगता है कि आप जो कुछ भी करते हैं, उस कोड में जांच से बचने की कोशिश करें जिसे आप जानते हैं कि वह संकलन नहीं करेगा।

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

Comments

विकल्प तीन संभव है लेकिन यह बहुत समय लेने वाला होगा। मुझे लगता है कि मैं सिर्फ

— ड्यूर्रोन 597

कमेटी कोड के डाउनसाइड्स क्या हैं जो एक फीचर ब्रांच (या समान) को संकलित या निर्माण नहीं करेंगे जो इतने भयानक हैं कि किसी को ऐसा करने से बचने के लिए मजबूर करना "जो कुछ भी वे करते हैं"? मुझे लगता है कि किसी भी वास्तव में भयानक प्रतिबद्धताओं को दूसरों द्वारा टाला जा सकता है, यही एकमात्र वास्तविक कारण है कि मैं उन्हें पहले स्थान पर कैसे बचाऊंगा (यह मानते हुए, कि कमिट जारी नहीं किए जा रहे हैं )।

— केनी एविट

"कोड है कि संकलन नहीं होगा में जाँच से बचने" केवल एक साझा कोड आधार / शाखा पर लागू होता है। वन-मैन प्रोजेक्ट या वन-मैन डेवलपमेंट ब्रांच पर, मेरा दावा है कि वीसी में सिर्फ बदलाव लाना ज्यादा जरूरी है ताकि आप सामान न खोएं।

— स्टीफन सी

@StephenC उदाहरण के लिए क्योंकि यह गिट-बाइसेक्ट जैसे उपकरणों को तोड़ता है। यदि कोड हर समय संकलित / चलाता है और आपको एक प्रतिगमन खोजने की आवश्यकता है यदि यह हर समय संकलित करता है तो आप केवल बाइनरी खोज कर सकते हैं (यह उल्लेख नहीं कि यदि कोड के बँट में प्रतिगमन है तो आप संकीर्णता के बजाय पढ़ने के लिए बड़े परिवर्तन के साथ छोड़ दिए जाते हैं। उसे नीचे करो)।

— मैकीज पाइचोटका

@MaciejPiechotka - ठीक है, जाहिर है अगर आपको अपनी निजी शाखाओं पर विशिष्ट उपकरणों का उपयोग करने की आवश्यकता है, और उन्हें उस कोड को संकलित करने की आवश्यकता है, तो ऐसा करें। लेकिन यह एक व्यक्ति-परियोजना / शाखा के लिए विशिष्ट नहीं है।

— स्टीफन सी

Answer 3

बार-बार छोटा, और सार्थक बनाने के लिए सबसे महत्वपूर्ण कारण कोड के इतिहास की समझ में सहायता करना है। विशेष रूप से, यह समझना बहुत मुश्किल है कि अगर समझने योग्य भिन्न उत्पन्न करना मुश्किल है तो कोड कैसे बदल गया है।

विकल्प 1 आपके द्वारा किए गए परिवर्तनों के इतिहास को रोकता है, लेकिन अन्यथा यह किसी भी समस्या का कारण नहीं होगा।

विकल्प 2 आपके द्वारा किए गए परिवर्तनों के इतिहास को संभवतः 1 विकल्प की तुलना में कुछ हद तक कम कर देता है, लेकिन यह स्वयं या दूसरों के लिए अन्य समस्याओं का कारण बन सकता है यदि वे मान लेते हैं या अन्यथा यह निष्कर्ष निकालते हैं कि कमिट अलग-अलग हैं, जैसे स्वतंत्र रूप से अन्य शाखाओं में विलय किया जा सकता है। जब तक एक मजबूत व्यावहारिक कारण नहीं है कि यह विकल्प 1 से अधिक क्यों पसंद किया जाता है, यह इसके मुकाबले कम आदर्श है।

विकल्प 3 सबसे अच्छा है, बाकी सभी समान हैं, लेकिन यदि आपने कहीं और वर्णित किया है, तो ऐसा करने के लिए "अत्यधिक" मात्रा की आवश्यकता होगी या अन्य महत्वपूर्ण लागतों को उठाना होगा, आपको उन लागतों का वजन अपेक्षित लाभ के मुकाबले करना होगा। क्लीनर बनाना।

आपके द्वारा प्रदान की गई जानकारी के आधार पर, मैं विकल्प 1 का विकल्प चुनूंगा। हो सकता है कि आपको अपने परिवर्तनों को करने के लिए संकेत देने के लिए सेटअप रिमाइंडर चाहिए।

प्रोटोटाइप और पुनर्लेखन

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

जब आप नए कोड का प्रोटोटाइप बना रहे होते हैं, तो जब भी आप अपने परिवर्तनों को सहेजना चाहते हैं, तो लगभग निश्चित रूप से एक शाखा में, लेकिन शायद एक अलग परियोजना में। या शायद पूरी तरह से संस्करण नियंत्रण के बाहर भी काम करते हैं। इसके बजाय आप विभिन्न परिकल्पनाओं या डिज़ाइनों पर विचार करने की व्यवहार्यता के बारे में साक्ष्य जुटाने पर ध्यान केंद्रित कर सकते हैं। मैं अक्सर विभिन्न टूल्स का उपयोग करके छोटे प्रोटोटाइप लिखता हूं, जैसे C # कोड के लिए Visual Studio के बजाय LINQPad।

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

Comments

अच्छा उत्तर; केनी आपके पास प्रोटोटाइप के बारे में अधिक विशिष्ट विवरण के साथ लिंक करने के लिए एक अच्छा लेख या अन्य ज्ञान का आधार है? प्रोटोटाइप का मेरा संस्करण "नोटबुक में स्केच या व्हाइटबोर्ड पर" है

— डुर्रोन 597

@ Durron597, मैं अपने सिर के ऊपर से किसी भी लिंक (यहां तक ​​कि देखने के लिए) के बारे में सोच भी नहीं सकता। मैंने पर्याप्त व्याख्या की हुई (और गतिशील रूप से संकलित) प्रोग्रामिंग भाषाओं के साथ खेला है जो मैंने सोचा भी नहीं था कि 'प्रोटोटाइपिंग' का विचार उपन्यास हो सकता है! और मैंने इतने सारे सी, सी ++ और जावा प्रोग्राम (बार-बार) फिर से लिखे हैं कि मुझे नहीं लगता था कि यह असामान्य भी हो सकता है, या कम से कम कुछ के लिए उपन्यास हो सकता है।

— केनी एविट

Answer 4

यद्यपि एकमात्र उचित उत्तर यह है कि ट्रंक को कभी नहीं तोड़ना चाहिए , लेकिन कुछ बार यह संभव नहीं है। उदाहरण के लिए, यदि आप बहुत अधिक (शायद एक विकल्प, या एक सुविधा, मुझे यकीन नहीं है) प्रतिबद्ध होने पर svn टूट सकता है। ऐसे विशेष मामलों में, बस टुकड़ों में जांच करें। चूंकि आप एकल प्रोग्रामर हैं, इसलिए यह किसी को परेशान करने वाला नहीं है।

इसलिए, मैं विकल्प 1 के लिए जाऊंगा। यदि संभव नहीं है, तो विकल्प 2।

विकल्प 3 को बहुत प्रयास की आवश्यकता होती है, और यह बस इसके लायक नहीं है।

Comments

या गैर-संकलन संस्करणों को "DOESN'T कंपाइल" के रूप में टैग करें

— शाफ़्ट सनकी

@ratchetfreak: मुझे लगता है कि SVN में "टैग" बहुत मदद नहीं करेगा, क्योंकि टैग ट्रंक पर "टिप्पणियों" के रूप में काम नहीं करते हैं।

— डॉक्टर ब्राउन

@DocBrown का मेरा मतलब था कि इसे कमिट मैसेज में जोड़ दूं

— शाफ़्ट फ्रीक

@ratchetfreak मैं इसे "PART X / N: ABC में जाँच

— DOESNT कम्पाइल

विकल्प 3 को बहुत प्रयास की आवश्यकता नहीं है। एक अन्य उत्तर बताता है कि यह कैसे जल्दी और आसानी से उपयोग करना है git add --patchऔर git stash। केवल पुरानी स्रोत नियंत्रण उपकरण और ज्ञान के कारण स्थिति कठिन लगती है।

— रॉन मैकनील

Answer 5

इसे छोटे कमिट में तोड़ने की कोशिश करें जो कि संभवत: संकलित नहीं होगी, क्योंकि फाइलों में कई सुधार, परिवर्तन, अतिरिक्त विधि के नाम आदि हैं।

जब मैंने खुद को एक समान स्थिति में पाया तो मैंने निम्नलिखित तकनीक का उपयोग किया:

1. केवल एक विशेष सुविधा के लिए प्रासंगिक कोड जोड़ें: git add --patch
2. अन्य सभी परिवर्तनों को रोकें: git stash save --keep-index
3. परीक्षण चलाएं / संकलन का प्रयास करें
4. अगर सब कुछ ठीक है, तो बदलाव करें अगर 1 पर न जाएं

मैं एसवीएन से परिचित नहीं हूं, इसलिए मुझे नहीं पता कि क्या यह आपकी विशिष्ट स्थिति पर लागू होता है, लेकिन आधार समान होना चाहिए - कोड के छोटे हिस्सों को अलग करना और उन्हें व्यक्तिगत रूप से परीक्षण करना।

Comments

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

— डुर्रोन 597

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

— joeytwiddle

Git के साथ आप स्वतंत्र रूप से अपने कमिट्स को मान्य करने के लिए कमिटमेंट और ब्रांच के बाद अंतःक्रियात्मक रूप से (-i) जोड़ सकते हैं।

— रिजेबोसच

Answer 6

विकल्प 4 के बारे में: अस्थायी स्थिति में अपने रेपो की वर्तमान स्थिति का बैक अप लें, अपने रेपो को उसकी मूल स्थिति में वापस लाएं, आपके द्वारा किए गए सभी परिवर्तनों की सूची बनाएं (आप अभी भी अस्थायी बैकअप देख सकते हैं), फिर मैन्युअल रूप से पुन: लागू करें (और संकलित करें) और परीक्षण!) उन्हें अलग करता है।

यह आसान होना चाहिए, क्योंकि आप पहले ही कोड लिख चुके हैं, यह केवल यह पता लगाना है कि आपके अस्थायी बैकअप से किन हिस्सों को कॉपी और पेस्ट करना है।

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

Comments

यह सिर्फ # 3 करने का एक तरीका है। शायद सबसे अच्छा तरीका है, सच है, लेकिन अभी भी काफी समय लगता है।

— डुर्रोन 597

जब मैंने एक बड़ी प्रतिबद्धता की थी, तब जोड़ने / हटाने / संदेश भेजने की 149 लाइनें थीं। ऐसा करने के लिए कम से कम आधा दिन है।

— ड्यूर्रोन 597

@ durron597 मैं असहमत हूं, मुझे लगता है कि यह # 3 से अलग है। 149 लाइनों के बारे में, आप एक स्वच्छ प्रतिबद्ध इतिहास को कितना महत्व देते हैं? क्या यह आधा दिन बिताने लायक है? वैसे भी, ऐसा नहीं है कि अन्य तरीकों से यह पता लगाने की आवश्यकता नहीं होगी कि कौन सी लाइन किस कमिट में होनी चाहिए, इसलिए आपको 149 लाइनों के रास्ते से गुजरना होगा। समय का अंतर छोटा होगा।

— शानदार

हे। मैं संस्करण नियंत्रण का उपयोग करने के लिए जानने के लिए पर्याप्त अनुभवी हूं, लेकिन इतना अनुभवी नहीं कि कभी भी उसने मेरे बट को बचाया हो :) इसलिए चीजों को करने के व्यावहारिक कारण अभी भी थोड़ा अकादमिक हैं, अगर आप जानते हैं कि मेरा क्या मतलब है।

— डुर्रोन 597

आपको अपने पूरे रेपो का बैकअप नहीं लेना है । आप "बैकअप" कमिट कर सकते हैं, फिर HEAD को वापस रोल कर सकते हैं git reset HEAD~। आपकी प्रतिबद्धता तब भी रहेगी git reflogजब आप तय करेंगे कि आपको बाद में इसकी आवश्यकता है। आप अपने "बैकअप" को एक नाम देने के लिए, रीसेट करने से पहले एक शाखा को बंद भी कर सकते हैं (और फिर काम करने वाली शाखा में वापस जाएँ)। यदि आपको इसकी आवश्यकता नहीं है, तो शाखा को बाद में हटा दें। संपादित करें: माफ करना एहसास नहीं था कि ओपी svn पर है!

— joeytwiddle

Answer 7

आप केवल प्रोग्रामर हैं; बस एक बड़े पैमाने पर जाँच करें कि आपने क्या किया महत्वपूर्ण बिट्स का विवरण।

क्या आपने जो किया उसके "भागों" को वापस करने की संभावना है? यदि नहीं, तो विकल्प 1 के साथ बिल्कुल आगे बढ़ें।

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

बाद में परियोजना में आने वाला एक प्रोग्रामर एक ऐसे संस्करण को वापस रोल करना नहीं चाहता है जो संकलन नहीं करता है। तो, IMHO, विकल्प 2 लूनसी है।

विकल्प 3 ऐसा टाइम सिंक लगता है, कि अगर मैं आपका बॉस था और आपको ऐसा करते हुए घंटों बर्बाद करते हुए देखा, तो आपके समय की कीमत क्या है, इस बारे में मैं आपसे थोड़ी बात करूँगा।

Iterate करने के लिए: अपने कोड में जाँच करके आप अपने मशीन पर विफलता के मामले में अपने बट को कवर / सहेज रहे हैं। एक आदमी टीम पर, बाकी सब कुछ, विंडो ड्रेसिंग है।

Comments

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

— Aaronaught

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

— Aaronaught

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

— NotMe

@Aaronaught मैं अपने आप को 3 महीने बाद जोड़ना चाहता हूं कि 'एक और प्रोग्रामर' का गठन कर सकते हैं।

— मिकीज पीचोटका

मुझे वास्तु परिवर्तन या अन्य "विनाशकारी" परिवर्तनों के लिए एक व्यवहार्य रणनीति के रूप में शाखा देने से भी असहमत होना है। यह सिर्फ मर्ज संघर्ष और बाद मर्ज कीड़े की एक दुःस्वप्न की ओर जाता है। लंबे समय में यह बहुत दूर है, छोटे, पिछड़े-संगत परिवर्तनों में प्रमुख परिवर्तन को तोड़ने का एक तरीका निकालने के लिए, या सबसे खराब स्थिति में, फाउलर, विनम्र और उनमें से बाकी कॉल शाखा का उपयोग करें एब्स्ट्रेक्शन द्वारा (जो वास्तव में एक शाखा नहीं है)। ये दोनों रणनीतियाँ छोटी और केंद्रित हैं।

— एरोनियट ने

Answer 8

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

हर कोई पूरी तरह से अटूट नियम है: कभी भी ऐसे कोड की जांच न करें जो निर्माण भी नहीं करते हैं, और गंभीरता से कोड में जांच से बचें जो काम नहीं करता है।

समाधान: अपना परिवर्तित कोड कॉपी करें, मूल बिंदु पर वापस जाएं। मूल कोड में एक समय में एक बदलाव को मर्ज करें, इसकी समीक्षा करें, इसका परीक्षण करें, इसकी जांच करें। आपके द्वारा वर्णित प्रोग्रामिंग विधि के साथ, आप उस तरह से कुछ गंभीर कीड़े खोजने के लिए बाध्य हैं।

यह खुद को अच्छी प्रोग्रामिंग आदतों को प्रशिक्षित करने का एक अच्छा तरीका भी है।

Comments

यह तार्किक रूप से Git- आधारित उत्तर के ऊपर ( git add --patchऔर git stash) के समान है और परिदृश्य का एक अच्छा उदाहरण है जिसे आधुनिक DVCS आसानी से संभाल सकता है लेकिन पुराने सिस्टम नहीं कर सकता।

— रॉन मैकनील

Answer 9

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

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

Comments

इससे पहले के 12 उत्तरों में जो कुछ पहले से पोस्ट किया गया था, उस पर कुछ भी जोड़कर नहीं देखा जा सकता है

— gnat

Answer 10

समस्या कमिट के बीच लंबे समय तक देरी में नहीं है, लेकिन इस तथ्य में कि आप कोड को बहुत अधिक समय तक असंगत स्थिति में रखते हैं। सबसे पहले 'लंबी' की आपकी परिभाषा क्या है? कुछ लोगों के लिए संक्रमणकालीन स्थिति के लिए 5 मिनट बहुत अधिक हैं, लेकिन कुछ दिनों तक अपने कोड को पॉलिश कर सकते हैं, यहां तक ​​कि संकलक को चलाने की कोशिश किए बिना।

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

कुछ परिवर्तनों के लिए परीक्षणों की आवश्यकता नहीं होती है। अधिक उपयुक्त के लिए चर का नाम बदलें, कोड को अलग फ़ंक्शन में स्थानांतरित करें, आदि ... आपको अपने कोड का बेहतर विचार मिलेगा। उसके बाद आप बड़े बदलाव कर सकते हैं। फिर, यदि संभव हो तो परीक्षण लिखने का प्रयास करें। अपने कोड को प्रबंधनीय बनाएं।

उसके बाद आप देखेंगे कि अगला बदलाव आपको "बहुत लंबा" नहीं लग रहा है (जो भी इसका मतलब है)।

Comments

उन्होंने कहा कि वह कोड को लंबे समय तक एकतरफा नहीं रख रहे थे। रेपो में कोड एक लंबे समय के लिए unmodified था - पुराना लेकिन फिर भी संकलन योग्य। उसकी कार्य प्रतिलिपि में कोड बार-बार अपडेट किया गया था लेकिन वह प्रतिबद्ध नहीं था। इस प्रश्न में कुछ भी नहीं बताया गया है कि उनके कोड को रिफैक्टिंग की आवश्यकता हो सकती है - "काउबॉय कोडिंग" यहां उनके एससीएम वर्कफ़्लो को संदर्भित करता है, वास्तविक कोड गुणवत्ता को नहीं

— ईडन आर्ये

@IdanArye मूल प्रश्न से ...Try to break it into smaller commits that likely won't compile...यदि कोई चीज़ आपके कोड को कम करने से रोक रही है तो यह पहले से ही एक अच्छा गाना है कि कोड को प्रबंधित करना मुश्किल है। "कमिट" आपके काम को जारी रखने के तरीकों में से एक है। हम अधिक चरम मामले के बारे में सोच सकते हैं - "अगर कुछ मुझे स्रोत फ़ाइल को बचाने से रोकता है"। तो यह क्या हो सकता है? मुझे लगता है कि यह आपके खुद के बदलाव का डर है। ऐसा क्यों हो सकता है? ... मुझे लगता है कि आप बिंदु मिल गया

— AlexT

मेरे लिए यह अधिक अच्छा लगता है, जो उसे करने से रोकता था वह केवल आलस्य था।

— इदं आर्ये

@IdanArye आप सभी मामलों में सही हैं। वह पर्याप्त TDD नहीं कर रहा है, जो एक अलग मुद्दा है।

— डुर्रोन 597

@AlexT एक परिदृश्य पर विचार करता है जहाँ आप दो बगों को ठीक करते हैं, और उनमें से एक को एक नए विकसित तरीके की आवश्यकता होती है। यदि आप ठीक से प्रतिबद्ध थे, तो आप एक बग को ठीक करते हैं, प्रतिबद्ध करते हैं, फिर दूसरे बग को ठीक करते हैं। यदि आप नहीं हैं, तो जब आप प्रतिबद्ध होते हैं, तो आपको या तो एक ही प्रतिबद्ध में दोनों बदलावों को शामिल करना होगा, या दूसरे बग के परिवर्तनों के साथ पहले बग को ठीक करना होगा, इसके अलावा प्रतिबद्ध संस्करण में नई विधि कॉल नहीं है और इसलिए संकलन नहीं है।

— दुर्रोन 597