क्या अस्थायी कोड को संस्करण नियंत्रण के तहत रखा जाना चाहिए और कैसे?

Question

यहाँ अस्थायी / स्थानीय कोड के कुछ उदाहरण दिए गए हैं। यह कोडबेस के साथ काम करने के लिए आवश्यक है, लेकिन इसका हिस्सा बनना हानिकारक होगा:

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

मैंने उन लोगों को एक कमिट में रखने की कोशिश की है कि मैं हमेशा रेपो को धक्का देने से पहले शीर्ष पर पहुंचता हूं और फिर धक्का देता हूं HEAD~। यह काफी असुविधाजनक है और यह svn के साथ काम नहीं करता है। स्ट्रैस मुझे और भी डराता है - "क्या मुझे धक्का देने के बाद पॉप करना याद था ??"।

कोड को संस्करण नियंत्रण से बाहर रखने से अप्रिय शोर का सामना करना पड़ता है, हर बार एक कमिट इकट्ठा हो रहा है और यह गलती से किसी ह्रदय शाम को एक कमिट में पेश किया जा सकता है।

ऐसे थ्रो-दूर कोड के लिए क्या एक समाधान होगा?

Comments

क्या इस अस्थायी कोड को अपनी अस्थायी उपयोग अवधि के दौरान मूल परियोजना से अद्यतन करने की आवश्यकता होगी?

— जेफ

@ जेफ़ो, यकीन नहीं होता तो मैं तुम्हें समझूंगा। गंदे स्निपेट्स छोटे और शायद ही कभी विकास के तहत कोड के साथ टकराव होते हैं। हालांकि, @ ब्लरफ्ल, उनके लिए मुख्यधारा में शामिल होना बहुत खतरनाक है। एक कल्पना कीजिए return 7में trunkशुक्रवार की शाम, गर्मियों में गर्मी में एक घटिया मर्ज के बाद।

— वोरैक

@ वोरैक - यही कोड समीक्षा और परीक्षण के लिए है! मैं आपको उस कोड से बहुत खराब दिखा सकता हूं - जो पहली नज़र में अच्छा लगने के बावजूद काम नहीं करता। Return 7.. अगर केवल वे सभी इतने स्पष्ट थे!

— gbjbaanb

@ वोरैक: यह किसी भी चीज़ की तुलना में अधिक दार्शनिक टिप्पणी थी।

— ब्लरफुल

क्या यह बताने का कोई तरीका है कि आप किस माहौल में हैं? उदाहरण के लिए, आप इसे कोड निष्पादित करने के लिए सेट कर सकते हैं यदि यह पता लगाता है कि आप देव परिवेश में हैं, लेकिन वैल / प्रोडक्ट में नहीं। इस तरह आपको कमिट करते समय प्लेसहोल्डर कोड को लगातार जोड़ना / निकालना नहीं पड़ता है।

— सागियो जूल

Answer 1

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

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

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

पुनश्च। वास्तव में अस्थायी फ़ाइलें (जैसे .obj या निर्माण कलाकृतियों) का आपके SCM में कोई स्थान नहीं है। ये ऐसी चीजें हैं जिनका किसी के लिए कोई मूल्य नहीं है। आप बता सकते हैं कि वे क्या हैं - यदि आप उन्हें हटाते हैं तो आप बुरा नहीं मानते हैं, या यहां तक ​​कि वे चले गए हैं।

Comments

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

— कैमरून मैकके

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

— InformedA

मैं एक बड़ा पोस्टर छपवाने जा रहा हूं जिसमें कहा गया है "ALL CODE IS TEMPORARY" और इसे दीवार पर चिपका दें। शायद कॉमिक सैंस में।

— बॉब टवे

@MattThrower एक बुलबुला बोली में, क्लीपी के होंठों से आ रहा है?

— gbjbaanb

गैर-संकलित कोड या कोड जो संकलन नहीं करता है, हालांकि संस्करण नियंत्रण के लिए प्रतिबद्ध नहीं होना चाहिए।

— ट्यूलेंस कोर्डोवा

Answer 2

प्रोजेक्ट फाइलें। वर्तमान पीसी पर लेआउट को प्रतिबिंबित करने के लिए पथों को संपादित करने की आवश्यकता हो सकती है।

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

Makefiles। उदाहरण के लिए अनुकूलन को डीबगिंग के दौरान बंद करने की आवश्यकता हो सकती है, लेकिन CI सर्वर के लिए नहीं।

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

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

क्या आप एक परीक्षण नहीं लिख सकते हैं जो संदिग्ध विफलता के मामले को प्रेरित करता है?

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

