2021 में शीर्ष 40 जीआईटी साक्षात्कार प्रश्न और उत्तर

top 40 git interview questions

उत्तर और उदाहरण के साथ सबसे लोकप्रिय जीआईटी साक्षात्कार प्रश्न:

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

चाहे आप एक नौसिखिए हों या एक अनुभवी पेशेवर हों, जीआईटी और विस्तृत उत्तरों पर ये साक्षात्कार प्रश्न निश्चित रूप से आपके विषय के ज्ञान को समृद्ध करने में मदद करेंगे और आपके काम के साथ-साथ साक्षात्कार भी देंगे।

आएँ शुरू करें!!

सबसे अक्सर पूछे जाने वाले जीआईटी साक्षात्कार प्रश्न

नीचे सूचीबद्ध आपके संदर्भ के लिए सामान्यतः पूछे जाने वाले जीआईटी साक्षात्कार के कुछ प्रश्न हैं।

Q # 1) Git क्या है?

उत्तर: Git एक वितरित संस्करण नियंत्रण उपकरण है। यह वितरित गैर-रेखीय वर्कफ़्लो के साथ संगत है क्योंकि यह अच्छी गुणवत्ता वाले सॉफ़्टवेयर के निर्माण के लिए डेटा आश्वासन प्रदान करता है।

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

Q # 2) एक वितरित संस्करण नियंत्रण प्रणाली क्या है?

उत्तर: एक वितरित वीसीएस एक प्रणाली है जो एक प्रोजेक्ट फ़ाइल और उसके सभी संस्करणों को रखने के लिए एक केंद्रीय सर्वर पर निर्भर नहीं करती है। वितरित VCS में, प्रत्येक सहयोगी या डेवलपर को मुख्य रिपॉजिटरी की एक स्थानीय प्रति मिलती है और इसे क्लोन कहा जाता है।

(छवि स्रोत )

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

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

Q # 3) Git का निर्माण किसने किया था?

उत्तर: लिनक्स कर्नेल विकसित करने के लिए सड़क पर 2005 में लिनस टॉर्वाल्ड्स द्वारा गिट बनाया गया था।

Q # 4) Git में किस भाषा का उपयोग किया जाता है?

उत्तर: C अंतर्निहित प्रोग्रामिंग भाषा है जिसमें Git लिखा जाता है। C भाषा अन्य उच्च-स्तरीय प्रोग्रामिंग भाषाओं के साथ जुड़े रनटाइम ओवरहेड को विकसित करके Git को तेज बनाती है।

Q # 5) Git के फायदे / मुख्य विशेषताएं क्या हैं?

उत्तर: नीचे सूचीबद्ध विभिन्न एफ हैं Git का भोजन।

(i) मुक्त और खुला स्रोत:

जीपीएल (जनरल पब्लिक लाइसेंस) ओपन सोर्स लाइसेंस के तहत जीआईटी जारी किया जाता है। Git का उपयोग करने के लिए आपको कुछ भी भुगतान करने की आवश्यकता नहीं है।

यह बिल्कुल मुफ्त है। चूंकि यह ओपन-सोर्स है, आप अपनी आवश्यकताओं के अनुसार सोर्स कोड को संशोधित कर सकते हैं।

(ii) गति:

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

गिट सी में लिखा गया है, जो कि अंतर्निहित प्रोग्रामिंग भाषा है जो अन्य उच्च-स्तरीय भाषाओं के साथ जुड़े रनटाइम ओवरहेड को विकसित करता है।

(iii) स्केलेबल:

गिट अत्यधिक स्केलेबल है। इसलिए, यदि आने वाले समय में सहयोगियों की संख्या बढ़ जाती है, तो गिट आसानी से इस बदलाव को समायोजित कर सकते हैं।

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

(iv) विश्वसनीय:

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

(v) सुरक्षित:

गिट अपने भंडार के अंदर वस्तुओं का नाम और पहचान करने के लिए SHA1 (सिक्योर हैश फंक्शन) का उपयोग करता है। प्रत्येक कलाकृतियों और प्रतिबद्धताओं को चेकआउट के दौरान चेकसम के माध्यम से चेक-संक्षेपित और पुनर्प्राप्त किया जाता है।

Git इतिहास को उस तरीके से सहेजा जाता है, जिसमें किसी विशिष्ट संस्करण की ID (Git के संदर्भ में एक कमिट) उस विकास तक चलने वाले कुल इतिहास पर निर्भर करती है। एक बार जब एक फ़ाइल संस्करण को Git में धकेल दिया जाता है, तो उसे देखे बिना बदलने का कोई तरीका नहीं है।

