गिट इतना जटिल क्यों है

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

ऐसा क्यों होना चाहिए?

कमांड-लाइन इंटरफ़ेस-सीएलआई

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

• cat - एक शराबी जानवर,
• cd —कैसे लोग संगीत सुनते थे, और
• grep - कुछ ओनोमेटोपोइया,

तो संभावना है कि गिट के साथ आपका पहला अनुभव कमांड लाइन मूल बातें सीखने की अतिरिक्त कठिनाई होगी। कुछ ऐसा जो विंडोज 95 और उसके जैसे ने आपसे छीन लिया।

गिट के डिजाइन लक्ष्य

Git का मतलब कभी भी सरल नहीं था। इसे विभिन्न लक्ष्यों को ध्यान में रखकर बनाया गया था: अधिक महत्वपूर्ण और अधिक चुनौतीपूर्ण भी।

सहेजे गए डेटा को सुरक्षित रूप से संग्रहीत करना

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

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

असुरक्षित नेटवर्क पर काम करें और गैर-भरोसेमंद प्रतिभागियों के साथ

क्योंकि क्रिप्टोग्राफ़िक हैश द्वारा सब कुछ पहचाना जाता है, इसलिए डेटा को अक्षुण्ण रखने के लिए Git को अधिक नेटवर्क पर भरोसा नहीं करना पड़ता है। गिट को मैन-इन-द-बीच हमलों से सुरक्षित किया गया है: ऐसा कोई तरीका नहीं है जिससे कोई गिट के दो नोड्स के बीच सार्थक कोड इंजेक्ट कर सके। बेशक, अगर कोई कमिट पढ़ सकता है कि वे इसके लिए नहीं थे, तो यह भी एक समस्या है, लेकिन हमलावरों द्वारा कोडबेस में कोड इंजेक्ट करने की तुलना में कम खतरनाक परिणाम हैं।

सुरक्षा की एक अतिरिक्त परत के लिए, Git कमिट साइन अप करने की पेशकश करता है - यह सुनिश्चित करने का एक अतिरिक्त साधन है कि कमिट को उस व्यक्ति द्वारा लिखा गया था जो इसके लेखक होने के लिए निर्धारित है।

पश्चगामी संगतता बनाए रखना

Git इंटरफ़ेस जितना होना चाहिए उससे कहीं अधिक जटिल है क्योंकि यह अपने उपयोगकर्ताओं की पुरानी आदतों का सम्मान करता है। मैंने 2011 में गिट सीखा, और पिछले हफ्ते तक मैंने ध्यान नहीं दिया था कि शाखाओं को बदलने के लिए एक नया git switch कमांड है। जिस तरह से मैं इसे करने के लिए उपयोग किया जाता हूं ( git checkout + विभिन्न झंडे) अभी भी ठीक काम कर रहा है। Git पुराने उपयोगकर्ताओं और उनकी आदतों को नए उपयोगकर्ताओं के लिए सरलता पर प्राथमिकता देता है—जो हमें अगले बिंदु पर ले जाता है।

सुपर-उपयोगकर्ताओं के लिए उपयोगकर्ता अनुभव

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

सादगी व्यापार-नापसंद

जब आप सिस्टम डिज़ाइन करते हैं, तो कुछ भी निःशुल्क नहीं होता है—शामिल उपयोगकर्ताओं के लिए सरलता।

जटिलता को छुपाना

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

• कम बुरा है
• अधिक अच्छा है

यह इंटरनेट का उपयोग करने के लिए पर्याप्त है, लेकिन इससे कनेक्शन की किसी भी समस्या को समझना और उसका निवारण करना कठिन हो जाता है।

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

आसान बनाम सुरक्षित

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

• जानबूझकर—रिबेस, संशोधन, स्क्वैश, या इतिहास को बदलने वाले किसी भी अन्य ऑपरेशन
• अनजाने में- गलती या कोडबेस पर हमला

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

क्या यह सही तरीका है?

जब मैं गिट सीख रहा था, तब भी यह एक नवीनता थी - मैं इसे 2011 में सीख रहा था, और गिट 2005 में बनाया गया था (पहली प्रतिबद्धता थू अप्रैल 7 15:13:13 2005 -0700 से है)। उस समय मैं काम पर SVN का उपयोग कर रहा था, और Mercurial को अक्सर Git के अधिक उपयोगकर्ता-अनुकूल विकल्प के रूप में माना जाता था। क्या आपने उन नामों को हाल ही में सुना है? Git संस्करण नियंत्रण बाजार पर लगभग पूरी तरह से हावी है। गिटहब के उदय के साथ इसने बहुत लोकप्रियता हासिल की, लेकिन भले ही यह शुरुआती लोगों के लिए कठिन हो, यह एक बहुत ही कुशल उपकरण है, और यह यहाँ रहने के लिए है।

शुरुआती प्रोग्रामर के रूप में क्या करें?

मेरी सलाह है कि इसे जल्द से जल्द सीखें। इसकी अत्यधिक संभावना नहीं है कि Git जल्द ही सरल हो जाएगा। या कभी। जब आप प्रोग्राम करते हैं तो वर्जन कंट्रोल सिस्टम सामान्य रूप से बहुत सारे सिरदर्द से बचाते हैं। यदि आप अपने कोडबेस के संस्करणों को स्थानांतरित करने के लिए संघर्ष करते हैं तो मैं कोड के साथ काम करने में कुशल होने की कल्पना नहीं कर सकता। अच्छी तरह से Git सीखने से आपको खोई हुई फ़ाइलों से जूझने या तथाकथित "Git मुद्दों" को ठीक करने के बजाय कोड चुनौतियों पर ध्यान केंद्रित करने में मदद मिलेगी - जो लगभग हमेशा ही लोग अपने रिपॉजिटरी को गड़बड़ कर रहे हैं।

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

अधिक कैसे सीखें?

यदि आप Git के बारे में अधिक जानने में रुचि रखते हैं, तो मेरे Git-केंद्रित सामग्री के बारे में अपडेट प्राप्त करने के लिए यहां साइन अप करें।