यह प्रतिवाद करने वाला है, लेकिन मेरी बात सुनो:
उन्हें उत्साह के साथ प्रयोग शुरू करने के लिए प्रोत्साहित करें
गिट के बारे में दिलचस्प चीजों में से एक यह है कि किसी भी स्थानीय ऑपरेशन को पूरी तरह से सुरक्षित बनाना आश्चर्यजनक रूप से आसान है। जब मैंने पहली बार git का उपयोग करना शुरू किया, तो मैंने जो कुछ भी पाया, उसमें से एक को मैं पूरी तरह से पूरी निर्देशिका के रूप में तैयार कर रहा था, जब मैंने किसी चीज़ को खराब कर दिया था। मुझे बाद में पता चला कि यह एक बहुत बड़ा कीचड़ है और यह लगभग कभी भी आपके काम की सुरक्षा के लिए आवश्यक नहीं है, लेकिन इसमें बहुत सुरक्षित और बहुत सरल होने का गुण है , भले ही आपको पता नहीं हो कि आप क्या कर रहे हैं और कैसे कर रहे हैं आप जिस कमांड को आज़माना चाहते हैं, वह चालू हो जाएगा। जब आप ऐसा कर रहे होते हैं तो केवल आपको ही बचना होता है push। यदि आप कुछ भी धक्का नहीं देते हैं, तो यह 100% सुरक्षित तरीका है जो आप चाहते हैं।
सामानों को आजमाने से डरना सबसे बड़ी अड़चन है। यह आपको देता है तो सब कुछ है कि यह एक तरह से कठिन है पर अधिक नियंत्रण। वास्तविकता यह है कि आप अपने दैनिक उपयोग के लिए कुछ बहुत ही सुरक्षित संचालन से चिपके रह सकते हैं, लेकिन जो खोजते हैं, उन्हें खोजने के लिए कुछ कमांड लेते हैं।
उन्हें सुरक्षा की भावना देकर , वे यह जानने की कोशिश करने के लिए और अधिक तैयार होंगे कि चीजों को कैसे करना है। और वे अपने स्थानीय मशीन पर एक व्यक्तिगत कार्य प्रवाह खोजने के लिए अधिक सशक्त होंगे जो उनके लिए काम करता है। और अगर हर कोई स्थानीय रूप से एक ही काम नहीं करता है , तो यह ठीक है, जब तक कि वे मानकों का पालन करते हैं जो वे धक्का देते हैं । यदि यह ऑपरेशन करने से पहले पूरे रेपो को जिप कर लेता है तो उन्हें इस तरह से महसूस करना ठीक है; वे चीजों को करने के बेहतर तरीकों को उठा सकते हैं जैसे वे जाते हैं और जैसा कि वे सामान की कोशिश करते हैं। कुछ भी अपने आप को पाने के लिए सामान की कोशिश शुरू करने और यह क्या करता है देखने के लिए।
इसका मतलब यह नहीं है कि प्रशिक्षण बेकार है। इसके विपरीत, प्रशिक्षण आपको सुविधाओं और पैटर्न और मानदंडों से परिचित कराने में मदद कर सकता है। लेकिन यह नीचे बैठने के लिए एक प्रतिस्थापन नहीं है और वास्तव में आपके दैनिक कार्य में सामान कर रहा है । न तो गिट और न ही एसवीएन ऐसी चीजें हैं जो आप सिर्फ एक कक्षा में जा सकते हैं और फिर आप सब कुछ जानते हैं। आपको उनकी समस्याओं को हल करने के लिए उनका उपयोग करना होगा और उनसे परिचित होना चाहिए कि कौन सी विशेषताएँ किन समस्याओं के लिए अनुकूल हैं।
उन्हें ins और git के बहिष्कार सीखने से हतोत्साहित करना बंद करें
मैंने कुछ भी नहीं धकेलने का उल्लेख किया, जो वास्तव में उन चीजों में से एक के खिलाफ जाता है जो आप उन्हें सिखा रहे हैं: हमेशा "कमिट एंड पुश"। मेरा मानना है कि आपको उन्हें ऐसा करने के लिए कहना बंद कर देना चाहिए और उनसे कहना चाहिए कि वे इसके विपरीत करना शुरू कर दें। Git में मूल रूप से 5 "स्थान" हैं जहाँ आपके परिवर्तन हो सकते हैं:
- डिस्क पर, uncommitted
- मंचन किया लेकिन प्रतिबद्ध नहीं
- एक स्थानीय प्रतिबद्ध में
- एक स्थानीय झड़प में
- दूरस्थ रिपॉजिटरी (केवल कमिट और टैग कभी-कभी अलग-अलग रिपॉजिटरी के बीच धकेल दिए जाते हैं और खींचे जाते हैं)
उन्हें एक ही चरण में सब कुछ खींचने और धक्का देने के लिए प्रोत्साहित करने के बजाय, इन 5 अलग-अलग स्थानों का लाभ उठाने के लिए प्रोत्साहित करें। उन्हें प्रोत्साहित करें:
इससे उन्हें सार्वजनिक रूप से सभी के लिए उपलब्ध होने से पहले अपने काम की जांच करने के लिए प्रोत्साहित किया जाएगा , जिसका अर्थ है कि वे जल्द ही अपनी गलतियों को पकड़ लेंगे। वे कमिट को देखेंगे और सोचेंगे, "रुको, जो मैं चाहता था, वह नहीं है" और एसवीएन में इसके विपरीत, वे वापस जा सकते हैं और धक्का देने से पहले फिर से कोशिश कर सकते हैं ।
एक बार जब उन्हें यह समझने की आदत हो जाती है कि उनके परिवर्तन कहाँ हैं, तो वे यह तय करना शुरू कर सकते हैं कि कब कदमों को छोड़ें और कुछ ऑपरेशनों को मिलाएं (जब खींचना है क्योंकि आप पहले से ही जानते हैं कि आप लाना चाहते हैं + मर्ज करना चाहते हैं या उस कमेंट और पुश विकल्प पर क्लिक करना चाहते हैं) ।
यह वास्तव में SVN पर git के भारी लाभों में से एक है, और git को इस उपयोग पैटर्न को ध्यान में रखकर बनाया गया है। एसवीएन, इसके विपरीत, केंद्रीय रिपॉजिटरी को मानता है, इसलिए यदि यह समान वर्कफ़्लो के लिए git के लिए टूलिंग अनुकूलित नहीं है, तो यह बहुत ही आश्चर्यजनक है। एसवीएन में, यदि आपकी प्रतिबद्धता गलत है, तो आपका एकमात्र वास्तविक सहारा गलती को पूर्ववत करने के लिए एक नई प्रतिबद्धता है।
ऐसा करने से वास्तव में स्वाभाविक रूप से अगली रणनीति बन जाएगी:
उन्हें स्थानीय शाखाओं का उपयोग करने के लिए प्रोत्साहित करें
स्थानीय शाखाएं वास्तव में साझा फ़ाइलों पर काम करने के दर्द बिंदुओं को बहुत कम करती हैं। मैं अपनी शाखा में अपनी इच्छानुसार सभी परिवर्तन कर सकता हूं, और यह कभी किसी को प्रभावित नहीं करेगा क्योंकि मैं उन्हें धक्का नहीं दे रहा हूं। फिर जब समय आता है, मैं सभी समान मर्ज और रीबेस की रणनीतियों का उपयोग कर सकता हूं, केवल आसान:
- मैं अपनी स्थानीय शाखा को फिर से बना सकता हूं, जो इसे मास्टर तुच्छ में विलय कर देता है।
- मैं अपनी स्थानीय शाखा के बदलावों को लाने के लिए मास्टर में एक सादे मर्ज (एक नई प्रतिबद्धता बनाने) का उपयोग कर सकता था।
- अगर मैं सोचता हूं कि मेरी शाखा स्थानीय एकल शाखा में विलय कर सकती है, अगर मुझे लगता है कि मेरी शाखा मुक्ति के लिए बहुत अधिक है।
स्थानीय शाखाओं का उपयोग करना भी एक व्यवस्थित शाखा रणनीति का पता लगाने के लिए एक अच्छी शुरुआत है। यह आपके उपयोगकर्ताओं को अपनी स्वयं की शाखाओं की जरूरतों को बेहतर ढंग से समझने में मदद करता है, इसलिए आप जरूरतों और टीम की वर्तमान समझ / कौशल के स्तर के आधार पर एक रणनीति चुन सकते हैं और सिर्फ गिफ्टफ्लो में नहीं गिर सकते क्योंकि सभी ने इसके बारे में सुना है।
सारांश
संक्षेप में, git SVN नहीं है और इसे इस तरह नहीं माना जा सकता है। आपको:
- सुरक्षित प्रयोग को प्रोत्साहित करके डर को खत्म करें।
- उन्हें यह समझने में मदद करें कि git अलग कैसे है ताकि वे देख सकें कि उनके सामान्य वर्कफ़्लो को कैसे बदलता है।
- उन्हें अपनी समस्याओं को अधिक आसानी से हल करने में मदद करने के लिए उपलब्ध सुविधाओं को समझने में मदद करें।
यह सब आपको धीरे-धीरे बेहतर गिट उपयोग को अपनाने में मदद करेगा , जब तक कि आप उस बिंदु तक नहीं पहुंच जाते जहां आप मानकों के एक सेट को लागू करना शुरू कर सकते हैं।
विशिष्ट लक्षण
तत्काल शब्द में, निम्नलिखित विचार मदद कर सकते हैं।
rebase
आपने रिबेस का उल्लेख किया है और यह कि आप वास्तव में इसे अपने प्रश्न में नहीं समझते हैं। तो यहाँ मेरी सलाह है: जो मैंने अभी वर्णित किया है उसे आज़माएँ। स्थानीय रूप से कुछ परिवर्तन करें जबकि कोई अन्य कुछ परिवर्तनों को आगे बढ़ाता है। स्थानीय रूप से अपने बदलाव करें । बैक अप के रूप में अपनी रिपॉजिटरी डायरेक्टरी को जिप करें। दूसरे व्यक्ति के परिवर्तनों को प्राप्त करें। अब एक रीबेस कमांड चलाने की कोशिश करें और देखें कि आपके कमिट्स का क्या होता है! आप अंतहीन ब्लॉग पोस्ट पढ़ सकते हैं या रिबेस के बारे में प्रशिक्षण प्राप्त कर सकते हैं और आपको इसका उपयोग कैसे करना चाहिए या क्या नहीं करना चाहिए, लेकिन इसमें से कोई भी इसे कार्रवाई में लाइव देखने के लिए प्रतिस्थापन नहीं है। इसलिए इसे आजमाएं ।
merge.ff=only
यह एक व्यक्तिगत स्वाद की बात होने जा रही है, लेकिन मैं आपको कम से कम अस्थायी रूप से इसकी सिफारिश करने जा रहा हूं क्योंकि आपने पहले ही उल्लेख किया है कि आपको संघर्ष से निपटने में परेशानी है। मैं यह निर्धारित merge.ffकरनेonly की अनुशंसा करता हूं :
git config --global merge.ff only
"एफएफ" का अर्थ है "तेजी से आगे बढ़ना।" एक तेज़ फ़ॉरवर्ड मर्ज तब होता है जब git को अलग-अलग कमिट से परिवर्तनों को संयोजित करने की आवश्यकता नहीं होती है। यह बस ग्राफ में एक सीधी रेखा के साथ शाखा के पॉइंटर को एक नई प्रतिबद्ध तक ले जाता है।
व्यवहार में ऐसा करने से गिट को कभी भी स्वचालित रूप से मर्ज करने की कोशिश करने से रोका जाता है। इसलिए यदि मैं स्थानीय रूप से कुछ करता हूं और फिर किसी और के परिवर्तन को खींचता हूं, तो मर्ज कमिट बनाने की कोशिश करने के बजाय (और संभावित रूप से उपयोगकर्ता को संघर्षों से निपटने के लिए मजबूर करना), मर्ज बस विफल हो जाएगा। वास्तव में, git ने केवल एक प्रदर्शन किया होगा fetch। जब आपके पास कोई स्थानीय आवागमन नहीं होता है, तो मर्ज सामान्य रूप से बढ़ता है।
इससे उपयोगकर्ताओं को उन्हें मर्ज करने का प्रयास करने से पहले विभिन्न कमियों की समीक्षा करने का मौका मिलता है और उन्हें इस बात का निर्णय लेने के लिए मजबूर किया जाता है कि उन्हें कैसे बेहतर तरीके से संभालना है। मैं मर्ज कर सकता हूं, मर्ज के साथ आगे बढ़ सकता हूं ( git merge --no-ffकॉन्फ़िगरेशन को बायपास करके ), या मैं अभी के लिए अपने परिवर्तनों को मर्ज करना बंद कर सकता हूं और बाद में इसे संभाल सकता हूं। मुझे लगता है कि यह छोटी गति टक्कर आपकी टीम को मर्ज के बारे में गलत निर्णय लेने से बचने में मदद करेगी। आप अपनी टीम को मर्ज से निपटने में बेहतर होने के बाद इसे बंद कर सकते हैं।