कब करें कोड?

Question

किसी प्रोजेक्ट पर काम करते समय, कुछ हफ्तों / महीनों / वर्षों की लंबी अवधि के लिए एक ही दिन में या बिट द्वारा कोड को काफी तेजी से विकसित किया जा सकता है। जैसा कि कोड कमिट्स को प्रोजेक्ट डेवलपमेंट के एक उपाय के रूप में माना जा रहा है, इसका वास्तव में मतलब नहीं है कि इसमें कम प्रॉजेक्ट वाले प्रोजेक्ट की तुलना में अधिक कोड लिखे गए हैं।

तो सवाल यह है कि वास्तव में रिपॉजिटरी के लिए एक कमिट कैसे करें ताकि कमिट उचित हो?

एक ऐड-ऑन के रूप में: क्या किसी परियोजना के विकास को उसके कमिट के आधार पर मापना सही अभ्यास है?

Comments

ज्यादातर चीजें जो आसानी से परिमाणी होती हैं, वे खराब मेट्रिक्स होती हैं, क्योंकि वे विशिष्ट माप के खिलाफ अच्छा प्रदर्शन करने के लिए ओवरसाइम्प्लीफाइड होती हैं या आसानी से प्राप्त की जा सकती हैं।

— अनहेल्स्लेमर

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

Answer 1

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

Comments

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

— एडवर्ड स्ट्रेंज

Answer 2

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

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

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

ऐड-ऑन के लिए: कृपया, कृपया ऐसा न करें। कोड की लाइनें, कमिट्स की संख्या, पाए जाने वाले कीड़े की संख्या / हल, आदि, सभी गुणवत्ता या मात्रा की बहुत खराब माप हैं।

Comments

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

— जूहा अनटाइनन

हां, लेकिन कुछ हद तक, क्योंकि (मूल उत्तर देखें) आप सीधे किसी को परेशान नहीं करेंगे। प्रश्न में SCM के आधार पर, आमतौर पर अपस्ट्रीम को मर्ज करने से पहले अपने प्रतिबद्ध इतिहास को साफ करने के लिए अच्छा अभ्यास माना जाता है (उदाहरण के लिए git rebase -i)।

— tdammers

Answer 3

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

गैर-वितरित वीसीएस (जैसे। एसवीएन) के लिए, एक ही तर्क लागू होता है, स्थानीय भंडार के बजाय निजी शाखा का उपयोग करते हैं, बजाय धक्का - मुख्य शाखा में विलय कर देते हैं।

Comments

+1 अचंभित यह अधिक उत्कीर्ण नहीं किया गया था। यह मेरा पहला विचार था - डीवीसीएस या वीकेएस

— माइकल डुरंट

Answer 4

आपको जल्दी और अक्सर कमिट करना चाहिए।

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

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

आप अपने उपयोगकर्ताओं को दिए गए मूल्य के आधार पर किसी उत्पाद के विकास को मापते हैं। कोई अन्य सटीक माप नहीं है।

Comments

+1। जब आप BDD-As-If-You-Mean-It, Refactor Till You Drop, Atomic Coding और एक अत्यधिक अभिव्यंजक भाषा का संयोजन करते हैं, तो 90 सेकंड का समय बिना किसी कमिटमेंट के जाने में लंबा समय हो सकता है ।

— जोर्ग डब्ल्यू मित्तग

Answer 5

कमिट किसी भी संस्करण नियंत्रित डेटा / कोड के निर्माण खंड हैं। प्रत्येक कमिट को निम्नलिखित में से एक करना चाहिए:

• डेटा या फ़ंक्शन का एक नया टुकड़ा जोड़ें
• एक या अधिक बग को ठीक करें (यदि संभव हो तो प्रत्येक फिक्स के लिए एक कमिट) जहां फिक्स हो सकता है:
  • प्रदर्शन में सुधार
  • गलत कोड व्यवहार को ठीक करना
  • टंकण त्रुटियों को दूर करना