(vi) किफायती:

केंद्रीयकृत संस्करण नियंत्रण प्रणाली के मामले में, केंद्रीय सर्वर को पूरी टीम के अनुरोधों को पूरा करने के लिए पर्याप्त मजबूत होना चाहिए। यह छोटी टीमों के लिए कोई समस्या नहीं है, हालांकि जैसे-जैसे टीम का विस्तार होता है, सर्वर की हार्डवेयर सीमाएं प्रदर्शन के लिए बाधा बन सकती हैं।

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

(vii) गैर-रेखीय विकास का समर्थन करता है:

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

Git Branches बेहद हल्के होते हैं। Git में एक शाखा केवल एक प्रतिबद्ध करने के लिए संदर्भित करती है। पूर्ण शाखा संरचना बनाई जा सकती है, जिसकी सहायता से अभिभावक आवागमन कर सकते हैं।

(viii) आसान शाखा:

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

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

(ix) वितरित विकास:

Git प्रत्येक डेवलपर को संपूर्ण विकास इतिहास की एक स्थानीय प्रति प्रदान करता है, साथ ही परिवर्तन एक ऐसे भंडार से दूसरे में क्लोन हो जाते हैं। इन परिवर्तनों को जोड़ा विकास शाखाओं के रूप में पेश किया जाता है और स्थानीय रूप से विकसित शाखा के रूप में उसी तरह विलय किया जा सकता है।

(x) वर्तमान सिस्टम या प्रोटोकॉल के साथ संगतता:

एक सॉकेट सॉकेट या ssh के शीर्ष पर रिपॉजिटरी को HTTP, FTP या Git प्रोटोकॉल के माध्यम से प्रकाशित किया जा सकता है।

Q # 6) Git में रिपोजिटरी कैसे बनाते हैं?

उत्तर: एक रिपॉजिटरी बनाने के लिए, आपको प्रोजेक्ट के लिए एक निर्देशिका बनाने की आवश्यकता है यदि यह पहले से मौजूद नहीं है, और फिर बस कमांड निष्पादित करें ' गिट इनिट ”। इस कमांड को निष्पादित करने से, प्रोजेक्ट निर्देशिका के अंदर एक .ITI डायरेक्टरी बनाई जाएगी यानी अब आपकी प्रोजेक्ट डायरेक्टरी Git रिपॉजिटरी में बदल गई है।

Q # 7) .गित निर्देशिका क्या है?

उत्तर: जिस क्षण आप एक रिपॉजिटरी का निर्माण करते हैं, आपको उसके अंदर एक .ITI डायरेक्टरी मौजूद मिलेगी। इस .IT निर्देशिका में रिपॉजिटरी के सभी मेटाडेटा शामिल हैं और आपकी रिपॉजिटरी में फाइलों के लिए किए गए सभी परिवर्तनों का एक ट्रैक रखता है, एक प्रतिबद्ध इतिहास रखकर।

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

आपके द्वारा परिचित किसी भी ऑपरेटिंग सिस्टम को सूचीबद्ध करें

Q # 8) .गित निर्देशिका हटा दिए जाने पर क्या होता है?

उत्तर: यदि .गित / निर्देशिका हटा दी जाती है, तो आप अपनी परियोजना के इतिहास का ट्रैक खो देंगे। रिपॉजिटरी अब संस्करण नियंत्रण में नहीं होगी।

Q # 9) Git में कमिट मैसेज लिखने के लिए किस कमांड का उपयोग किया जाता है?

उत्तर: एक संदेश के लिए एक कमिट पारित करने के लिए इस्तेमाल किया जाता है git कमिट -m 'कमिट मैसेज'। झंडा म एक संदेश भेजने के लिए उपयोग किया जाता है।

Q # 10) नंगे गिट रिपॉजिटरी क्या है? यह मानक / गैर-नंगे गिट रिपॉजिटरी से कैसे अलग है?

उत्तर: के माध्यम से बनाए गए भंडार गिट इनिट कमांड मानक / गैर-नंगे गिट रिपॉजिटरी हैं।

इस तरह के भंडार के शीर्ष-स्तरीय फ़ोल्डर में, आपको दो चीजें मिलेंगी:

1. सभी। मेटाडाटा और अपने रेपो के इतिहास पर नज़र रखने के लिए एक .it उपनिर्देशिका।
2. एक काम का पेड़।

