से Git एससीएम बुक :
अक्सर, जब आप अपनी परियोजना के हिस्से पर काम कर रहे होते हैं, तो चीजें गड़बड़ होती हैं और आप कुछ और काम करने के लिए शाखाओं को थोड़ा बदलना चाहते हैं। समस्या यह है कि आप आधे-अधूरे काम करने की इच्छा नहीं रखते हैं ताकि आप बाद में इस बिंदु पर वापस आ सकें। इस मुद्दे का जवाब git stash कमांड है।
स्टैशिंग आपकी कार्यशील निर्देशिका की गंदी स्थिति को ले जाता है - अर्थात, आपकी संशोधित ट्रैक की गई फ़ाइलें और परिवर्तनों का मंचन - और इसे अधूरे परिवर्तनों के ढेर पर सहेजता है जिन्हें आप किसी भी समय पुन: लागू कर सकते हैं।
इस विवरण को देखते हुए, मैं कहूंगा कि यह एक एंटी पैटर्न है। गिट स्टैश की एक अत्यधिक सरल व्याख्या यह होगी कि यह स्रोत नियंत्रण का "कट एंड पेस्ट" है। आप परिवर्तित फ़ाइलों का एक गुच्छा लेते हैं, उन्हें Git की सामान्य ब्रांचिंग वर्कफ़्लो के बाहर एक होल्डिंग पेन में "स्लैश" करते हैं, और फिर बाद में एक अलग शाखा में उन परिवर्तनों को फिर से लागू करते हैं।
थोड़ा और पीछे जाएं, तो गुरु के प्रति वचनबद्धता यहां का विरोधी स्वरूप है। शाखाओं का उपयोग करें। यही कारण है कि वे के लिए डिजाइन किए गए थे।
यह वास्तव में यह करने के लिए नीचे फोड़े:
आप दीवार में एक स्क्रू को हथौड़ा कर सकते हैं और यह एक तस्वीर बनाए रखेगा, लेकिन एक पेचकश का उपयोग करना है जो आपको करना चाहिए। जब आपके बगल में पेचकश बैठा हो तो हथौड़े का प्रयोग न करें।
"टूटी हुई" कोड के बारे में
जबकि निम्नलिखित राय है, मैं अनुभव से इस राय पर आया हूं।
जल्दी कमिट करें, और अक्सर कमिट करें। जितना चाहे उतना कोड टूट जाए। जब आप किसी चीज़ को हैक करते हैं तो अपने स्थानीय प्रतिबद्ध इतिहास को "सेव पॉइंट" के रूप में देखें। एक बार जब आप तार्किक कार्य कर लेते हैं, तो कमिट करें। यकीन है कि यह सब कुछ तोड़ सकता है, लेकिन यह तब तक कोई फर्क नहीं पड़ता जब तक आप उन कमिटों को धक्का नहीं देते । पुश करने से पहले, रिबेट करें और अपने कमिट्स को स्क्वैश करें।
- नई शाखा बनाएं
- हैक हैक
- टूटा हुआ कोड
- कोड पोलिश करें और इसे काम करें
- काम करने का कोड
- रिबेस और स्क्वैश
- परीक्षा
- जब टेस्ट पास हो रहे हों तो पुश करें
ओपी के लिए, यह लिनक्स कर्नेल संदेश धागा रुचि का हो सकता है, क्योंकि यह ओपी की टीम के कुछ सदस्यों की तरह लगता है कि एक समान तरीके से गिट का उपयोग कर रहा है।
@RibaldEddie ने नीचे टिप्पणी में कहा:
सबसे पहले, एक स्लैश "ब्रांचिंग वर्कफ़्लो" के बाहर नहीं है क्योंकि हुड के नीचे एक स्लैश सिर्फ दूसरी शाखा है।
(कई लोगों के प्रकोप के जोखिम में)
लिनस ने कहा:
"गिट स्टैश" के साथ, आपके पास कई अलग-अलग स्टैक्ड चीजें भी हो सकती हैं, लेकिन वे एक-दूसरे पर कतार नहीं लगाते हैं - वे सिर्फ यादृच्छिक स्वतंत्र पैच हैं जो आप दूर भाग गए हैं क्योंकि वे कुछ बिंदु पर असुविधाजनक थे।
मुझे क्या लगता है @RibaldEddie यह कहना चाह रही है कि आप git stashएक सुविधा शाखा वर्कफ़्लो में उपयोग कर सकते हैं - और यह सच है। यह git stashउस समस्या का उपयोग नहीं है। यह मास्टर और उपयोग करने के लिए प्रतिबद्ध है git stash। यह एक विरोधी पैटर्न है।
स्पष्ट git rebase
@ RibaldEddie की टिप्पणी से:
रिबासिंग कॉपी-पेस्टिंग की तरह बहुत अधिक है और इससे भी बदतर प्रतिबद्ध इतिहास को संशोधित करता है।
(जोर मेरा)
जब तक यह स्थानीय प्रतिबद्ध इतिहास है, तब तक प्रतिबद्ध इतिहास को संशोधित करना कोई बुरी बात नहीं है । यदि आप मना करते हैं कि आपने पहले ही धक्का दे दिया है, तो आप अनिवार्य रूप से किसी और को अपनी शाखा का उपयोग कर सकते हैं। ये गलत है।
अब, मान लें कि आपने एक दिन के दौरान कई कमिट किए हैं। कुछ कमिट अच्छे थे। कुछ ... इतना अच्छा नहीं। git rebaseअपने प्रतिबद्ध कुचलने के साथ संयोजन के रूप में आदेश एक अच्छा तरीका है अपने स्थानीय प्रतिबद्ध इतिहास को साफ करने के लिए है। सार्वजनिक शाखाओं में किसी एक समिति में विलय करना अच्छा है क्योंकि यह आपकी टीम की साझा शाखाओं के प्रतिबद्ध इतिहास को साफ रखता है। रिबासिंग के बाद, आप फिर से परीक्षण करना चाहते हैं, लेकिन यदि परीक्षण पास हो जाते हैं, तो आप कई गंदे लोगों के बजाय एक स्वच्छ प्रतिबद्ध धक्का दे सकते हैं।
क्लीन कमिट हिस्ट्री पर एक और दिलचस्प लिनक्स कर्नेल थ्रेड है ।
फिर से, लिनस से:
मैं स्वच्छ इतिहास चाहता हूं, लेकिन वास्तव में इसका मतलब (ए) स्वच्छ और (बी) इतिहास है।
लोग अपने निजी पेड़ों (अपने काम से) को फिर से पा सकते हैं (और शायद )। वह सफाई है । लेकिन कभी अन्य लोगों का कोड नहीं। यह एक "इतिहास को नष्ट" है
इसलिए इतिहास का हिस्सा काफी आसान है। केवल एक प्रमुख नियम है, और एक लघु स्पष्टीकरण:
आपको कभी भी अन्य लोगों के इतिहास को नष्ट नहीं करना चाहिए। आप अन्य लोगों द्वारा किए गए कामों को नहीं छोड़ना चाहिए। मूल रूप से, यदि आपके पास इस पर आपका साइन-ऑफ नहीं है, तो यह सीमा से बाहर है: आप इसे वापस नहीं कर सकते, क्योंकि यह आपका नहीं है।
ध्यान दें कि यह वास्तव में अन्य लोगों के इतिहास के बारे में है, अन्य लोगों के कोड के बारे में नहीं । यदि उन्होंने आपको ईमेल किए गए पैच के रूप में सामान भेजा है, और आपने इसे "git am -s" के साथ लागू किया है, तो यह उनका कोड है, लेकिन यह
आपका इतिहास है।
तो आप इस पर "गिट रिबास" बात पर जंगली जा सकते हैं, भले ही आपने कोड नहीं लिखा हो, जब तक कि प्रतिबद्ध खुद आपका निजी है।
नियम के लिए मामूली स्पष्टीकरण: एक बार जब आप अपना इतिहास किसी सार्वजनिक साइट पर प्रकाशित करते हैं, तो अन्य लोग इसका उपयोग कर सकते हैं, और इसलिए अब यह स्पष्ट रूप से आपका निजी इतिहास नहीं है।
तो मामूली स्पष्टीकरण वास्तव में यह है कि यह केवल "आपकी प्रतिबद्धता" के बारे में नहीं है, यह आपके पेड़ पर निजी होने के बारे में भी है, और आपने इसे बाहर नहीं धकेल दिया है और इसकी घोषणा अभी तक नहीं की है।
...
अब "स्वच्छ" हिस्सा थोड़ा अधिक सूक्ष्म है, हालांकि पहले नियम बहुत स्पष्ट और आसान हैं:
अपना खुद का इतिहास पठनीय रखें
कुछ लोग केवल अपने सिर में काम करने वाली चीजों को पहले करते हैं, और गलतियाँ नहीं करते हैं। लेकिन यह बहुत दुर्लभ है, और हम में से बाकी के लिए, हम अपनी समस्याओं पर काम करते समय "गिट रीबेस" आदि का उपयोग करते हैं।
इसलिए "git rebase" गलत नहीं है। लेकिन यह केवल तभी सही है जब यह आपका बहुत निजी निजी पेड़ है।
अपनी बकवास का पर्दाफाश मत करो।
इसका मतलब है: यदि आप अभी भी "गिट रीबेस" चरण में हैं, तो आप इसे बाहर नहीं धकेलते हैं। यदि यह तैयार नहीं है, तो आप चारों ओर पैच भेजते हैं, या निजी गिट पेड़ों का उपयोग करते हैं (बस एक "पैच श्रृंखला प्रतिस्थापन" के रूप में) जिसे आप बड़े पैमाने पर जनता को नहीं बताते हैं।
(जोर मेरा)
निष्कर्ष
अंत में, ओपी के पास कुछ डेवलपर्स हैं:
git checkout master
(edit files)
git commit -am "..."
(edit files)
git stash
git pull
git stash (pop|apply)
यहां पर दो समस्याएं हैं:
- डेवलपर्स मास्टर करने के लिए प्रतिबद्ध हैं। इसे तुरंत बंद कर दें। वास्तव में, यह सबसे बड़ी समस्या है।
- डेवलपर्स लगातार
git stashऔर git pullमास्टर पर उपयोग कर रहे हैं जब उन्हें सुविधा शाखाओं का उपयोग करना चाहिए।
उपयोग करने के साथ कुछ भी गलत नहीं है git stash- विशेष रूप से एक पुल से पहले - लेकिन git stashइस तरीके का उपयोग एक विरोधी पैटर्न है जब गिट में बेहतर वर्कफ़्लो होते हैं।
git stashएक लाल हेरिंग का उनका उपयोग । यह समस्या नहीं है। गुरु को वचन देना समस्या है।