Comments

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

— वोरैक

@Vorac, मैं तोड़फोड़ हुक में देखूँगा जो आपको स्क्रिप्टिंग करते समय करते हैं। एक स्क्रिप्ट लिखना संभव होना चाहिए जो एक मर्ज को अस्वीकार करता है अगर इसमें XXX या ऐसा कुछ है।

— विंस्टन इर्वर्ट

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

— leokhorn

Answer 3

संस्करण नियंत्रण में कोड और कॉन्फ़िगरेशन होना चाहिए जो एप्लिकेशन के निर्माण के लिए आवश्यक है।

इस का मतलब है कि:

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

• स्थानीय फाइलें जो एक विशेष मशीन के लिए उपयुक्त हैं, उन्हें एक शाखा में रखा जा सकता है।

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

  दूसरी ओर, फ़ाइल संरचना के साथ सावधान रहें: स्थानीय कॉन्फ़िगरेशन ठीक है, जब तक कि यह भारी न हो जाए, और आपको परियोजना में भाग लेने वाले प्रत्येक 42 डेवलपर्स की हर फ़ाइल में एक एकल परिवर्तन करने के लिए मजबूर करता है।

  मशीनों के बीच विशिष्टताओं को दूर करने के अवसर के लिए देखें। इसका मतलब हो सकता है:

  • डेवलपर्स मशीनों पर स्थानीय उदाहरणों को बदलने के लिए एक देव SQL सर्वर तक पहुंच प्रदान करना,

  • सार्वजनिक पैकेज के लिए पीपीआई या एनपीएम जैसी पैकेज वितरण सेवाओं का उपयोग करना और इन-हाउस पैकेज के लिए उनके निजी समकक्षों,

  • टीम के सदस्यों से सॉफ्टवेयर के एक ही संस्करण को स्थापित करने के लिए कहें,

  • जितना संभव हो सके सॉफ्टवेयर अपडेट करें,

  • या एक क्लिक में मशीन पर ओएस और आवश्यक सॉफ़्टवेयर को तैनात करना संभव है (इसके अलावा प्रत्येक डेवलपर के लिए अपना पसंदीदा विम बनाम एमएसीएस, क्रोम बनाम फ़ायरफ़ॉक्स, आदि स्थापित करने का समय)

इसलिए:

प्रोजेक्ट फाइलें। वर्तमान पीसी पर लेआउट को प्रतिबिंबित करने के लिए पथों को संपादित करने की आवश्यकता हो सकती है।

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

उदाहरण:

विज़ुअल स्टूडियो के साथ बनाई गई परियोजना में, आप पा सकते हैं:

• फाइलें खुद। रिश्तेदार होने के पथ, इससे कोई फर्क नहीं पड़ता कि मेरी मशीन पर, परियोजना स्थित है, H:\Development\Hello World Project\जबकि टीम के अन्य सदस्यों ने परियोजना की जांच की C:\Work\HelloWorld\।

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

  ध्यान दें कि निजी नूगेट में इन-हाउस पुस्तकालयों को रखना महत्वपूर्ण है। एक साझा फ़ोल्डर में संग्रहीत पुस्तकालयों का एक समूह होने या एक टीम में ई-मेल द्वारा भेजे जाने से अराजकता और अवसादग्रस्तता सीआई सर्वर की ओर जाता है।

• सेटिंग्स। यह महत्वपूर्ण है कि टीम समान सेटिंग्स साझा करे। यदि टीम का आधा हिस्सा चेतावनियों को गलत मानता है और आधी टीम चेतावनियों को मानती है, तो टीम के पहले हिस्से के सदस्य डेवलपर्स द्वारा टीम के दूसरे भाग से उत्पन्न चेतावनियों को हटाने में अपना समय व्यतीत करेंगे।

• उपयोगिताओं से संबंधित सेटिंग्स। वे मुश्किल हैं, क्योंकि टीम के कुछ सदस्यों ने कुछ उपयोगिताओं को स्थापित किया हो सकता है, जबकि अन्य ने नहीं।

  यह समान टूलसेट स्थापित करने के लिए दृढ़ता से अनुशंसित है। यदि कुछ प्रोग्रामर स्टाइलकॉप का उपयोग करना चाहते हैं, लेकिन अन्य नहीं करते हैं, तो टीम को काम नहीं मिलेगा। यदि कुछ कोड कॉन्ट्रैक्ट का उपयोग करते हैं लेकिन अन्य नहीं करते हैं, तो उनके पास समान मुद्दे होंगे।