• शब्दार्थ को बदले बिना कोड या डेटा को फिर से बनाना। यह भी शामिल है:
  • मूल के समान व्यवहार करने वाला कोड फिर से लिखना
  • एक अलग प्रारूप में डेटा का प्रतिनिधित्व बदलना
  • प्रोजेक्ट के फ़ॉर्मेटिंग दिशानिर्देशों को पूरा करने के लिए कोड या डेटा को फ़ॉर्मेट करना
• किसी अन्य शाखा से परिवर्तन (या तो अपस्ट्रीम / डाउनस्ट्रीम)

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

यदि हंगामा करने वाले उपरोक्त नियम का पालन करते हैं, तो यह तुच्छ हो जाता है:

• बिना किसी साइड-इफेक्ट के किसी विशेष परिवर्तन को वापस लाएं
• कोड स्वरूपण परिवर्तनों से कोड परिवर्तन के व्यवहार को पहचानें
• अधिकांश संघर्षों से बचने के लिए विभिन्न शाखाओं के बीच विलय करें
• अन्य डेवलपर्स के साथ सहयोग करें जो आपके परिवर्तन को आसानी से खींच सकते हैं

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

Comments

मुझे लगता है कि यह उत्तर स्वीकृत उत्तर होना चाहिए, लेकिन शायद प्रश्नकर्ता एक सरल स्पष्टीकरण की तलाश में था :)

— बेहन रसूली

Answer 6

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

और आपके ऐड-ऑन सवालों के जवाब देने के लिए - नहीं !! माप जहां परियोजना को कभी भी कमिट की संख्या से निर्धारित नहीं किया जाना चाहिए ... कौन जानता है कि वास्तव में क्या प्रतिबद्ध है? क्या इसका सफल परीक्षण किया गया है या यहां तक ​​कि इकाई का भी परीक्षण किया गया है। सिर्फ इसलिए कि यह प्रतिबद्ध है - इसका मतलब यह नहीं है कि यह उत्पादन के लिए तैयार है।

Comments

यह सच होगा यदि आप ट्रंक के लिए प्रतिबद्ध थे, लेकिन यदि आप एक सुविधा शाखा या एक निजी शाखा के लिए प्रतिबद्ध थे, तो एकीकरण के लिए तैयार होने की कोई आवश्यकता नहीं है।

— नील बटरवर्थ

@ नील बटरवर्थ: ... जब तक कि आपके कोड पर कुछ निर्भरता वाले एक ही शाखा पर अन्य डेवलपर्स काम नहीं कर रहे हैं।

— FrustratedWithFormsDesigner

@ स्वीकृत इस मामले में यह निश्चित रूप से अनिवार्य होना चाहिए, लेकिन मैं यह नहीं देखता कि इसे एकीकरण और सिस्टम परीक्षण के लिए तैयार होना चाहिए।

— नील बटरवर्थ

वितरित और केंद्रीकृत vcs के बीच यहां दिलचस्प द्विभाजन। वितरित vcs के साथ यह एक चिंता का विषय नहीं होगा क्योंकि आप स्थानीय स्तर पर शाखाओं की सुविधा के लिए प्रतिबद्ध हो सकते हैं और किसी अन्य देव के रास्ते से बाहर रह सकते हैं।

— जॉर्ज मौअर

@ जॉर्ज - यह एक झूठा द्वैतवाद है। वास्तविक डाइकोटॉमी निजी (प्रति डेवलपर) शाखाओं, या सार्वजनिक (कई डेवलपर्स द्वारा शेयर) के उपयोग के बीच है। यह ऑर्थोगोनल है कि क्या आप वितरित वीसीएस का एक केंद्रीकृत उपयोग कर रहे हैं (हालांकि, डीवीसीएस निजी शाखाओं को प्रोत्साहित करते हैं, क्योंकि शाखाएं तब तक निजी होती हैं जब तक आप उन्हें प्रकाशित नहीं करते)।

— स्टीफन सी। स्टील

Answer 7

एक ऐड-ऑन के रूप में: क्या किसी परियोजना के विकास को उसके कमिट के आधार पर मापना सही अभ्यास है?

नहीं, एक दैनिक डब्ल्यूटीएफ था था कि क्यों एक भयावह विचार है।

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