रिपोजिटरी जो उपयोग करके बनाई गई हैं git init -bare कमांड को नंगे गिट रिपोजिटरी के रूप में जाना जाता है। वे मुख्य रूप से साझा करने के लिए उपयोग किए जाते हैं। उनके पास कोई भी काम करने वाला पेड़ नहीं है। वे .it सबफ़ोल्डर के अंदर रखने के बजाय रूट फ़ोल्डर में आपके रिपॉजिटरी के git संशोधन इतिहास को रखते हैं।

इसमें सिर्फ नंगे रिपॉजिटरी डेटा होता है। यह कैसे एक नंगे गिट रिपॉजिटरी एक मानक गिट रिपॉजिटरी से अलग है। इसके अलावा, एक नंगे भंडार में एक डिफ़ॉल्ट रिमोट नहीं है मूल रिपॉजिटरी के रूप में यह कई दूरस्थ उपयोगकर्ताओं के लिए एक मूल रिपोजिटरी के रूप में कार्य करता है।

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

Q # 11) कुछ Git रिपोजिटरी होस्टिंग सेवाओं का उल्लेख करें।

उत्तर:

• गिथब
• पिकाकोड
• गिटलब
• Microsoft VSTS
• बिट बकेट
• GitEnterprise
• sourceforge
• लांच पैड
• ख़ामख़ाह
• बीनस्टॉक
• ऐसा लग रहा है

Q # 12) Git में कुछ बेसिक ऑपरेशंस का नाम दें।

उत्तर: Git में कुछ बुनियादी ऑपरेशन में शामिल हैं:

• प्रारंभ
• जोड़ना
• कमिट
• धक्का दें
• खींचें

Q # 13) Git में कुछ एडवांस ऑपरेशंस के नाम बताइए।

उत्तर: Git में कुछ उन्नत संचालन हैं:

• शाखाओं में
• विलय
• रिबेसिंग

Q # 14) आप Git और SVN में कैसे अंतर करेंगे?

उत्तर: Git एक वितरित संस्करण नियंत्रण है जबकि SVN केंद्रीकृत है। इससे दोनों के बीच अपनी विशेषताओं और कार्यक्षमता के बीच कई अंतर पैदा होते हैं।

Q # 15) आप गिट और गिटहब के बीच अंतर कैसे करेंगे?

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

Git के प्राथमिक लक्ष्य गति, डेटा अखंडता, वितरित, गैर-रेखीय वर्कफ़्लो को सहायता प्रदान करना है। क्लाउड के बजाय स्थानीय मशीन पर गिट स्थापित और बनाए रखा जाता है।

GitHub एक क्लाउड-आधारित Git रिपॉजिटरी होस्टिंग सेवा है जो टीमों को एक साथ लाता है। यह आपको एक वेब-आधारित GUI प्रदान करता है और साथ ही प्रत्येक परियोजना के लिए एक्सेस कंट्रोल और कई सहयोग सुविधाएँ, मूलभूत कार्य प्रबंधन उपकरण भी प्रदान करता है।

इसके अलावा, GitHub एक ओपन-सोर्स है यानी कोड को एक केंद्रीकृत सर्वर पर रखा गया है और इसे सभी के द्वारा एक्सेस किया जा सकता है।

Q # 16) Git में क्या संघर्ष है और इसे कैसे हल किया जाए?

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

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

ऐसे मामलों में, अंतिम मर्ज में किस कोड को शामिल करना है और किस कोड को छोड़ना है, यह तय करने में आपकी मदद की आवश्यकता होती है।

एक शाखा को मर्ज करने, एक शाखा को पुन: व्यवस्थित करने, या एक चेरी-चुनने के दौरान एक मर्ज संघर्ष हो सकता है। एक बार एक संघर्ष का पता चला है, गिट संघर्ष क्षेत्र पर प्रकाश डाला और आप इसे हल करने के लिए कहता है। एक बार संघर्ष हल हो जाने पर, आप मर्ज के साथ आगे बढ़ सकते हैं।

एक प्रतिस्पर्धा रेखा परिवर्तन मर्ज संघर्ष को हल करने के लिए नीचे दिए गए चरणों का पालन करें:

1. Git Bash (Git कमांड लाइन) खोलें।
2. प्रयोग करें सीडी मर्ज संघर्ष होने वाले स्थानीय गिट रिपॉजिटरी में जाने की आज्ञा।
3. उपयोग गिट की स्थिति मर्ज संघर्ष से प्रभावित फ़ाइलों की सूची का उत्पादन करने के लिए आदेश।
4. उस टेक्स्ट एडिटर को खोलें जिसका आप उपयोग करते हैं और उस फाइल को ट्रेस करते हैं, जिसमें मर्ज का विरोध है।
5. अपनी फ़ाइल में मर्ज संघर्ष की शुरुआत देखने के लिए, संघर्ष मार्कर के लिए दस्तावेज़ देखें<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> शाखा-नाम।
6. उस स्थिति में चुनें, जिसमें आपको अपनी शाखा के बदलावों को रखने की ज़रूरत है, बस दूसरी शाखा के परिवर्तनों को बनाए रखें, या एक नया परिवर्तन करें, जिसमें दो शाखाओं के परिवर्तन शामिल हो सकते हैं। संघर्ष मार्करों को मिटा दें<<<<<<>>>>>> और उन परिवर्तनों को करें जो आपको अंतिम मर्ज में चाहिए।
7. प्रयोग करें गिट जोड़ता है। अपने परिवर्तनों को जोड़ने या मंच करने की आज्ञा।
8. अंत में, उपयोग करें git कमिट-मी 'संदेश' एक टिप्पणी के साथ अपने परिवर्तनों को करने के लिए आदेश।

हटाए गए फ़ाइल मर्ज संघर्ष को हल करने के लिए, आपको निम्न चरणों का पालन करने की आवश्यकता है:

1. Git Bash (Git कमांड लाइन) खोलें।
2. प्रयोग करें सीडी मर्ज संघर्ष वाले स्थानीय गिट रिपॉजिटरी में जाने के लिए कमांड करें।
3. उपयोग गिट की स्थिति मर्ज संघर्ष से प्रभावित फ़ाइलों की सूची का उत्पादन करने के लिए आदेश।
4. उस टेक्स्ट एडिटर को खोलें जिसका आप उपयोग करते हैं और उस फाइल को ट्रेस करते हैं, जिसमें मर्ज का विरोध है।
5. यदि आप हटाए गए फ़ाइल को रखना चाहते हैं तो चुनें। आप अपने पाठ संपादक में हटाए गए फ़ाइल में किए गए नवीनतम परिवर्तनों की जांच कर सकते हैं।
6. प्रयोग करें जोड़ देना हटाए गए फ़ाइल को रिपॉजिटरी में वापस जोड़ने के लिए कमांड। या, उपयोग करें आरएम जाओ अपने रिपॉजिटरी से फ़ाइल को हटाने के लिए कमांड।
7. अंत में, उपयोग करें git कमिट-मी 'संदेश' एक टिप्पणी के साथ अपने परिवर्तनों को करने के लिए आदेश।

Q # 17) आप ब्रोकन कमिट को कैसे ठीक करेंगे?

उत्तर: टूटी हुई कमिट को ठीक करने के लिए या आखिरी कमिट को बदलने के लिए, कमांड का उपयोग करने के लिए सबसे सुविधाजनक तरीका है “ कमिट-कमेंट ' ।

यह आपको पिछली प्रतिबद्धताओं के साथ एक पूरी तरह से नई प्रतिबद्ध बनाने के विकल्प के रूप में मंचित परिवर्तनों को संयोजित करने की अनुमति देता है। यह संशोधित कमेटी के साथ सबसे हालिया प्रतिबद्ध की जगह लेता है।

(छवि स्रोत )

इस आदेश के माध्यम से, आप इसके स्नैपशॉट को बदले बिना पिछले प्रतिबद्ध संदेश को भी संपादित कर सकते हैं।

Q # 18) git instaweb का उपयोग क्या है?

उत्तर: यह एक स्क्रिप्ट है जिसके माध्यम से आप वेब ब्राउजर में अपने कामकाजी गिट रिपॉजिटरी को तुरंत ब्राउज़ कर सकते हैं।

यह स्क्रिप्ट स्थानीय रिपॉजिटरी ब्राउज़ करने के लिए gitweb और एक वेबसर्वर सेट करती है। यह स्वचालित रूप से एक वेब ब्राउज़र को निर्देशित करता है और आपके स्थानीय भंडार में एक इंटरफ़ेस के माध्यम से एक वेब सर्वर चलाता है।

Q # 19) git is-tree क्या है?

उत्तर: ‘गिट इज-ट्री’ एक ट्री ऑब्जेक्ट को दर्शाता है जिसमें बूँद या पेड़ के SHA-1 मान के साथ मोड और सभी वस्तुओं का नाम शामिल है।

क्यू # 20) क्या पहले से धकेल दिए गए और सार्वजनिक किए जाने के लिए एक जीआईटी प्रतिबद्ध को वापस करने का एक तरीका है?