Makefiles। उदाहरण के लिए अनुकूलन को डीबगिंग के दौरान बंद करने की आवश्यकता हो सकती है, लेकिन CI सर्वर के लिए नहीं।

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

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

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

जैसा कि आप इसका वर्णन करते हैं, आपको एक परीक्षण लिखना चाहिए। उदाहरण के लिए, यदि आप यह सुनिश्चित करना चाहते हैं कि:

class TemperatureConverter
{
    public int CelsiusToFahrenheit(int temperature)
    {
        ...
    }
}

एक अपवाद फेंकता है जब निरंतर temperatureसे हीन होता AbsoluteZeroहै, आपको कोड के साथ नहीं खेलना चाहिए। इसके बजाय, एक इकाई परीक्षण बनाएं जो होगा:

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

Comments

दुर्भाग्य से मुझे लेखन परीक्षण का अनुभव नहीं है। वर्तमान प्लेटफ़ॉर्म में ARM cpu शामिल है, USB कमांड के जवाब में कुछ हार्डवेयर को कॉन्फ़िगर करता है। हार्डवेयर से सीपीयू तक कोई प्रतिक्रिया नहीं है।

— वोरैक

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

— सुपरकैट

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

— डेविड के

VS के साथ, आपको कभी-कभी यह सुनिश्चित करने के लिए ध्यान रखने की ज़रूरत है कि आपके पास रास्ते में आने-जाने के लिए पूर्ण रास्ते नहीं हैं। मैं जीतने के लिए अपग्रेड करते समय कुछ समस्याओं से अधिक भाग गया हूं जब win64 में अपग्रेड हो रहा है और 3rd पार्टी प्लेटफॉर्म के लिए पुस्तकालयों से C:\Program Files\...जाना हैC:\Program Files (x86)\...

— डैन नीली

@ डानेली: यही कारण है कि तीसरे पक्ष के पुस्तकालयों को नुगेट द्वारा नियंत्रित किया जाना चाहिए।

— आर्सेनी मूरज़ेंको

Answer 4

@@परीक्षण उद्देश्यों के लिए, कुछ भी तैयार नहीं होने का संकेत देने के लिए हम कोड में टिप्पणियों का उपयोग करते हैं ।

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

हम @@बीटा परीक्षण आदि के अंतिम चरणों में प्रवेश करने से पहले किसी भी 'बचे हुए' को रोकने के लिए एक वैश्विक खोज करते हैं ।

कि अनुशासन का उपयोग करना, मैं करने के लिए कोई कारण नहीं देख नहीं बस के लिए प्रतिबद्ध। इस तरह, हमारे पास अलग-अलग शाखाएँ नहीं हैं और केवल एक अतिरिक्त 'प्रोटोकॉल' का पालन करना है।

---

अतिरिक्त लाभ के रूप में, ये टूडू (आमतौर पर छोटी चीजें) हमेशा कोड में होते हैं। उन पर काम करने वाले डेवलपर जल्दी से उन पर जा सकते हैं, और अलग-अलग सूची रखने की कोई आवश्यकता नहीं है।
आप जानते हैं कि विकास कैसे होता है: आप एक जगह काम कर रहे हैं, लेकिन आप लगातार अपने दिमाग को एक स्टैक के रूप में उपयोग कर रहे हैं (' जब मैं यहां काम कर रहा हूं तो मुझे उस पर बदलाव करना चाहिए ')। बस एक त्वरित @@टिप्पणी नीचे संक्षेपण ढेर अतिप्रवाह रोकता है।

मैं @@nameउन मुद्दों को इंगित करने के लिए भी उपयोग करता हूं जिन्हें मुझे 'नाम' के साथ चर्चा करने की आवश्यकता है।

Answer 5

2 हैमस्टर समाधान:

• आप HAMSTER जैसे कुछ असामान्य कीवर्ड के लिए अपने कोड की जांच करने के लिए पूर्व-प्रतिबद्ध हुक का उपयोग कर सकते हैं। बस उन लोगों को कोड न दें जो HAMSTERed हो चुके हैं और जब भी आप गंदे हैक करते हैं तो इसका उपयोग करें।

• C में उदाहरण के लिए एक अन्य विकल्प #ifdef HAMSTER का उपयोग करना है, फिर कोड केवल आपकी मशीन पर चलेगा जहाँ आपके पास एक संकलनकर्ता HAMSTER है।

Answer 6

हमने मौजूदा बायनेरिज़ के निर्माण और परीक्षण के लिए स्रोत नियंत्रण के तहत सब कुछ डाल दिया और यह समझने की कोशिश की कि चीजों को किस तरह से डिज़ाइन / कार्यान्वित / परीक्षण किया गया है।

