संस्करण नियंत्रण कब बहुत बड़ा होता है? [बन्द है]

Question

मैंने कई स्थानों पर सुना है "बड़े कमिट मत करो" लेकिन मैंने वास्तव में कभी भी "बड़े" कमिट को नहीं समझा है। क्या यह बड़ा है अगर आप फ़ाइलों का एक गुच्छा पर काम करते हैं भले ही संबंधित हो? किसी प्रोजेक्ट के कितने हिस्सों पर आपको एक बार काम करना चाहिए?

मेरे लिए, मुझे "छोटे कमिट" बनाने की कोशिश करने में परेशानी होती है क्योंकि मैं भूल जाता हूं या ऐसा कुछ बनाता हूं जो कुछ और बनाता है जो कुछ और बनाता है। फिर आप इस तरह से सामान के साथ समाप्त होते हैं:

कस्टम आउटगोइंग कतार बनाई

बॉट
-नए फ़ील्ड msgQueue जो कि एक सिंगलट्रेड एक्सिक्यूटर से ज्यादा कुछ नहीं है
-sendMsg संदेश भेजने तक ब्लॉक करता है, और संदेश मिलने के बीच प्रतीक्षा को जोड़ता है
भेज दिया
-adminExist कॉल अपडेट किया गया (देखें नियंत्रक)
SendMessage के लिए -Removed कॉल

नियंत्रक
-नई फ़ील्ड msgWait संदेशों के बीच प्रतीक्षा करने के लिए समय को दर्शाता है
-स्ट्रीम प्लगइन्स को पुनः आरंभ करने के लिए पुनः लोड करें
-adminExists Global Adins के कारण सर्वर से चला गया। चैनल पर चेक,
सर्वर, और वैश्विक स्तर

व्यवस्थापक
-नहीं तरीके getServer और getChannel जो एप्रोपिएट ऑब्जेक्ट एडमिन को मिलते हैं
का है

BotEvent
-toString () भी दिखाते हैं अतिरिक्त और extra1

चैनल
-चैन फील्ड का नाम बदलकर नामकरण किया गया
-Fixed टाइपो चैनल में (int)

सर्वर
-प्रशासित नियंत्रक के लिए नियंत्रक

PluginExecutor
-Minor परीक्षण जोड़ा, बाद में हटा दिया जाएगा

जेएस प्लगइन्स
-ढांचे में बदलाव के लिए तैयार
-Replaced InstanceTracker.getController () Controller.instance के साथ
-वीएलसी अब खुद की फाइल में बात करेंगे

विभिन्न NB परियोजना अद्यतन और परिवर्तन

---

प्रभावित फाइलें
/Trunk/Quackbot-Core/dist/Quackbot-Core.jar को संशोधित करें
/Trunk/Quackbot-Core/dist/README.TXT संशोधित करें
/Trunk/Quackbot-Core/nbproject/pStreet/pStreet.properties को संशोधित करें
/Trunk/Quackbot-Core/nbproject/pStreet/pStreet.xml को संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/Bot.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/Controller.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/info/Admin.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/info/Channel.java संशोधित करें
/Trunk/Quackbot-Core/src/Quackbot/info/Server.java संशोधित करें
/Trunk/Quackbot-GUI/dist/Quackbot-GUI.jar को संशोधित करें
/Trunk/Quackbot-GUI/dist/README.TXT संशोधित करें
/Trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar को संशोधित करें
/Trunk/Quackbot-GUI/nbproject/pStreet/pStreet.properties को संशोधित करें
/Trunk/Quackbot-GUI/nbproject/pStreet/pStreet.xml को संशोधित करें
/Trunk/Quackbot-GUI/src/Quackbot/GUI.java संशोधित करें
/Trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java संशोधित करें
डिलीट / ट्रंक / क्वैकबॉट-GUI/src/Quackbot/log/WriteOutput.java
/Trunk/Quackbot-Impl/dist/Quackbot-Impl.jar संशोधित करें
/Trunk/Quackbot-Impl/dist/README.TXT संशोधित करें
/Trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar संशोधित करें
/Trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar को संशोधित करें
/Trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar संशोधित करें
/Trunk/Quackbot-Impl/lib/javarebel.stats संशोधित करें
/Trunk/Quackbot-Impl/lib/jrebel.info जोड़ें
/Trunk/Quackbot-Impl/nbproject/pStreet/pStreet.properties को संशोधित करें
/Trunk/Quackbot-Impl/nbproject/pStreet/pStreet.xml को संशोधित करें
/Trunk/Quackbot-Impl/nbproject/project.properties संशोधित करें
/Trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js संशोधित करें
Add / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
/Trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js संशोधित करें
/Trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js संशोधित करें
/Trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomom.ss संशोधित करें
/Trunk/Quackbot-Impl/plugins/listeners/onJoin.js संशोधित करें
/Trunk/Quackbot-Impl/plugins/listeners/onQuit.js संशोधित करें
/Trunk/Quackbot-Impl/plugins/testCase.js संशोधित करें
/Trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js जोड़ें
/Trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java संशोधित करें
जोड़ें / ट्रंक / क्वैकबॉट-इम्प्ल / vlc_http
/Trunk/Quackbot-Impl/vlc_http/current.html जोड़ें
/Trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar को संशोधित करें
/Trunk/Quackbot-Plugins/dist/README.TXT संशोधित करें
/Trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar संशोधित करें
/Trunk/Quackbot-Plugins/nbproject/pStreet/pStreet.properties को संशोधित करें
/Trunk/Quackbot-Plugins/nbproject/pStreet/pStreet.xml को संशोधित करें
/Trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.vava संशोधित करें
जोड़ें / ट्रंक / क्वैकबॉट-प्लगइन्स / vlc_http
/Trunk/global-lib/jrebel.jar जोड़ें