उत्तर: हां, एक खराब प्रतिबद्ध को ठीक करने या वापस करने के लिए, दो दृष्टिकोण हैं जो परिदृश्य के आधार पर उपयोग किए जा सकते हैं।

वे:

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

क्यू # 21) आप गिट पुल और गिट भ्रूण के बीच अंतर कैसे करेंगे?

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

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

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

इसलिए, एक गिट पुल अपने दूरस्थ संस्करण के साथ स्थानीय शाखा को अप-टू-डेट लाता है, जबकि एक गिट लाने से सीधे आपकी खुद की स्थानीय शाखा या वर्किंग कॉपी नहीं बदल जाती है रेफ / सिर। Git fetch का उपयोग आपकी दूरस्थ-ट्रैकिंग शाखाओं को अद्यतन करने के लिए किया जा सकता है refs / remotes //।

सरल शब्दों में, git पुल एक git मर्ज के बाद git fetch के बराबर है ।

Q # 22) गेटिंग में स्टेजिंग एरिया या इंडेक्सिंग का क्या उपयोग है?

उत्तर: Git के दृष्टिकोण से, तीन क्षेत्र हैं जहाँ फ़ाइल परिवर्तन रखे जा सकते हैं अर्थात् कार्यशील निर्देशिका, स्टेजिंग क्षेत्र और रिपॉजिटरी।

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

आप परिवर्तनों को निष्पादित करके चरणबद्ध कर सकते हैं जोड़ देना। आज्ञा। यह मंचन क्षेत्र आपको आपकी अगली प्रतिबद्धताओं का पूर्वावलोकन देता है और मूल रूप से आपको अपने कामों को ठीक करने देता है। आप स्टेजिंग क्षेत्र में तब तक बदलाव जोड़ या हटा सकते हैं जब तक आप उस संस्करण से संतुष्ट नहीं हो जाते जो आप करने जा रहे हैं।

एक बार जब आप अपने परिवर्तनों को सत्यापित कर लेते हैं और परिवर्तित चरण पर हस्ताक्षर कर देते हैं, तो आप अंततः परिवर्तनों को कर सकते हैं। प्रतिबद्ध होने पर, वे स्थानीय रिपॉजिटरी यानि .गित / ऑब्जेक्ट्स डायरेक्टरी में जाते हैं।

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

आप एक फ़ाइल का चयन कर सकते हैं और 'चरण परिवर्तित' पर क्लिक कर सकते हैं, फिर इसे स्टेजिंग क्षेत्र में ले जाया जाएगा। उदाहरण के लिए , फ़ाइल hello.txt चरण में परिवर्तित (मौजूद है) क्षेत्र में मौजूद है। आप अपने परिवर्तनों को सत्यापित कर सकते हैं और फिर साइन-ऑफ कर सकते हैं, इसके बाद एक कमिट कर सकते हैं।

स्टेजिंग को इंडेक्सिंग के रूप में भी जाना जाता है क्योंकि गिट इन तीन क्षेत्रों में आपकी फ़ाइल परिवर्तनों का ट्रैक रखने के लिए एक इंडेक्स फ़ाइल का रखरखाव करता है। फ़ाइलों का मंचन वर्तमान में आपके सूचकांक में है।

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

Q # 23) Git Stash क्या है?

उत्तर: जीआईटी स्टैश काम कर रहे डायरेक्टरी और इंडेक्स की वर्तमान स्थिति को कैप्चर करता है और इसे भविष्य में उपयोग के लिए स्टैक पर रखता है। यह आपके वर्किंग डायरेक्टरी से अनकम्फर्टेड बदलावों (स्टेज्ड और अनस्टेंडेड दोनों) को रिजेक्ट करता है और आपको एक क्लीन वर्किंग ट्री देता है।

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

यह त्वरित संदर्भ स्विचिंग में सहायक है, जहाँ आप एक कोड परिवर्तन के मध्य में हैं जिसे आप अभी करना नहीं चाहते हैं या इसे पूर्ववत करना चाहते हैं और आपको काम करने के लिए कुछ और मिल गया है। उपयोग करने का आदेश git stash है।

Q # 24) Git Stash ड्रॉप क्या है?

उत्तर: जब आपको किसी विशिष्ट स्टैश की आवश्यकता नहीं होती है, तो आप इसे निष्पादित करके निकाल सकते हैं git stash ड्रॉप कमांड । यदि आप रिपॉजिटरी से एक बार में सभी बाधाओं को दूर करना चाहते हैं तो आप चला सकते हैं git stash स्पष्ट कमांड ।

Q # 25) Git stash लागू क्या है? यह गिट स्टैश पॉप से ​​कैसे अलग है?

