समझ से बाहर

अनुवादक से: यह लेख git कमांड का वर्णन नहीं करता है, इसका अर्थ है कि आप पहले से ही इससे परिचित हैं। यह पूरी तरह से ध्वनि का वर्णन करता है, मेरी राय में, सार्वजनिक इतिहास को साफ और सुव्यवस्थित रखने के लिए दृष्टिकोण।

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


आइए देखें कि गिट के साथ विकास के लिए सामान्य दृष्टिकोण कैसे अलग हो जाता है।

हम मास्टर से शाखा को तोड़ते हैं, काम करते हैं, जब हम करते हैं तब वापस विलय करते हैं।

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

तेजी से आगे तंत्र को समझाने के लिए, मैंने एक प्रसिद्ध लेख से एक तस्वीर उधार ली। लगभग। दुभाषिया।



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

इसलिए, आप एक नया नियम जोड़ रहे हैं: "- फीचर शाखाओं को मर्ज करते समय-no-ff का उपयोग करें।" इससे समस्या हल होती है और आप आगे बढ़ते हैं।

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

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

एक नो-एफएफ बैसाखी, एक बिस्केट टूट गया, और एक दोषपूर्ण स्लैड एक पेचकश के साथ नौकायन के लक्षण हैं।

रीथिंकिंग वर्जन कंट्रोल

दो चीजों के लिए संस्करण नियंत्रण आवश्यक है।

पहला कोड लिखने में मदद करना है। अपनी टीम के साथ संपादन सिंक्रनाइज़ करने और नियमित रूप से अपने काम का बैकअप लेने की आवश्यकता है।

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

परंपरागत रूप से, ये दो कारण संघर्ष में आते हैं।

कुछ कार्यक्षमता विकसित करते समय, आपको नियमित मध्यवर्ती कमिट की आवश्यकता होगी। हालांकि, ये कमिट आमतौर पर बिल्ड को तोड़ते हैं।

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

तो आप क्या दृष्टिकोण चुनते हैं? बार-बार कमिट या साफ-सुथरी कहानी?

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

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

फीचर शाखाएं एक अच्छे समझौते की तरह दिखती हैं। वे समानांतर विकास की सरल समस्याओं को हल करते हैं। आप कोड लिखते समय कम से कम महत्वपूर्ण बिंदु पर एकीकृत करने के बारे में सोच रहे हैं, लेकिन यह आपको थोड़ी देर के लिए मदद करेगा।

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

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

कर्मों का अनुक्रम

दो श्रेणियों के संदर्भ में शाखाओं के बारे में सोचें: सार्वजनिक शाखाएँ और निजी।

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

अपने लिए निजी शाखा। समस्या को हल करने के समय यह आपका मसौदा है।

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

एक सार्वजनिक सरल मर्ज में एक निजी शाखा को इंजेक्ट न करें। पहले अपनी शाखा को रीसेट, रिबेस, मर्ज - स्क्वैश और कमिटम जैसे उपकरणों से साफ करें।

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

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

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

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

--No-ff के लिए एकमात्र शेष तर्क प्रलेखन है। आप नवीनतम प्रोडक्शन कोड के साथ मर्ज कमिट का उपयोग कर सकते हैं। यह एक एंटीपैटर्न है। टैग का उपयोग करें।

सिफारिशें और उदाहरण

मैं परिवर्तन के आकार के आधार पर 3 सरल दृष्टिकोणों का उपयोग करता हूं, जिस समय यह काम किया था, और शाखा कितनी दूर तक गई थी।

त्वरित संपादित करें

ज्यादातर समय सफाई सिर्फ एक स्क्वैश कमिटमेंट है।
मान लीजिए कि मैंने एक सुविधा शाखा बनाई और एक घंटे के भीतर कई मध्यवर्ती आवागमन किए।

git checkout -b private_feature_branch touch file1.txt git add file1.txt git commit -am "WIP" 

जैसे ही मैं किया जाता हूं, एक साधारण मर्ज के बजाय, मैं निम्नलिखित कार्य करता हूं:

 git checkout master git merge --squash private_feature_branch git commit -v 

फिर मैं एक मिनट कमेंट कमेंट में लिखता हूं।

अधिक संपादित करें

कई बार, एक सुविधा का कार्यान्वयन कई छोटे-छोटे कामों के साथ एक बहु-दिवसीय परियोजना में बढ़ता है।

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

यदि मेरा मध्यवर्ती कमिट एक तार्किक अग्रिम था, तो आप रिबास का उपयोग अंतःक्रियात्मक रूप से कर सकते हैं।

इंटरैक्टिव मोड शक्तिशाली है। आप इसका उपयोग पुराने कमिट्स को संपादित करने, उन्हें विभाजित करने या व्यवस्थित करने के लिए कर सकते हैं, और इस मामले में, कई को संयोजित करने के लिए कर सकते हैं।

सुविधा शाखा में:

 git rebase --interactive master 

एक संपादक कमिट की सूची के साथ खुलता है। प्रत्येक पंक्ति है: निष्पादित करने के लिए एक कमांड, एक SHA1 हैश, और कमेंट के लिए एक टिप्पणी। नीचे संभावित आदेशों की एक सूची दी गई है।

डिफ़ॉल्ट रूप से, प्रत्येक कमिट में "पिक" होता है, जिसका अर्थ है "कमिट न बदलें"।

 pick ccd6e62 Work on back button pick 1c83feb Bug fixes pick f9d0c33 Start work on toolbar 

मैं कमांड को स्क्वैश में बदलता हूं, जो पिछले एक के साथ वर्तमान प्रतिबद्ध को जोड़ती है।

 pick ccd6e62 Work on back button squash 1c83feb Bug fixes pick f9d0c33 Start work on toolbar 

मैं सहेजता हूं, अब एक अन्य संपादक विलय की गई टिप्पणी पर टिप्पणी करता है। सब कुछ तैयार है।

विफल शाखाएँ

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

 git checkout master git checkout -b cleaned_up_branch git merge --squash private_feature_branch git reset 

अब कामकाजी निर्देशिका मेरे संपादन से भरी हुई है और पिछली शाखा की कोई विरासत नहीं है। अब हम लेते हैं और कलम जोड़ते हैं और संपादन करते हैं।

संक्षेप में प्रस्तुत करना

यदि आप कार्य में चूक से जूझ रहे हैं, तो अपने आप से पूछें कि क्यों।

एक सार्वजनिक कहानी को अपरिवर्तनीय, परमाणु और आसानी से पता लगाने योग्य पर विचार करें।
एक निजी कहानी को परस्पर और लचीली समझें।

प्रक्रिया इस प्रकार है:

• सार्वजनिक शाखा से एक निजी शाखा बनाएँ।
• हम इस निजी शाखा में विधिपूर्वक काम करते हैं।
• कोड सही होने के बाद, हम कहानी को व्यवस्थित करते हैं।
• आदेशित शाखा को जनता में वापस मर्ज करें।