हाँ....

तो सवालों के लिए:

• जब कोई कमिट बहुत बड़ा हो जाता है तो कुछ कारक क्या होते हैं ( गैर-स्पष्ट सामान )?
• आप ऐसे कमिट्स को कैसे रोक सकते हैं? कृपया विवरण दें
• क्या होगा जब आपके विकास के अर्ध-प्रारंभिक चरण में जब चीजें तेज़ी से आगे बढ़ रही हैं? क्या अभी भी बहुत बड़े काम ठीक हैं?

Comments

lists.madduck.net/pipermail/vcs-home/2010-Se/t/000276.html एक ऐसे मामले का वर्णन करता है जहाँ डेटा फ़ाइलें स्वयं बहुत बड़ी होती हैं, जो भंडार में प्रभावी रूप से संग्रहीत होने के लिए बहुत बड़ी हैं। (लेकिन मुझे यकीन है कि आप यहाँ किस बारे में बात कर रहे हैं।)

— केन ब्लूम

रचनात्मक नहीं ????? मैंने यहां सिर्फ एक टन सीखा है! Mods, कृपया अपने ड्रैकोनियन प्रश्न को बंद करें!

— रिचार्ड

क्या तुमने कभी सैकड़ों फ़ाइलों के साथ एक प्रतिबद्ध नहीं देखा, कि किसी भी कट अप संकलन नहीं होगा?

— जोशुआ

Answer 1

मेरे लिए, मुझे "छोटे कमिट" बनाने की कोशिश करने में परेशानी होती है क्योंकि मैं भूल जाता हूं या ऐसा कुछ बनाता हूं जो कुछ और बनाता है जो कुछ और बनाता है।

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

बड़े कमिट्स के साथ समस्या यह है:

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

कभी-कभी बड़े कमेंट्स अपरिहार्य होते हैं; जैसे अगर आपको कोई बड़ी API बदलनी है। लेकिन आम तौर पर ऐसा नहीं है। और यदि आप खुद को इस स्थिति में पाते हैं, तो संभवतः एक अच्छा विचार है कि एक शाखा बनाएं और वहां अपना काम करें ... बहुत सारे छोटे-छोटे कामों के साथ ... और जब आप काम पूरा कर लें तो फिर से संगठित हो जाएं।

(एक अन्य मामला यह है कि जब आप एक प्रारंभिक आयात करते हैं, लेकिन यह ऊपर सूचीबद्ध मुद्दों के परिप्रेक्ष्य से समस्याग्रस्त नहीं है।)

Comments

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

— dr हैनिबल लेक्टर

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

— जल्दी_अनजान

इसके अलावा, छोटे कमिट = उन लोगों के लिए अलग-अलग होते हैं जो पीआरएस द्वारा प्रतिबद्ध-कमिट की समीक्षा करते हैं

— पीटर

Answer 2

एकल जिम्मेदारी सिद्धांत।

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

