मैं इस नियम से सहमत नहीं हूं और मैसन व्हीलर ने जो कहा उससे मैं सहमत हूं। मैं कुछ विचार जोड़ना चाहूंगा।
मैं हर बार प्रतिबद्ध होने के लिए एक सार्थक बदलाव करने की कोशिश करता हूं: यह एक दिन में कई बार हो सकता है अगर मैं कई छोटे कीड़े ठीक करूं, या सप्ताह में एक बार अगर मैं सॉफ्टवेयर के एक बड़े टुकड़े पर काम कर रहा हूं जो कि बाकी हिस्सों द्वारा उपयोग नहीं किया जा सकता है किसी भी सार्थक तरीके से कोड जब तक यह एक सुसंगत स्थिति तक नहीं पहुंचता।
इसके अलावा, मैं व्याख्या करने के रूप में एक सार्थक संशोधन प्रकाशित करने कि कोड बेस के लिए नई कार्यक्षमता योगदान देता है। मुझे लगता है कि किसी को कमिट करने से पहले कोड को साफ करने की कोशिश करनी चाहिए ताकि अन्य डेवलपर्स संशोधन इतिहास का अर्थ और बदलाव के उद्देश्य को समझ सकें। अन्य डेवलपर्स इतिहास में कम बदलाव देखते हैं, बेहतर: जब मैं संशोधन इतिहास को देखता हूं तो मैं वेतन वृद्धि देखना चाहता हूं जो कुछ सार्थक कार्यक्षमता जोड़ते हैं; मुझे प्रत्येक छोटे विचार में कोई दिलचस्पी नहीं है जो प्रत्येक डेवलपर के पास था और समाधान तक पहुंचने से पहले वह कोशिश करना चाहता था।
इसके अलावा, मुझे नहीं लगता कि एसवीएन सर्वर (या जो भी संस्करण नियंत्रण प्रणाली) को बैकअप सुविधा के रूप में उपयोग करना एक अच्छा विचार है, जिसके लिए कोड का वर्तमान स्नैपशॉट प्रतिबद्ध है (बशर्ते कि यह संकलन): आप एक यूएसबी स्टिक का उपयोग कर सकते हैं या बाहरी USB- ड्राइव या एक नेटवर्क डिस्क को आपके वर्तमान कोड को मिरर करने के लिए ताकि आपका कंप्यूटर टूट जाए तो यह खो न जाए। रिविजन कंट्रोल और डेटा बैकअप दो अलग-अलग चीजें हैं। एक संशोधन प्रकाशित करना
आपके कोड के स्नैपशॉट को सहेजने के समान नहीं है ।
अंत में, मुझे लगता है कि यह अब और फिर हर किसी को प्रतिबद्ध करने के लिए एक समस्या नहीं होनी चाहिए (यानी केवल जब कोई वास्तव में कोड की वर्तमान स्थिति से संतुष्ट हो) और मर्ज संघर्ष से बचने के लिए अक्सर (भी) कमिट करने का अच्छा औचित्य नहीं है। कई मर्ज टकराव तब होते हैं जब विभिन्न लोग एक ही समय पर एक ही फाइल पर काम करते हैं, जो एक बुरा अभ्यास है (उदाहरण के लिए इस लेख को देखें , बिंदु 7)। स्पष्ट अंतर और संभव के रूप में कुछ निर्भरता के साथ मॉड्यूल में एक परियोजना को विभाजित करके और डेवलपर्स के काम में समन्वय करके मर्ज संघर्ष को कम किया जाना चाहिए ताकि कोड जितना संभव हो उतना ओवरलैप पर काम करें।
बस मेरे 2 सेंट।
संपादित करें
समय से पहले आने का एक और कारण मेरे दिमाग में यह आया कि एक (बहुत) छोटी गाड़ी के संस्करण का परीक्षण नहीं किया जा सकता है। यदि आप ट्रंक पर कर रहे हैं और आपकी टेस्ट टीम हर दिन परीक्षण कर रही है, तो उनके पास कुछ घंटों (या एक दिन के लिए) का कोई परीक्षण योग्य संस्करण नहीं हो सकता है। यहां तक कि अगर आप बग को ठीक करने की कोशिश नहीं करते हैं और केवल अपने परिवर्तनों को वापस करते हैं, तो एक पुनर्निर्माण में कुछ घंटों का समय लग सकता है। अपनी टीम में काम करने वाले पांच परीक्षकों के साथ, आपने निष्क्रियता के कारण टीम के समय के 5 x 2 = 10 घंटे बर्बाद कर दिए हैं। यह मेरे साथ एक बार हुआ था इसलिए मैं वास्तव में जितनी जल्दी हो सके प्रतिबद्ध के नाम पर समय से पहले से बचने की कोशिश करता हूं ।