क्या संस्करण इतिहास वास्तव में पवित्र है या इसे फिर से बनाना बेहतर है?

Question

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

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

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

तो मेरा सवाल है: क्या आपने वास्तव में इस तरह के "ऑर्गेनिक कमिट्स" (यानी अप्रकाशित इतिहास) को मूल्यवान पाया है ?, या इसके विपरीत, क्या आप निफ्टी में अच्छी तरह से पैक किए गए कमिट को चलाना पसंद करते हैं और प्रोग्रामर्स के प्रयोग की प्रक्रिया की उपेक्षा करते हैं ?; जो भी आपने चुना है, वह आपके लिए क्यों काम करता है? (टीम के अन्य सदस्यों के पास इतिहास रखने के लिए, या वैकल्पिक रूप से, इसे फिर से शुरू करने के लिए)।

---

¹ प्रति Google DVCS विश्लेषण , मर्क्यूरियल में "इतिहास पवित्र है"।

Comments

क्या आप इसे "मरक्यूरियल मंत्र" के रूप में संदर्भित कर सकते हैं?

— gnat

अब जब कि तुम यह उल्लेख, मुझे लगता है कि यह वास्तव में गूगल के DVCS विश्लेषण से आता है code.google.com/p/support/wiki/DVCSAnalysis (लेकिन वास्तव अवशेष)

— dukeofgaming

किसी परियोजना के वीसीएस इतिहास

— gnat

Answer 1

इतिहास पवित्र है, वर्तमान नहीं है। आप अपने DVCS "ट्री" को दो भागों में विभाजित कर सकते हैं:

• अतीत / इतिहास जो कि कैसे आप कोड की वर्तमान स्थिति तक पहुँच चुके हैं का सही दृश्य शामिल हैं। इतिहास का यह हिस्सा समय के साथ बढ़ता है

• वर्तमान कौन सा हिस्सा आप वर्तमान में काम कर रहे हैं आप कोड Evolve बनाने के लिए। इतिहास के अधिकांश भाग में हमेशा एक जैसा आकार होता है।

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

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

तो हाँ, कृपया रीबेस करें अगर यह आपके इतिहास को बेहतर बनाता है। मर्क्यूरियल आपको पैर में अपने आप को शूट करने से रोकेगा यदि आप सामान को रिबास कर रहे हैं तो आपको नहीं करना चाहिए।

Comments

अब, मुझे आपका उत्तर बेहतर लगा

— dukeofgaming

Answer 2

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

Comments

तो आप कभी भी अधिक "तार्किक" बनाने के लिए नहीं मना करेंगे?

— ड्यूकफैगिंग

Answer 3

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

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

दूसरी ओर, अगर किसी को एक-दूसरे से कोई लेना-देना नहीं है, तो रिबेट की सलाह दी जाती है। मल्टीपल फीचर एडिशन अलग-अलग होने चाहिए (और आदर्श रूप से अलग-अलग शाखाओं से आते हैं)।

Comments

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

— पीके।

आधार संशोधन और फीचर पूर्ण संशोधन के बीच अंतर की समीक्षा करने और उस पुन: आधारित सेट के एकल प्रतिबद्धताओं की समीक्षा करने में कोई अंतर कैसे है? यह समान दिखने वाला है अगर री-बेस ने सही ढंग से काम किया है!

— मार्क बूथ

यहाँ आप जो भी वर्णन करते हैं वह सीधे मर्क्यूरियल विकि में सलाह के विरुद्ध जाता है । छोटे "स्पष्ट रूप से सही" परिवर्तनों को समीक्षाओं के लिए पसंद किया जाता है। एकल चेंज में एक फीचर ब्रांच को समाप्‍त करना मर्क्यूरियल में सामान्‍य नहीं है - मैंने देखा है कि यह कई बार Git में अनुशंसित होता है जहां git rebase -iआप इसे आसानी से और चुनिंदा तरीके से कर सकते हैं। निकटतम मर्क्युरियल बराबर है histedit ।

— मार्टिन गेइस्लर

मैं पूरी तरह से असहमत हूं। पिछले कुछ वर्षों में हमने कोड समीक्षाओं के लिए एक उपकरण का उपयोग किया था, और कुछ भी नहीं था जिससे मुझे समीक्षा के लिए प्रस्तुत एक बड़े 30+ फ़ाइल परिवर्तन से नफरत हो गई थी। बहुत सारे छोटे-छोटे बदलाव करना बहुत आसान है। उदा। मैंने इस वर्ग का नाम बदलकर xyz कर दिया क्योंकि यह संशोधित जिम्मेदारी को बेहतर ढंग से दर्शाता है। मैंने पद्धति nn को जोड़ा क्योंकि मुझे ब्ला के लिए इसकी आवश्यकता होगी। छोटी समीक्षाओं को संभालने के लिए बहुत आसान है।

— पीट

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

— क्रिस सटन

Answer 4

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

मुझे नहीं लगता कि ऑर्गेनिक वर्कफ़्लोज़ यह अच्छी तरह से करते हैं, यहां तक ​​कि मेरे अपने भी। जब मैं कोडिंग कर रहा हूं, तो डीवीसी के बारे में योग्यताएं - जब मैं कोडिंग कर रहा हूं - सस्ती शाखाएं, त्वरित आवागमन, दूरस्थ रूप से जल्दी और अक्सर बचाता है - वे नहीं हैं जो मैं अपनी कंपनी के एकीकरण प्रबंधक के रूप में महत्व देता हूं । मैं इस मुद्दे git rebase, git merge, git diff, और git applyकहीं अधिक अक्सर उस से भूमिका में git addया git commit। जैसे उपकरण rebaseमुझे उस कोड को बदलने की अनुमति देते हैं जो मुझे कुछ ऐसे कार्यों से दिया जाता है जिसे बनाए रखा जा सकता है।

अवैध या अस्पष्ट काम उपयोगी नहीं होते हैं, लेकिन जब वे प्राथमिक चिंता कोड काम कर रहे होते हैं, तो उन्हें दूसरों को वितरित नहीं करना, संगठित रूप से लिखना आसान होता है। जब भी मैं उन्हें लेखक करता हूं, तब मेरे रखरखाव-स्वयं की कमी को पसंद करता है Case 15: Fixed a problem, या करता Refactored <cranky legacy feature>है। हालांकि, कोई भी, "वृद्धिशील" जैसे ब्लैकआउट क्रोध को प्रेरित नहीं करता है। इस विषय शाखा पर विचार करें कि एक डेवलपर ने मुझे दूसरे दिन सौंप दिया:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

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

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

Comments

बहुत अच्छा जवाब, क्रिस्टल स्पष्ट प्रेरणाओं को

— पुन:

Answer 5

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

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

Answer 6

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

Comments

आप जो कह रहे हैं, वह यह है कि आप एक आधारभूत शाखा (यानी मास्टर / डिफ़ॉल्ट, उत्पादन / रिलीज, vX.X, आदि) के संपादन पर काम करने वाली शाखाओं का पक्ष लेते हैं?

— ड्यूकफैगिंग