क्या प्रत्येक हितग्राही को कार्यशील अवस्था में परियोजना छोड़नी चाहिए?

Question

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

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

Answer 1

मैं आमतौर पर इस नियम का पालन करता हूं:

• शाखा में प्रत्येक मर्ज को एक कार्यशील स्थिति में परियोजना को छोड़ना होगा ;master
• मेनलाइन शाखा में प्रत्येक मर्ज को एक कार्यशील स्थिति में परियोजना को छोड़ देना चाहिए (और इसे कम से कम निर्माण करना होगा);develop
• एक-दूसरे की व्यक्तिगत प्रतिबद्धता यह समझाने का एक प्राथमिक लक्ष्य है कि परिवर्तन क्यों किया गया है, और यह किसके लिए है, और परियोजना के कौन से हिस्से प्रभावित हुए हैं। अन्य सभी लक्ष्य, जैसे कि कार्यशील स्थिति में परियोजना को छोड़ना, वैकल्पिक हैं।

Comments

हमने अपने कार्यालय में समान नलिकाएं स्थापित कीं, और यह ठीक काम कर रहा है। ऐसा नहीं है कि यह git तक सीमित नहीं है बल्कि किसी भी समान टूल (मर्क्यूरियल, svn, इत्यादि) के साथ काम करता है।)

— deadalnix

Answer 2

विकास करते समय जो भी आपको आरामदायक बनाता है उसके लिए रिपॉजिटरी के अपने स्थानीय क्लोन का उपयोग करें।

मैं नियमित रूप से टूटा हुआ कोड करता हूं, और जब मैं अन्य डेवलपर्स के लिए कोड उपलब्ध करने के लिए तैयार होता हूं, तो मैं एक महान सुविधा का उपयोग करता हूं:

git rebase -i HEAD~4

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

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

Comments

मैं इस उत्तर की बुद्धिमत्ता पर सवाल उठाता हूं क्योंकि यह rebaseकाफी विवादास्पद है: थाउ श्लॉट नॉट लिट: गिट रिबेस, संशोधन, स्क्वैश, और अन्य झूठ

— स्लेज

@ArtB: लेकिन इस मामले में, मेमटेक केवल अपने आप से झूठ बोल रहा है (IOW सार्वजनिक इतिहास नहीं लिख रहा है), और यह बहुत विवादास्पद नहीं है।

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

@ आर्ट आर्टिकल में प्रकाशित कमिट्स का जिक्र है। उत्तर अप्रकाशित आवागमन को संदर्भित करता है।

— d0001

@WayneConrad "अंगूठे का एक अच्छा नियम यह है कि आपको उन चीजों के लिए इतिहास को फिर से लिखना नहीं चाहिए जो पहले से ही दुनिया में धकेल दी गई हैं। इससे इन पुनर्लेखन टूल को स्थानीय रूप से उपयोग करने वाली चीजों को धक्का देने से पहले" ठीक "करने के लिए सीमित कर दिया जाएगा।" उपसंहार के अंतिम पैराग्राफ से।

— एंड्रयू का कहना है कि मोनिका

@ArtB - मैं इंटरनेट पर पढ़ी गई हर चीज़ पर विश्वास करने और (या न करने) पर विश्वास करने की बुद्धि पर सवाल उठाता हूँ, जो आप इंटरनेट पर पढ़े बिना यह समझे कि (या क्यों नहीं)।

— मटनज़

Answer 3

संस्करण नियंत्रण के दो महान लाभ यह हैं कि यह डेवलपर्स को उनके काम के पिछले संस्करणों को पुनर्प्राप्त करने देता है, और यह डेवलपर्स को अलग-अलग प्रयास करने देता है, संभवतः एक ही समय में परस्पर विरोधी परिवर्तन। संस्करण नियंत्रण डेवलपर्स को विचारों की कोशिश करने की स्वतंत्रता देता है जो विफल हो सकते हैं।

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

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

Answer 4

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

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

Answer 5

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

यह git pushअन्य उपयोगकर्ताओं को प्रभावित करता है। आपकी विकास टीम को क्या निर्णय लेना चाहिए, इसके लिए नीतियों को आगे बढ़ाया जाना चाहिए। मुख्य शाखा पर गैर-काम कोड को धक्का देना संभवत: एक नहीं-नहीं है, लेकिन गैर-काम कोड को एक अलग शाखा पर धकेलना ठीक है (जब तक कि कोई और उस शाखा से निर्माण करने की कोशिश नहीं करेगा)।

Answer 6

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

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

Answer 7

अंततः यह आपके और उन लोगों के लिए है, जिनके साथ आप काम करते हैं या जिनके लिए कोई नियम लागू नहीं करता है।

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

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

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

Answer 8

यह मानते हुए कि आप शाखाओं का उपयोग कर रहे हैं, और अच्छी प्रतिबद्ध संदेश, एक प्रतिबद्ध संदेश के साथ एक शाखा पर "टूटा हुआ" कोड है जो यह स्पष्ट करता है कि यह ठीक होगा, जब तक कि आपकी टीम सहमत हो कि यह एक अच्छा काम है।

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

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