उत्तर: दोनों आदेशों का उपयोग आपके अटके हुए परिवर्तनों को फिर से लागू करने के लिए किया जाता है और जहां आप छोड़ गए थे वहां से काम करना शुरू करते हैं।

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

में git stash पॉप आदेश, परिवर्तनों को स्टैश से हटा दिया जाता है और काम की प्रतिलिपि पर फिर से लागू किया जाता है।

Q # 26) git क्लोन कमांड का उपयोग क्या है?

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

Q # 27) git config कमांड का उपयोग कब किया जाता है?

उत्तर: git config कमांड का उपयोग आपके Git इंस्टॉलेशन के लिए कॉन्फ़िगरेशन विकल्प सेट करने के लिए किया जाता है।

उदाहरण के लिए, Git को डाउनलोड करने के बाद, आपको उपयोगकर्ता नाम सेटअप करने के लिए विन्यास कमांड के नीचे उपयोग करने की आवश्यकता है और क्रमशः Git में ईमेल पता दें:

$ git config -global user.name ''

$ git config -global user.email ''

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

Q # 28) यदि शाखा को पहले से ही मास्टर में मिला दिया गया है तो आप कैसे पहचानेंगे?

उत्तर:

नीचे दिए गए आदेशों को निष्पादित करके, आप शाखा मर्ज स्थिति जान सकते हैं:

1. गिट शाखा-कुशल मास्टर: यह उन सभी शाखाओं को सूचीबद्ध करेगा, जिन्हें मास्टर में बदल दिया गया है।
2. गिट शाखा यह उन सभी शाखाओं को सूचीबद्ध करेगा, जिन्हें HEAD में मिला दिया गया है।
3. git Branch -no-merged: यह उन सभी शाखाओं को सूचीबद्ध करेगा जो अभी तक विलय नहीं हुई हैं।

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

प्रश्न # 29) हुक में क्या हैं?

उत्तर: Git हुक कुछ स्क्रिप्ट्स हैं जो Git कमिटमेंट, पुश, अपडेट या प्राप्त करने जैसी घटना से पहले या बाद में चलती हैं। आपको अपने स्थानीय रिपॉजिटरी में .it निर्देशिका के अंदर 'हुक' फ़ोल्डर मिलेगा। आपको यहां प्री-कमिटमेंट, पोस्ट-कमिट, प्री-पुश, पोस्ट पुश जैसी स्क्रिप्ट्स मिलेंगी।

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

Q # 30) git fork का क्या उपयोग है? क्लोनिंग से अलग फोर्किंग कैसे होती है?

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

कांटा ऑपरेशन Git वर्कफ़्लो द्वारा उपयोग किया जाता है और यह विचार GitHub जैसे मुक्त और ओपन-सोर्स सॉफ़्टवेयर के लिए लंबे समय तक मौजूद है। आम तौर पर, एक बार जब आप परियोजना को छोड़ देते हैं, तो आप शायद ही कभी फिर से मूल परियोजना में योगदान करेंगे।

उदाहरण के लिए, ओपनबीएसडी एक यूनिक्स जैसा ओपन-सोर्स ऑपरेटिंग सिस्टम है जिसे नेटबीएसडी को फोर्क करके विकसित किया गया था जो एक अन्य यूनिक्स जैसा ओपन-सोर्स ओएस है।

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

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

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

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

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

Q # 31) आपको कैसे पता चलेगा कि किसी विशेष Git कमिट में सभी फाइलों को बदल दिया गया है?

उत्तर: किसी विशेष कमिट के हैश मान का उपयोग करके, आप उन कमांड को निष्पादित कर सकते हैं जो किसी विशेष फ़ाइल में बदली गई फाइलों की सूची प्राप्त करने के लिए हैं:

गिट डिफरेंस ट्री -r {हैश}

यह उन सभी फाइलों को सूचीबद्ध करेगा, जिन्हें संशोधित किया गया है, और जो फाइलें जोड़ी गई हैं, वे भी। -R ध्वज का उपयोग केवल उनके रूट डायरेक्टरी नामों में उन्हें ढहाने के बजाय उनके पथ के साथ-साथ व्यक्तिगत फ़ाइलों को सूचीबद्ध करने के लिए किया जाता है।

आप नीचे दिए गए आदेश का भी उपयोग कर सकते हैं:

git diff-tree -no-प्रतिबद्ध-id -name-only -r {हैश}