अपनी वर्किंग कॉपी में बहुत सारे अलग-अलग असंबंधित या अर्ध-संबंधित परिवर्तनों के साथ समाप्त होना बहुत आम है। इसे "पेचीदा काम करने की नकल समस्या" कहा जाता है, और यह वास्तव में अनुशासित डेवलपर्स के लिए भी बचने के लिए बहुत कठिन है। हालाँकि, Git और Mercurial दोनों आपको इसे हल करने के लिए उपकरण देते हैं - क्रमशः Gort ऐड -p या chunk चयन और TortoiseHg में Mercurial Queues ।

Comments

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

— रीनफॉल

Answer 3

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

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

Comments

"1 लाइन / 10 फाइलों" से पूरी तरह सहमत हैं। कानूनों के एक मानक समूह द्वारा इस सवाल का जवाब देने के लिए बहुत सारे चर हैं

— पुलक अग्रवाल

केवल एक चीज जो मैं जोड़ूंगा वह यह है कि कभी-कभी "एक अनुरोध, एक बदलाव" से भी छोटा होने का मतलब होता है। बड़े अनुरोधों को छोटे, वृद्धिशील परिवर्तनों में तोड़ दिया जाना चाहिए। (जैसा कि एक अन्य उत्तर में उल्लेख किया गया है, एक शाखा में विकास से यह सुविधा हो सकती है) अंततः, मैं उपरोक्त मंत्र को इस तरह से अनुकूलित कर सकता हूं: "एक अनुरोध, एक (या अधिक!) परिवर्तन"।

— रिनोगो

Answer 4

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

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

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

Answer 5

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

Answer 6

यह उदाहरण एक प्रतिबद्धता दिखाता है जो बहुत बड़ी है।

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

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

Comments

लिनक्स कर्नेल रिपॉजिटरी में इस नियम का उल्लंघन करने के बहुत सारे अच्छे उदाहरण हैं - वे अक्सर कमिट मैसेज के बॉडी में फिक्स के लिए बग या तर्क के कारण के बारे में बहुत सारे स्पष्टीकरण देते हैं। आपके नियम का एक उचित संस्करण यह होगा "आपको हमेशा 1 वाक्य में एक कमिट के मुख्य बिंदु को समझाने में सक्षम होना चाहिए।"

— केन ब्लूम

@Ken: यहां मेरा लक्ष्य प्रश्न पूछने वाले व्यक्ति की मदद करना है, न कि दुनिया के सभी पहले से मौजूद सोर्स कोड रिपॉजिटरी को कवर करने वाले नियम के साथ आना।

— अज़ेगलोव

Answer 7

अपने क्षेत्र (भौतिकी मॉडलिंग) में, मुझे आज आउटपुट में बग का पता चलता है जो 6 महीने पहले रिपॉजिटरी में नहीं था। जब ऐसा होता है, तो मैं संशोधन पर एक द्विआधारी खोज करूँगा:

1. 3 महीने पहले से मॉडल चलाएं
2. यदि बग अभी भी आउटपुट में है, तो मॉडल को 4.5 महीने पहले से चलाएं
3. ... तब तक दोहराएं जब तक कि मुझे ऐसा कमिटमेंट नहीं मिल जाता, जो खराब आउटपुट देता है

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

मैं आपकी समस्या को छोटे कार्यों की एक श्रृंखला में तोड़ने की सलाह दूंगा (आदर्श रूप से प्रत्येक कार्य को बग ट्रैकर में रखना)। जैसा कि आप प्रत्येक कार्य को पूरा करते हैं (और अपने बग ट्रैकर में उस बग / सुविधा को बंद करते हैं) को कमिट करें।

Comments

अधिकांश आधुनिक तरीकों में बड़े पैमाने पर कमिट्स की तरह ध्वनि कम से कम महीने में ...

— रिग

Answer 8

यह प्रतिबद्ध का आकार नहीं है जो वास्तव में मायने रखता है, यह उस बदलाव का दायरा है जो यह निर्धारित करता है कि आपकी प्रतिबद्धताओं को कैसे व्यवस्थित किया जाए।

उदाहरण के __macro1लिए, __macro2आप एक बड़े कोड बेस में हर उदाहरण को बदल सकते हैं, जो 200 फाइलों को बदलता है। उस मामले में 200 प्रतिबद्धताएं समझदार नहीं होंगी।

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

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