वह भी स्पाइक्स के लिए रखती है http://www.extremeprogramming.org/rules/spike.html , जैसा आपने वर्णित किया है; हम बस उन्हें एक अलग उप-वृक्ष में होस्ट करते हैं।

Answer 7

यहां कई समाधान हैं जो मैं कभी-कभी विभिन्न परिस्थितियों में खुद का उपयोग करता हूं, और जब आप अपने स्वयं के वर्कफ़्लो पर लागू होते हैं तो आप मददगार हो सकते हैं:

1. हल्के शाखाएं जिन्हें स्क्वीज किया जा सकता है।

   इस पर गिट महान है। एक शाखा पर हैक करें, बहुत सारे कमिट करें, और फिर शोर को संपादित करने के लिए अपने इतिहास को रिबेट या स्क्वैश करें।

2. अपने SCM के शीर्ष पर एक पैच कतार का उपयोग करें।

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

3. छोटे प्रयोगों के लिए आरसीएस को "आउट-ऑफ-बैंड" एससीएम के रूप में उपयोग करें ।

   कभी-कभी आप इतिहास को बाद में साफ करने के लिए बिना किसी डिस्पोजेबल तरीके से प्रगति में एक फ़ाइल की जांच करना चाहते हैं। मैं आमतौर पर Git या SVN के अंदर इसके लिए RCS का उपयोग करता हूं। मैं Git को RCS कलाकृतियों को अनदेखा करने के लिए कहता हूं, RCS में प्रगति में मेरे काम की जांच करता हूं, और जब मुझे परिणाम पसंद आते हैं तो मैं बस *,vफाइलों या पूरे आरसीएस निर्देशिका को टॉस करता हूं । git clean -fdxजब तक आप अपने "वास्तविक" एससीएम के लिए अपना काम नहीं करते, या आप इसे पछतावा नहीं करेंगे, तब तक या उसके समान न चलें ।

4. नाम रखा गया है।

   एक और गिट-इस्म, लेकिन काम: git stash save --include-untracked <some-cool-title>एक चुटकी में उपयोगी हो सकता है। तुम्हें पता है, बचा सकते हैं पॉप, और इस तरह से प्रगति में काम लागू होते हैं, और के माध्यम से अपने विभिन्न चौकियों देखने git stash listया git reflog --all। अन्य SCM में समान विशेषताएं हो सकती हैं, लेकिन आपका माइलेज इस एक के साथ बहुत भिन्न हो सकता है।

Answer 8

उस अस्थायी कोड में से कुछ वास्तव में अनुचित निर्माण / परीक्षण / विकास पद्धति की अभिव्यक्ति है, और उम्मीद है कि उनका अस्तित्व भविष्य में सुधार के लिए प्रेरित करेगा।

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

संस्करण नियंत्रण आपको मदद करने के लिए माना जाता है , और अधिक बार नहीं कि मैं जिस तरह से गलतियों (या शायद कम-से-सहज ज्ञान युक्त निर्णय) से अंतर्दृष्टि की सराहना करता हूं अतीत में किए गए थे, और वर्तमान के लिए अधिक सूचित निर्णय लेते हैं।

Answer 9

मुझे विश्वास है कि कुछ प्रणालियाँ TODO को एक टिप्पणी में देखकर चेतावनी देंगी

// TODO: remove this hack.

यह सब हो सकता है यदि आप अपने विकास के वातावरण के कुछ हिस्से में एक प्रासंगिक विकल्प पा सकते हैं, या बस अपने बिल्डफाइल में कुछ प्रकार के grep कमांड को चिपका सकते हैं। यह संभव भी हो सकता है कि // HACKकिसी मनमाने तार को उठाया जाए।

यह आपके कोड को एक विशेष तरीके से व्यवस्थित करने की तुलना में सरल है और उम्मीद करता है कि लोग इसका उपयोग नहीं करना याद रखेंगे। यह @gbjbaanb की सलाह का पालन करने के लिए सुरक्षित बनाता है (यदि आप यह सुनिश्चित कर सकते हैं कि हर कोई चेतावनी देख रहा है!)।

आप जो कुछ भी चाहते हैं, उसे एक दिन रोक दें क्योंकि आप यह देखना चाहते हैं कि यह क्या था, और वे दिन हैं जिन्हें आप महसूस करते हैं कि आपका एससीएम वास्तव में क्या है।

Answer 10

सोर्स कंट्रोल में कोड डालना कभी भी हानिकारक नहीं होता है।

आपके द्वारा उल्लिखित हर एक आइटम स्रोत नियंत्रण में होना चाहिए।