-न-कमिट-आईडी आउटपुट में आने के लिए प्रतिबद्ध हैश नंबरों को पुनः प्राप्त करेगा। जबकि, -name फ़ाइल पथ को बाहर कर देगा और आउटपुट में केवल फ़ाइल नाम देगा।

क्यू # 32) Git चेकआउट (शाखा का नाम) और git चेकआउट -b (शाखा का नाम) में क्या अंतर है?

उत्तर: आदेश git चेकआउट (शाखा का नाम) एक शाखा से दूसरी शाखा में जाएगा।

आदेश git चेकआउट -b (शाखा का नाम) एक नई शाखा बनाएगा और उस पर स्विच भी करेगा।

Q # 33) सबजीट क्या है?

उत्तर: SubGit एक उपकरण है जो SVN से Git माइग्रेशन के लिए उपयोग किया जाता है। इसे TMate नामक कंपनी ने विकसित किया है। यह SVN रिपॉजिटरी को Git में कनवर्ट करता है और आपको समवर्ती दोनों सिस्टम पर काम करने देता है। यह एसवीएन को गिट के साथ ऑटो-सिंक करता है।

(छवि स्रोत )

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

यह ट्रैकिंग मर्ज डेटा सहित इतिहास को भी संरक्षित करता है।

Q # 34) क्या आप Git में हटाए गए ब्रांच को रिकवर कर सकते हैं?

उत्तर: हाँ तुम कर सकते हो। हटाई गई शाखा को पुनर्प्राप्त करने के लिए, आपको अपने सिर के शीर्ष से SHA पता होना चाहिए। SHA या हैश एक अद्वितीय आईडी है जो हर ऑपरेशन के साथ Git बनाता है।

जब आप एक शाखा को हटाते हैं, तो आपको टर्मिनल पर SHA प्रदर्शित होता है:

हटा दी गई शाखा (थी)

आप हटाए गए शाखा को पुनर्प्राप्त करने के लिए नीचे दिए गए आदेश का उपयोग कर सकते हैं:

git checkout -b

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

Q # 35) क्या है git का अंतर कमांड? यह किस तरह से अलग है गिट स्थिति?

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

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

Q # 36) एक प्रतिबद्ध वस्तु में क्या होता है?

उत्तर: प्रतिबद्ध ऑब्जेक्ट में शीर्ष-स्तरीय ट्री ऑब्जेक्ट हैश, माता-पिता हैश (यदि कोई हो), लेखक और कमेंट जानकारी, प्रतिबद्ध दिनांक और प्रतिबद्ध संदेश शामिल हैं।

आप इसके माध्यम से देख सकते हैं गिट लॉग आज्ञा।

उदाहरण:

(छवि स्रोत )

Q # 37) git चेरी-पिक क्या है? वे कौन से परिदृश्य हैं जिनमें git चेरी-पिक का उपयोग किया जा सकता है?

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

git चेरी-पिक कमठा चेरी-पिकिंग के लिए प्रयुक्त कमांड है। कमिटमेंट कमिटमेंट है।

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

इसका उपयोग टीम सहयोग में भी किया जा सकता है। ऐसे परिदृश्य हो सकते हैं जहां उत्पाद के दो घटकों के बीच समान कोड को साझा करने की आवश्यकता होती है। इस मामले में, यदि कोई डेवलपर पहले से ही उस कोड को लिख चुका है, तो दूसरा उसी को चेरी-पिक कर सकता है।

चेरी फ़िक्सिंग बग हॉटफ़िक्स में भी उपयोगी है जहाँ एक पैच कमिट को जल्द से जल्द समस्या को ठीक करने के लिए सीधे मास्टर ब्रांच में ले जाया जा सकता है।

Q # 38) 'गेट रीसेट' किसके लिए उपयोग किया जाता है? इस कमांड का डिफ़ॉल्ट मोड क्या है?

उत्तर: गेट रीसेट Git रेपो की स्थिति में स्थानीय परिवर्तनों को पूर्ववत करने के लिए एक शक्तिशाली आदेश है। यह कमांड वर्तमान HEAD को निर्दिष्ट चरण में रीसेट करता है।

यह इंडेक्स और वर्किंग डायरेक्टरी दोनों को आपकी अंतिम प्रतिबद्ध स्थिति की स्थिति में रीसेट करता है। Git रीसेट में तीन मोड हैं यानी सॉफ्ट, हार्ड और मिक्स। ऑपरेशन का डिफ़ॉल्ट मोड मिश्रित है।

Q # 39) 'हेड', 'वर्किंग ट्री' और 'इंडेक्स' में क्या अंतर है?