लेकिन कभी यह चेक न करें कि क्या यह संकलन नहीं है। मुझे पता है कि यह वास्तव में जोर से कहने के लिए एक बेवकूफ चीज की तरह लगता है, लेकिन मुझे इसे पहले लोगों को समझाना पड़ा है।

Comments

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

— रे

@ रे - मेरे अंतिम स्थान पर, लोट्टो फंड में जुर्माना चला गया। काश, हमने इसे इस बुरी आदत से कभी नहीं उबारा। : पी

— तन्य

Answer 8

जब कोड तैयार हो, तो कोड के अन्य उपयोगकर्ताओं के साथ साझा करने के लिए तैयार रहें - जब यह अपेक्षाकृत स्थिर, सुरक्षित और ठीक से परीक्षण किया गया हो।

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

Comments

याद रखें कि वितरित सिस्टम के साथ, कमिट! = शेयर करें। जब आप कुछ साझा करने के लिए तैयार हों तो आपको धक्का देना चाहिए ।

— रीन हेनरिच्स

@ हेन हेनरिच: अच्छा बिंदु, हालांकि काम पर यहां स्रोत नियंत्रण में वह कार्यक्षमता नहीं है (कम से कम जहां तक ​​मुझे पता है)। जब कुछ किया जाता है, तो परियोजना पर बाकी सभी लोग इसे देख सकते हैं और फिर से देख सकते हैं (और वे आमतौर पर करते हैं, कभी-कभी आँख बंद करके)।

— FrustratedWithFormsDesigner

जो एक संकेत हो सकता है कि आप बेहतर उपकरणों से लाभान्वित हो सकते हैं। कुछ भी जो लगातार आने से रोकता है, एक अनावश्यक बाधा है।

— रीन हेनरिच्स

@ हेन हेनरिच: मैं बहस नहीं करूँगा कि !!

— FrustratedWithFormsDesigner

Answer 9

जैसे ही संबंधित कार्य किया जाता है । एक कार्य एक उपयोगकर्ता कहानी का एक हिस्सा है ।

एक कार्य किया जाता है जब:

• इसी इकाई परीक्षण passe,
• कोड ठीक से प्रलेखित है और
• कोड शुरू किया गया है।

आप की एक अलग परिभाषा हो सकती है ।

मुझे कमिट की संख्या को मापने में मूल्य नहीं दिखता है। हालांकि, यदि आप किसी को उसी उपयोगकर्ता कहानी (या बदतर, कहानियों) पर लंबे समय तक काम करते देखते हैं, तो यह एक गंध है।

Answer 10

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

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

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

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

यहां बताया गया है कि यह Git के साथ कैसे काम करता है, लेकिन प्रिंसिपल किसी भी संस्करण नियंत्रण पर लागू होता है।

Comments

यह 10 पूर्व उत्तर में बनाए गए बिंदुओं पर पर्याप्त रूप से कुछ भी नहीं बताता और समझा नहीं जाता है। इसके अलावा, अंतिम पैराग्राफ git-specific फीचर को संदर्भित करता है जबकि प्रश्न git के बारे में नहीं प्रतीत होता है

— gnat

बिसेसिंग विशिष्ट नहीं है। यह किसी भी प्रकार के संस्करण नियंत्रण के साथ किया जा सकता है, यह सिर्फ एक उदाहरण था जैसा कि मुझे पता है कि Git ने इसे बनाया है।

— जैस्पर केंस

Answer 11

कब:

• यह बनाता है (हमेशा)
• इकाई परीक्षण पास
• यह काम करता है (जब तक कि इसे "प्रगति में काम" के रूप में स्पष्ट रूप से चिह्नित नहीं किया जाता है)
• कोड की स्थिति को बचाने के लाभों ने परीक्षणों को चलाने, एक अच्छे प्रतिबद्ध संदेश की सोच और प्रतिबद्ध प्रक्रिया के दौरान किसी भी मर्ज संघर्ष को हल करने की परेशानी को कम कर दिया

Comments

इस के लिए upvoted हमारा सबसे अच्छा अभ्यास है।

— jersoft