हाँ, आपके पास एक एकल फ़ाइल को पिछले संशोधन में वापस करने की शक्ति है (इस प्रकार एक फ़ाइल को एक बड़ी प्रतिबद्धता से बाहर निकालकर), ऐसा करने से वास्तव में सड़क के नीचे बिसफेक्शन जैसे उपकरण खराब हो जाते हैं, और इतिहास को प्रदूषित करता है।

यदि आप रुकते हैं और सोचते हैं "ठीक है, परीक्षण पास करते हैं, मुझे लगता है कि यह काम करता है .. लेकिन अगर यह खराब हो जाता है, तो क्या मैं इसे आसानी से वापस कर सकता हूं?" .. आप समझदार प्रतिबद्धताओं को समाप्त करेंगे।

Answer 9

यहाँ समझने की बात यह है कि इस संदर्भ में "बड़े" कमिटमेंट के भौतिक आकार नहीं बल्कि कई अलग-अलग परिवर्तनों के बारे में है (हालाँकि आम तौर पर दोनों हाथ से चले जाएंगे)।

इसका इतना सवाल नहीं है कि "बड़े कमिट न करें" जैसा कि छोटे कमिट करते हैं - आदर्श छोटे आत्म निहित बदलाव के लिए किया जा रहा है।

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

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

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

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

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

Answer 10

बहुत कम से कम, अपने आप को प्रतिबद्ध करने के लिए प्रशिक्षित करें जब भी आप अपने आप को सोचते हैं "मुझे अब तक मेरी प्रगति पसंद है, और मैं इसे खोना नहीं चाहता हूं अगर मैं जो बदलाव करने जा रहा हूं वह एक आपदा है।" फिर आपके पास किसी भी मृत छोर को उड़ाने के लिए वीसीएस का लाभ उठाने का विकल्प है जिसे आपने कोशिश की या विशेष डिबगिंग कोड जो आपने किसी समस्या को ट्रैक करने के लिए जोड़ा था। (जैसे git reset --hardया साथ rm -rf *; svn update)

Answer 11

कोई कठिन और तेज़ नियम नहीं है, कोई विभाजन रेखा अतीत नहीं है जो आपकी प्रतिबद्धता बहुत बड़ी है।

वहाँ है , तथापि, एक दिशानिर्देश है कि छोटे प्रतिबद्ध बेहतर हैं कारण के भीतर (यानी हर पंक्ति करने probaby अत्यधिक है)।

मैं इस प्रकार के दिशानिर्देशों को ध्यान में रखता हूं:

• एक सिंगल कमिट में सिर्फ एक बग फिक्स के लिए बदलाव शामिल होना चाहिए
• एक सिंगल कमिट में आधे दिन से ज्यादा काम शामिल नहीं होना चाहिए
• एक भी कमिट बिल्ड को तोड़ना नहीं चाहिए

बेशक - ये वही हैं जो मैं ध्यान में रखता हूं - YMMV। विभिन्न डेवलपर्स ग्रैन्युलैरिटी के विभिन्न स्तरों का पक्ष लेते हैं।

Answer 12

कमिटमेंट जितना छोटा होता है, उतनी ही आसानी से मिल जाएगा, जहां एक संभावित रिग्रेशन आता है।

आदर्श रूप से एक परमाणु परमाणु होना चाहिए , कोड बेस (सबसे छोटा, विशेषता, आदि से संबंधित) के लिए सबसे छोटे सुसंगत परिवर्तन के अर्थ में।

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

कुंजी आपकी "निजी" शाखा के लिए प्रतिबद्ध है जब आप हर बार परमाणु परिवर्तन करते हैं, और फिर आप नियमित रूप से अपनी शाखा को मर्ज कर सकते हैं, उदाहरण के लिए हर हफ्ते।

एक DVcs का उपयोग करके, आपका वर्कफ़्लो इस तरह दिख सकता है:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

केंद्रीकृत vcs का उपयोग करना:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Answer 13

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

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

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

Answer 14

प्रतिबद्ध संदेश केवल एक पंक्ति में होना चाहिए (और अधिकतम 60 वर्णों के लिए)। उस सीमा के भीतर वर्णनात्मक संदेश रखने के लिए कोड की मात्रा कम होनी चाहिए।

मैं हर समय (यहां तक ​​कि अब तक हमने गिट में बदल दिया है) करने के लिए प्रतिबद्ध हूं, मैंने एक चंक किया है, क्योंकि यह "क्यों" चीजों को इस तरह से पकड़ने की अनुमति देता है।

Comments

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