उत्तर: कार्यशील ट्री या कार्यक्षेत्र वह निर्देशिका स्रोत है जिसमें आप वर्तमान में काम कर रहे हैं।

सूचकांक Git में मंचन क्षेत्र है जहां कमिट तैयार किए जाते हैं। यह कमिट और आपके काम करने वाले पेड़ के बीच स्थित है। Git इंडेक्स एक बड़ी बाइनरी फाइल है जो वर्तमान ब्रांच की सभी फाइलों, उनके नाम, sha1 चेकसम और टाइमस्टैम्प पर लागू होती है।

यह फ़ाइल /.it/index पर मौजूद है। HEAD वर्तमान चेकआउट शाखा में नवीनतम प्रतिबद्ध के लिए संदर्भ या सूचक है।

Q # 40) रिबास और मर्ज में क्या अंतर है? आपको कब रिबास करना चाहिए और कब विलय करना चाहिए?

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

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

दूसरी ओर, रिबास मास्टर शाखा की नोक पर शुरू करने के लिए पूरी सुविधा शाखा को स्थानांतरित करेगा।

(छवि स्रोत )

इस तरह दिखेगा:

सार्वजनिक शाखाओं के लिए रिबासिंग की सिफारिश नहीं की जाती है क्योंकि यह असंगत रिपोजिटरी बनाती है। हालांकि, निजी शाखाओं / व्यक्तिगत डेवलपर्स के लिए रिबासिंग एक अच्छा विकल्प है। यह शाखा-प्रति-सुविधा मोड के लिए बहुत उपयुक्त नहीं है। लेकिन अगर आपके पास एक शाखा-प्रति-डेवलपर मॉडल है, तो रिबासिंग का कोई नुकसान नहीं है।

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

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

मर्ज इतिहास को फिर से बनाए रखते हैं क्योंकि यह इतिहास को फिर से लिखता है। इस प्रकार, यदि आप इतिहास को पूरी तरह से देखना चाहते हैं जैसा कि हुआ तो आपको मर्ज का उपयोग करना चाहिए।

Q # 41) रिबासिंग के लिए वाक्य रचना क्या है?

उत्तर: रीबेस कमांड का सिंटैक्स है git रिबास (नया-कमिट)

Q # 42) आप वास्तव में अपने स्थानीय फाइल सिस्टम से हटाए बिना किसी फाइल को गिट से कैसे हटाएंगे?

उत्तर: आप इसके लिए the कैशेड ’विकल्प का उपयोग कर सकते हैं:

git rm -rf-cached $ FILES

यह कमांड आपकी डिस्क से हटाने के बिना आपकी रिपॉजिटरी से फाइलों को हटा देगा।

Q # 43) Git में सामान्य शाखा पैटर्न क्या है?

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

• मास्टर शाखा में उत्पादन कोड होता है। सभी विकास कोड किसी समय में मास्टर शाखा में विलय कर दिए जाते हैं।
• विकास शाखा में पूर्व-उत्पादन कोड होता है। जब सुविधाएँ पूरी हो जाती हैं, तो वे आमतौर पर CI / CD पाइपलाइन के माध्यम से मास्टर शाखा में विलय हो जाते हैं।

इस मॉडल की कुछ सहायक शाखाएँ भी हैं जिनका उपयोग विकास चक्र के दौरान किया जाता है:

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

निष्कर्ष

हम इस ट्यूटोरियल में Git इंटरव्यू के दौरान पूछे जाने वाले महत्वपूर्ण प्रश्नों से गुजरे हैं।

यह न केवल आपको आगामी साक्षात्कार के लिए तैयार करने में मदद करेगा, बल्कि आपकी अवधारणाओं को भी स्पष्ट करेगा।

आपके साक्षात्कार के लिए शुभकामनाएँ!

अनुशंसित पाठ

• साक्षात्कार प्रश्न और उत्तर
• कुछ दिलचस्प सॉफ्टवेयर परीक्षण साक्षात्कार प्रश्न
• शीर्ष 40 सी प्रोग्रामिंग साक्षात्कार प्रश्न और उत्तर
• टॉप 40 पॉपुलर J2EE के इंटरव्यू सवाल और जवाब जो आपको पढ़ने चाहिए
• ईटीएल परीक्षण साक्षात्कार प्रश्न और उत्तर
• 20+ सबसे सामान्य रूप से पूछे जाने वाले साक्षात्कार के प्रश्न और उत्तर
• शीर्ष ओरेकल फॉर्म और रिपोर्ट साक्षात्कार प्रश्न
• कुछ मुश्किल मैनुअल परीक्षण प्रश्न और उत्तर