— एलएलक्यू

@ THELQ: फिर से, मैं एक उदाहरण के रूप में लिनक्स कर्नेल पर कई कॉमेट्स लाता हूं, जहां एक लंबी प्रतिबद्ध संदेश अन्य डेवलपर्स के लिए एक विशेष परिवर्तन के लिए तर्क संचार करने का कार्य करता है।

— केन ब्लूम

@ TheLQ, कि कैसे चीजें हमारे लिए अच्छी तरह से काम करती हैं। याद रखें, आपके पास "

Answer 15

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

git citool क्या आप किसी विशेष कमिट में किसी फ़ाइल (या कौन सी विशिष्ट पंक्तियों) का चयन करने के लिए चुन सकते हैं, इसलिए आप एक ही फ़ाइल में किए गए परिवर्तन (गैर-अतिव्यापी) को कई कमिट्स में तोड़ सकते हैं।

(ऐसा लगता है कि आप तोड़फोड़ का उपयोग करते हैं। मुझे ऐसे उपकरण का पता नहीं है जो तोड़फोड़ के लिए ऐसा करता है, लेकिन आप उपयोग करने के लिए देख सकते हैं git-svn, गिट के लिए तोड़फोड़ एडाप्टर, जो आपके जीवन को बदल देगा।)

Comments

हाँ, जो एक ऐसी चीज़ थी जो मुझे गित के बारे में याद आती है: एक फ़ाइल के केवल एक हिस्से को करने की क्षमता। मुझे लगता है कि अंत में यह एक गड़बड़ होगा क्योंकि मैं 1 तरीका बनाऊंगा, लेकिन नया नहीं जो कि इस पर निर्भर करता है, कुछ को तोड़ना।

— TheLQ

@ एलक्यू: ठीक है, कि आपको क्या करना है अगर आप अपने कमिट्स को लॉजिकल चंक्स में व्यवस्थित करना चाहते हैं: या तो जल्दी कमिट करने और अक्सर git rebaseकमिट करने के बारे में बहुत अनुशासित हो जाएं (और कमिट्स में शामिल होने से न डरें जो वास्तव में उसी का हिस्सा हैं संशोधन) या git citoolजब आप दिन के अंत में प्रतिबद्ध होने के लिए तैयार हों तो चीजों को तार्किक भागों में विभाजित करने के लिए ठीक-ठीक कंघी के साथ जाना सीखें ।

— केन ब्लूम

Answer 16

जितनी बड़ी प्रतिबद्धता, उतनी अधिक संभावना है कि आप निर्माण को तोड़ देंगे और अपनी टीम के बाकी सदस्यों द्वारा भुगतान किया जाएगा। मैं दिन में दो बार बदलाव करने की कोशिश करता हूं। दोपहर के भोजन से पहले और घर जाने से पहले। इसलिए @ दोपहर 12 बजे और 4:30 बजे मैं कोशिश करता हूं कि सब कुछ काम कर जाए और मैं प्रतिबद्ध हो जाऊं। मुझे यह अभ्यास मेरे लिए काम करता है।

Answer 17

अपने सवालों के जवाब देने के लिए:

1) मेरे लिए मानक कमिट को बड़ा माना जाता है यदि वह एक से अधिक काम कर रहा है। बात से मेरा मतलब है कि एक बग को ठीक करना या एक फीचर जोड़ना।

2) जब भी आप कुछ खत्म करने के लिए इसे एक आदत और एक नियम बनाने के लिए इस तरह के कमिट्स को रोकें।

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

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

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

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

Answer 18

मेरे मामले में मैं रिपॉजिटरी सिस्टम (एसवीएन) के लिए एक सर्वर की फाइलें करने की कोशिश कर रहा हूं। यह प्रारंभिक प्रतिबद्धता है और इसे डाउनलोड नहीं करना चाहते क्योंकि यह वास्तव में एक बड़ी परियोजना (कुछ जीबी) है और मैं क्लाइंट सर्वर से प्रारंभिक प्रतिबद्ध करना चाहता हूं।

मुद्दा यह है कि क्लाइंट एक साझा सर्वर पर है, svn क्लाइंट को मार दिया जाता है (या कोई अन्य सॉफ़्टवेयर) यदि यह अधिक चलता है तो एक मिनट।

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

मुझसे पहले डेवलपर ने कभी संस्करण नियंत्रण प्रणाली का उपयोग नहीं किया।

Answer 19

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