1. नौसिखियों के लिए गिट के लिए एक विस्तृत गाइड

आज हम एक वर्जन कंट्रोल सिस्टम के बारे में बात करने जा रहे हैं, जिसका नाम है Git।

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

गिट मूल बातें

Git हमारे कोड के लिए एक वितरित संस्करण नियंत्रण प्रणाली है। हमें इसकी जरूरत क्यों है? टीमों को अपने काम के प्रबंधन के लिए किसी प्रकार की प्रणाली की आवश्यकता होती है। समय के साथ होने वाले परिवर्तनों को ट्रैक करने के लिए इसकी आवश्यकता होती है।

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

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

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

अगर आप Git का इस्तेमाल करते हैं तो ऐसी कोई समस्या नहीं होगी।

गिट स्थापित करना

आइए आपके कंप्यूटर पर जावा स्थापित करें यह प्रक्रिया अलग-अलग ऑपरेटिंग सिस्टम के लिए थोड़ी भिन्न होती है।

विंडोज़ पर स्थापित करना

हमेशा की तरह, आपको एक exe फ़ाइल डाउनलोड करने और चलाने की आवश्यकता होती है। यहां सब कुछ सरल है: पहले Google लिंक पर क्लिक करें , इंस्टॉल करें, और बस इतना ही। ऐसा करने के लिए, हम विंडोज द्वारा प्रदान किए गए बैश कंसोल का उपयोग करेंगे।

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

अब यह एक कमांड प्रॉम्प्ट है जिसके साथ आप काम कर सकते हैं।

वहाँ Git को खोलने के लिए हर बार प्रोजेक्ट के साथ फ़ोल्डर में जाने से बचने के लिए, आप प्रोजेक्ट फ़ोल्डर में राइट माउस बटन के साथ कमांड प्रॉम्प्ट को उस पथ के साथ खोल सकते हैं जिसकी हमें आवश्यकता है:

लिनक्स पर स्थापित करना

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

एक टर्मिनल खोलें और इंस्टॉल करें। उबंटू के लिए, आपको लिखना होगा: sudo apt-get install git। और बस इतना ही: अब आप किसी भी टर्मिनल में Git का उपयोग कर सकते हैं।

MacOS पर इंस्टॉल करना

यहां भी, आपको पहले यह जांचने की आवश्यकता है कि क्या Git पहले से मौजूद है (ऊपर देखें, जैसा कि लिनक्स पर है)।

यदि आपके पास यह नहीं है, तो इसे प्राप्त करने का सबसे आसान तरीका नवीनतम संस्करण डाउनलोड करना है । यदि Xcode स्थापित है, तो Git निश्चित रूप से स्वचालित रूप से स्थापित हो जाएगा।

गिट सेटिंग्स

गिट में उपयोगकर्ता के लिए उपयोगकर्ता सेटिंग्स हैं जो काम सबमिट करेंगे। यह समझ में आता है और आवश्यक है, क्योंकि Git इस जानकारी को लेखक क्षेत्र के लिए लेता है जब एक कमिट बनाया जाता है।

निम्नलिखित आदेश चलाकर अपनी सभी परियोजनाओं के लिए एक उपयोगकर्ता नाम और पासवर्ड सेट करें:

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

थोड़ा सिद्धांत

विषय में गोता लगाने के लिए, हमें आपको कुछ नए शब्दों और कार्यों से परिचित कराना चाहिए... अन्यथा, बात करने के लिए कुछ नहीं होगा। बेशक, यह शब्दजाल है जो अंग्रेजी से हमारे पास आता है, इसलिए मैं कोष्ठक में अनुवाद जोड़ूंगा।

क्या शब्द और कर्म?

• गिट रिपॉजिटरी
• वादा करना
• शाखा
• मर्ज
• संघर्ष
• खींचना
• धकेलना
• कैसे कुछ फ़ाइलों को अनदेखा करने के लिए (.gitignore)

और इसी तरह।

गिट में स्थितियां

गिट की कई मूर्तियाँ हैं जिन्हें समझने और याद रखने की आवश्यकता है:

• ट्रैक न किए गए
• संशोधित
• मंचन
• प्रतिबद्ध

आपको इसे कैसे समझना चाहिए?

ये वे स्थितियाँ हैं जो हमारे कोड वाली फ़ाइलों पर लागू होती हैं। दूसरे शब्दों में, उनका जीवन चक्र आमतौर पर ऐसा दिखता है:

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

यह कैसा दिखता है:

कमिटमेंट क्या है?

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

विशेष रूप से, पहली प्रतिबद्धता है। जब दूसरा कमिट बनाया जाता है, तो यह (दूसरा) जानता है कि पहले के बाद क्या आता है। और इस तरह से जानकारी को ट्रैक किया जा सकता है।

एक कमिट की अपनी जानकारी भी होती है, जिसे मेटाडेटा कहा जाता है:

• कमिट का विशिष्ट पहचानकर्ता, जिसका उपयोग इसे खोजने के लिए किया जा सकता है
• कमिट के लेखक का नाम, जिसने इसे बनाया
• जिस तारीख को कमिट बनाया गया था
• एक टिप्पणी जो बताती है कि प्रतिबद्धता के दौरान क्या किया गया था

यहाँ यह कैसा दिखता है:

एक शाखा क्या है?

एक शाखा कुछ प्रतिबद्ध करने के लिए सूचक है। क्योंकि एक कमिट जानता है कि कौन सी कमिट इससे पहले होती है, जब कोई ब्रांच किसी कमिट की ओर इशारा करती है, तो पिछले सभी कमिट भी उस पर लागू होते हैं।

तदनुसार, हम कह सकते हैं कि आप एक ही कमिट की ओर इशारा करते हुए जितनी चाहें उतनी शाखाएँ रख सकते हैं।

काम शाखाओं में होता है, इसलिए जब कोई नया कमिट बनाया जाता है, तो ब्रांच अपने पॉइंटर को हाल के कमिट में ले जाती है।

गिट के साथ शुरुआत करना

आप एक स्थानीय रिपॉजिटरी के साथ-साथ एक रिमोट के साथ भी काम कर सकते हैं।

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

यदि हम दूरस्थ रिपॉजिटरी के बारे में बात कर रहे हैं, तो सभी जानकारी दूरस्थ सर्वर पर कहीं संग्रहीत की जाती है: केवल प्रोजेक्ट की एक प्रति स्थानीय रूप से संग्रहीत की जाती है। आपकी स्थानीय प्रतिलिपि में किए गए परिवर्तन दूरस्थ रिपॉजिटरी में पुश (गिट पुश) किए जा सकते हैं।

यहां और नीचे हमारी चर्चा में, हम कंसोल में गिट के साथ काम करने के बारे में बात कर रहे हैं। बेशक, आप किसी प्रकार के GUI-आधारित समाधान (उदाहरण के लिए, IntelliJ IDEA) का उपयोग कर सकते हैं, लेकिन पहले आपको यह पता लगाना चाहिए कि कौन से कमांड निष्पादित किए जा रहे हैं और उनका क्या मतलब है।

एक स्थानीय रिपॉजिटरी में गिट के साथ काम करना

एक स्थानीय रिपॉजिटरी बनाने के लिए, आपको लिखना होगा:

यह कंसोल की वर्तमान निर्देशिका में एक छिपा हुआ .git फ़ोल्डर बनाएगा।

.Git फ़ोल्डर Git रिपॉजिटरी के बारे में सभी जानकारी संग्रहीत करता है। इसे मिटाओ मत;)

इसके बाद, फाइलें प्रोजेक्ट में जोड़ी जाती हैं, और उन्हें "अनट्रैक" स्थिति सौंपी जाती है। अपने कार्य की वर्तमान स्थिति की जाँच करने के लिए, इसे लिखें:

हम मास्टर शाखा में हैं, और यहाँ हम तब तक रहेंगे जब तक हम दूसरी शाखा में नहीं जाते।

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

• गिट एड-ए - सभी फाइलों को "चरणबद्ध" स्थिति में जोड़ें
• गिट ऐड। - इस फ़ोल्डर और सभी सबफ़ोल्डर्स से सभी फ़ाइलें जोड़ें। अनिवार्य रूप से पिछले वाले के समान;
• git add <file name> — एक विशिष्ट फ़ाइल जोड़ता है। यहां आप कुछ पैटर्न के अनुसार फाइल जोड़ने के लिए रेगुलर एक्सप्रेशन का उपयोग कर सकते हैं। उदाहरण के लिए, git add *.java: इसका मतलब है कि आप केवल जावा एक्सटेंशन वाली फाइलें जोड़ना चाहते हैं।

पहले दो विकल्प स्पष्ट रूप से सरल हैं। नवीनतम जोड़ के साथ चीजें और अधिक दिलचस्प हो जाती हैं, तो चलिए लिखते हैं:

स्थिति की जाँच करने के लिए, हम पहले से ज्ञात कमांड का उपयोग करते हैं:

यहां आप देख सकते हैं कि रेगुलर एक्सप्रेशन ने सही तरीके से काम किया है: test_resource.txt की अब "स्टेज्ड" स्थिति है।

और अंत में, स्थानीय रिपॉजिटरी के साथ काम करने का अंतिम चरण (रिमोट रिपॉजिटरी के साथ काम करते समय एक और है;)) - एक नया कमिट बनाना:

शाखा पर प्रतिबद्ध इतिहास को देखने के लिए अगली बार एक महान आदेश है। आइए इसका उपयोग करें:

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

एक जिज्ञासु पाठक जो अभी तक सो नहीं पाया है, सोच रहा होगा कि GitTest.java फ़ाइल का क्या हुआ। आइए अभी पता करें। ऐसा करने के लिए, हम उपयोग करते हैं:

जैसा कि आप देख सकते हैं, यह अभी भी "अनट्रैक" है और पंखों में प्रतीक्षा कर रहा है। लेकिन क्या होगा अगर हम इसे प्रोजेक्ट में बिल्कुल भी नहीं जोड़ना चाहते हैं? कभी कभी ऐसा होता है।

चीजों को और अधिक रोचक बनाने के लिए, आइए अब अपनी test_resource.txt फ़ाइल को बदलने का प्रयास करें। आइए वहां कुछ टेक्स्ट जोड़ें और स्थिति जांचें:

यहां आप स्पष्ट रूप से "अनट्रैक" और "संशोधित" स्थितियों के बीच अंतर देख सकते हैं।

GitTest.java "अनट्रैक" है, जबकि test_resource.txt "संशोधित" है।

अब जब हमारे पास संशोधित स्थिति में फाइलें हैं, तो हम उनमें किए गए परिवर्तनों की जांच कर सकते हैं। यह निम्न कमांड का उपयोग करके किया जा सकता है:

अर्थात्, आप यहाँ स्पष्ट रूप से देख सकते हैं कि मैंने अपनी टेक्स्ट फ़ाइल में क्या जोड़ा है: हैलो वर्ल्ड!

टेक्स्ट फ़ाइल में अपने बदलाव जोड़ते हैं और एक कमिट बनाते हैं:

सभी कमिट्स को देखने के लिए, लिखें:

जैसा कि आप देख सकते हैं, अब हमारे पास दो कमिट हैं।

हम इसी तरह GitTest.java को जोड़ेंगे। यहां कोई टिप्पणी नहीं, केवल आदेश:

.gitignore के साथ कार्य करना

स्पष्ट रूप से, हम केवल स्रोत कोड को अकेले रखना चाहते हैं, और कुछ नहीं, रिपॉजिटरी में। तो और क्या हो सकता है? कम से कम, संकलित कक्षाएं और/या विकास वातावरण द्वारा उत्पन्न फाइलें।

Git को उन्हें अनदेखा करने के लिए कहने के लिए, हमें एक विशेष फ़ाइल बनाने की आवश्यकता है। ऐसा करें: प्रोजेक्ट के रूट में .gitignore नाम की एक फाइल बनाएं। इस फ़ाइल की प्रत्येक पंक्ति अनदेखा करने के लिए एक पैटर्न का प्रतिनिधित्व करती है।

इस उदाहरण में, .gitignore फ़ाइल इस तरह दिखेगी:

चलो एक नज़र मारें:

• पहली पंक्ति .class एक्सटेंशन वाली सभी फाइलों को अनदेखा करना है
• दूसरी पंक्ति "लक्ष्य" फ़ोल्डर और उसमें मौजूद सभी चीज़ों को अनदेखा करना है
• तीसरी लाइन .iml एक्सटेंशन वाली सभी फाइलों को इग्नोर करना है
• चौथी लाइन .idea फोल्डर को इग्नोर करना है

आइए एक उदाहरण का उपयोग करके देखें। यह देखने के लिए कि यह कैसे काम करता है, आइए संकलित GitTest.class को प्रोजेक्ट में जोड़ें और प्रोजेक्ट की स्थिति जांचें:

स्पष्ट रूप से, हम किसी तरह गलती से संकलित वर्ग को परियोजना में नहीं जोड़ना चाहते हैं (git ऐड-ए का उपयोग करके)। ऐसा करने के लिए, एक .gitignore फ़ाइल बनाएँ और वह सब कुछ जोड़ें जो पहले वर्णित किया गया था:

अब प्रोजेक्ट में .gitignore फ़ाइल जोड़ने के लिए एक कमिट का उपयोग करें:

और अब सच्चाई का क्षण: हमारे पास एक संकलित वर्ग GitTest.class है जो "अनट्रैक" है, जिसे हम Git रिपॉजिटरी में नहीं जोड़ना चाहते थे।

अब हमें .gitignore फ़ाइल का प्रभाव देखना चाहिए:

उत्तम! .gitignore +1 :)

शाखाओं के साथ काम करना

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

एक शाखा काम करने के लिए सिर्फ एक चल सूचक है।

इस भाग में, हम विभिन्न शाखाओं में काम करने का पता लगाएंगे: एक शाखा से दूसरी शाखा में परिवर्तनों को कैसे मर्ज किया जाए, कौन से विरोध उत्पन्न हो सकते हैं, और भी बहुत कुछ।

रिपॉजिटरी में सभी शाखाओं की सूची देखने के लिए और यह समझने के लिए कि आप किस शाखा में हैं, आपको लिखने की आवश्यकता है:

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

फिर शाखाएँ बनाने के लिए कई विकल्प हैं (और भी हो सकते हैं - ये वे हैं जिनका मैं उपयोग करता हूँ):

• हम जिस (99% मामलों में) हैं, उसके आधार पर एक नई शाखा बनाएँ
• एक विशिष्ट प्रतिबद्धता के आधार पर एक शाखा बनाएँ (मामलों का 1%)

चलिए एक विशिष्ट कमिट के आधार पर एक शाखा बनाते हैं

हम कमिट के विशिष्ट पहचानकर्ता पर भरोसा करेंगे। इसे खोजने के लिए, हम लिखते हैं:

हमने "एडेड हैलो वर्ल्ड ..." टिप्पणी के साथ कमिटमेंट को हाइलाइट किया है। इसकी विशिष्ट पहचानकर्ता 6c44e53d06228f888f2f454d3cb8c1c976dd73f8 है। हम एक "विकास" शाखा बनाना चाहते हैं जो इस प्रतिबद्धता से शुरू हो। ऐसा करने के लिए, हम लिखते हैं:

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

और उम्मीद के मुताबिक, हमारे पास दो कमिट हैं। वैसे, यहाँ एक दिलचस्प बिंदु है: इस शाखा में अभी तक कोई .gitignore फ़ाइल नहीं है, इसलिए हमारी संकलित फ़ाइल (GitTest.class) अब "अनट्रैक" स्थिति के साथ हाइलाइट की गई है।

अब हम इसे लिखकर अपनी शाखाओं की फिर से समीक्षा कर सकते हैं:

आप देख सकते हैं कि दो शाखाएँ हैं: "मास्टर" और "विकास"। हम वर्तमान में विकास में हैं।

आइए वर्तमान के आधार पर एक शाखा बनाएँ

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

• गिट चेकआउट मास्टर - मास्टर शाखा में स्विच करें
• git स्थिति - सत्यापित करें कि हम वास्तव में मास्टर शाखा में हैं

यहां आप देख सकते हैं कि हमने मास्टर शाखा में स्विच किया है, .gitignore फ़ाइल प्रभाव में है, और संकलित वर्ग अब "अनट्रैक" के रूप में हाइलाइट नहीं किया गया है।

अब हम मास्टर ब्रांच के आधार पर एक नई ब्रांच बनाते हैं:

यदि आप अनिश्चित हैं कि क्या यह शाखा "मास्टर" के समान है, तो आप "गिट लॉग" निष्पादित करके और सभी कामों को देखकर आसानी से जांच सकते हैं। उनमें से चार होने चाहिए।

युद्ध वियोजन

इससे पहले कि हम यह पता लगाएँ कि संघर्ष क्या है, हमें एक शाखा को दूसरी में विलय करने के बारे में बात करने की आवश्यकता है।

यह चित्र एक शाखा को दूसरी शाखा में विलय करने की प्रक्रिया को दर्शाता है:

यहाँ, हमारी एक मुख्य शाखा है। किसी बिंदु पर, मुख्य शाखा से एक द्वितीयक शाखा बनाई जाती है और फिर संशोधित की जाती है। एक बार काम पूरा हो जाने के बाद, हमें एक शाखा को दूसरी शाखा में विलय करने की जरूरत है।

हमारे उदाहरण में, हमने फीचर/अपडेट-टीएक्सटी-फाइल्स ब्रांच बनाई। जैसा कि शाखा के नाम से संकेत मिलता है, हम टेक्स्ट अपडेट कर रहे हैं।

अब हमें इस काम के लिए एक नई प्रतिबद्धता बनाने की जरूरत है:

अब, यदि हम फीचर/अपडेट-टीएक्सटी-फाइल्स ब्रांच को मास्टर में मर्ज करना चाहते हैं, तो हमें मास्टर में जाकर "गिट मर्ज फीचर/अपडेट-टीएक्सटी-फाइल्स" लिखना होगा:

नतीजतन, मास्टर शाखा में अब वह कमिट भी शामिल है जिसे फीचर/अपडेट-टीएक्सटी-फाइल्स में जोड़ा गया था।

यह कार्यक्षमता जोड़ी गई थी, ताकि आप फीचर शाखा को हटा सकें। ऐसा करने के लिए, हम लिखते हैं:

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

हम मास्टर के आधार पर एक नई शाखा बनाएंगे, text_resource.txt में बदलाव करेंगे और इस काम के लिए एक कमिट बनाएंगे:

... हम फ़ाइल में परिवर्तन करते हैं

मास्टर ब्रांच में जाएं और इस टेक्स्ट फाइल को उसी लाइन पर अपडेट करें जैसे कि फीचर ब्रांच में:

… हमने test_resource.txt को अपडेट किया है

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

लेकिन परिणाम test_resource.txt फ़ाइल में विरोध होगा:

यहाँ हम देख सकते हैं कि Git इस कोड को मर्ज करने का तरीका स्वयं तय नहीं कर सका। यह हमें बताता है कि हमें पहले संघर्ष को हल करने की जरूरत है, और उसके बाद ही कमिटमेंट करें।

ठीक है। हम पाठ संपादक में विरोध वाली फ़ाइल खोलते हैं और देखते हैं:

यह समझने के लिए कि Git ने यहाँ क्या किया, हमें यह याद रखना होगा कि हमने कौन से परिवर्तन किए हैं और कहाँ किए हैं, और फिर तुलना करें:

1. मास्टर ब्रांच में इस लाइन पर जो बदलाव थे, वे "<<<<<<< HEAD" और "====" के बीच पाए गए।
2. फीचर/ऐड-हेडर ब्रांच में जो बदलाव थे, वे "====" और ">>>>>>> फीचर/ऐड-हेडर" के बीच पाए गए।

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

काफी उचित। मैं साहसपूर्वक सब कुछ हटाने का फैसला करता हूं, केवल "हेडर" शब्द छोड़कर:

आइए परिवर्तनों की स्थिति देखें। विवरण थोड़ा अलग होगा। "संशोधित" स्थिति के बजाय, हमारे पास "अनमर्ज" है। तो क्या हम पाँचवीं स्थिति का उल्लेख कर सकते थे? मुझे नहीं लगता कि यह जरूरी है। आइए देखते हैं:

हम खुद को समझा सकते हैं कि यह एक विशेष, असामान्य मामला है। आगे है:

आप देख सकते हैं कि विवरण केवल "गिट कमिट" लिखने का सुझाव देता है। आइए इसे लिखने का प्रयास करें:

और ठीक ऐसे ही, हमने इसे किया — हमने कंसोल में विरोध को सुलझा लिया।

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

रिमोट रिपॉजिटरी के साथ काम करना

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

जैसा कि मैंने कहा, एक रिमोट रिपॉजिटरी कुछ ऐसी जगह है जहां रिपॉजिटरी स्टोर की जाती है और जिससे आप इसे क्लोन कर सकते हैं।

वहां किस तरह के रिमोट रिपॉजिटरी हैं? उदाहरण:

• GitHub रिपॉजिटरी और सहयोगी विकास के लिए सबसे बड़ा स्टोरेज प्लेटफॉर्म है।
• GitLab खुले स्रोत के साथ DevOps जीवनचक्र के लिए एक वेब-आधारित उपकरण है। यह अपने स्वयं के विकी, बग ट्रैकिंग सिस्टम, CI/CD पाइपलाइन और अन्य कार्यों के साथ कोड रिपॉजिटरी के प्रबंधन के लिए एक Git-आधारित प्रणाली है।
• BitBucket Mercurial और Git वर्जन कंट्रोल सिस्टम पर आधारित प्रोजेक्ट होस्टिंग और सहयोगी विकास के लिए एक वेब सेवा है। एक समय में गिटहब पर इसका बड़ा फायदा था कि यह मुफ्त निजी रिपॉजिटरी की पेशकश करता था। पिछले साल, GitHub ने भी इस क्षमता को सभी के लिए मुफ्त में पेश किया था।
• और इसी तरह…

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

इसके लिए हमने उस प्रोजेक्ट को एक्सपोर्ट किया जो हमने स्थानीय रूप से बनाया था। अब हर कोई इसे लिखकर अपने लिए क्लोन कर सकता है:

अब परियोजना की पूरी स्थानीय प्रति है। यह सुनिश्चित करने के लिए कि परियोजना की स्थानीय प्रति नवीनतम है, आपको परियोजना को लिखकर खींचने की आवश्यकता है:

हमारे मामले में, वर्तमान में दूरस्थ रिपॉजिटरी में कुछ भी नहीं बदला है, इसलिए प्रतिक्रिया है: पहले से ही अद्यतित।

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

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

अब हमारे लिए कुछ बहुत ही सामान्य है — हम इस कार्य के लिए एक कमिट बनाते हैं:

इसे दूरस्थ रिपॉजिटरी में धकेलने का आदेश है:

अभी के लिए बस इतना ही!

2. IntelliJ IDEA में Git के साथ कैसे काम करें

इस भाग में, आप सीखेंगे कि IntelliJ IDEA में Git के साथ कैसे काम करें।

आवश्यक इनपुट:

1. पिछला भाग पढ़ें, साथ चलें और समझें। इससे यह सुनिश्चित करने में मदद मिलेगी कि सब कुछ सेट हो गया है और जाने के लिए तैयार है।
2. IntelliJ आईडिया स्थापित करें। यहाँ सब कुछ क्रम में होना चाहिए :)
3. पूर्ण महारत हासिल करने के लिए एक घंटा आवंटित करें।

आइए डेमो प्रोजेक्ट के साथ काम करें जिसका उपयोग मैंने Git के बारे में लेख के लिए किया था।

परियोजना को स्थानीय रूप से क्लोन करें

यहां दो विकल्प हैं:

1. यदि आपके पास पहले से ही एक GitHub खाता है और बाद में कुछ पुश करना चाहते हैं, तो प्रोजेक्ट को फोर्क करना और अपनी कॉपी को क्लोन करना बेहतर होगा। आप फोर्किंग वर्कफ़्लो का एक उदाहरण शीर्षक के तहत एक अन्य लेख में एक कांटा कैसे बनाएं के बारे में पढ़ सकते हैं ।
2. रिपॉजिटरी को क्लोन करें और पूरी चीज को सर्वर पर धकेलने की क्षमता के बिना स्थानीय रूप से सब कुछ करें।

GitHub से किसी प्रोजेक्ट को क्लोन करने के लिए, आपको प्रोजेक्ट लिंक को कॉपी करना होगा और इसे IntelliJ IDEA को पास करना होगा:

1. प्रोजेक्ट का पता कॉपी करें:

2. IntelliJ IDEA खोलें और "संस्करण नियंत्रण से प्राप्त करें" चुनें:

3. प्रोजेक्ट का पता कॉपी और पेस्ट करें:

4. आपको IntelliJ IDEA प्रोजेक्ट बनाने के लिए कहा जाएगा। ऑफर स्वीकार करें:

5. चूंकि कोई बिल्ड सिस्टम नहीं है, हम "मौजूदा स्रोतों से प्रोजेक्ट बनाएं" का चयन करते हैं:

6. आगे आपको यह सुंदर स्क्रीन दिखाई देगी:

अब जब हमने क्लोनिंग का पता लगा लिया है, तो आप चारों ओर देख सकते हैं।

Git UI के रूप में IntelliJ IDEA पर पहली नज़र

क्लोन प्रोजेक्ट पर करीब से नज़र डालें: आप पहले से ही संस्करण नियंत्रण प्रणाली के बारे में बहुत सारी जानकारी प्राप्त कर सकते हैं।

सबसे पहले, हमारे पास निचले बाएँ कोने में संस्करण नियंत्रण फलक है। यहां आप सभी स्थानीय परिवर्तन पा सकते हैं और कमिट की सूची प्राप्त कर सकते हैं ("गिट लॉग" के अनुरूप)।

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

इसके अलावा, आप वास्तविक परिवर्तन देख सकते हैं। हम यह भी देखते हैं कि वहां एक विवाद सुलझा लिया गया था। आईडिया भी इसे बहुत अच्छे से प्रस्तुत करता है।

यदि आप इस कमिट के दौरान बदली गई फ़ाइल पर डबल-क्लिक करते हैं, तो हम देखेंगे कि विरोध कैसे हल किया गया:

हम ध्यान दें कि बाईं और दाईं ओर हमारे पास एक ही फ़ाइल के दो संस्करण हैं जिन्हें एक में विलय करने की आवश्यकता है। और बीच में, हमारे पास अंतिम विलयित परिणाम है।

जब किसी प्रोजेक्ट की कई शाखाएँ, कमिट और उपयोगकर्ता होते हैं, तो आपको शाखा, उपयोगकर्ता और दिनांक के अनुसार अलग से खोजना होगा:

आरंभ करने से पहले, यह समझाना भी सार्थक है कि हम किस शाखा में हैं, यह कैसे समझें।

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

रिपॉजिटरी के साथ काम करना

उपयोगी हॉटकीज़

भविष्य के काम के लिए, आपको कुछ बहुत ही उपयोगी हॉटकी याद रखने की आवश्यकता है:

1. CTRL+T — रिमोट रिपॉजिटरी (git पुल) से नवीनतम परिवर्तन प्राप्त करें।
2. CTRL+K — एक कमिट बनाएं / सभी मौजूदा बदलाव देखें। इसमें ट्रैक न की गई और संशोधित फ़ाइलें (git कमिट) दोनों शामिल हैं।
3. CTRL+SHIFT+K — यह रिमोट रिपॉजिटरी में परिवर्तन करने के लिए कमांड है। स्थानीय रूप से बनाए गए और अभी तक दूरस्थ रिपॉजिटरी में नहीं बनाए गए सभी कमिट को पुश (गिट पुश) किया जाएगा।
4. ALT+CTRL+Z - स्थानीय रिपॉजिटरी में बनाए गए अंतिम कमिट की स्थिति में एक विशिष्ट फ़ाइल में रोलबैक परिवर्तन। यदि आप ऊपरी बाएँ कोने में संपूर्ण प्रोजेक्ट का चयन करते हैं, तो आप सभी फ़ाइलों में परिवर्तन वापस कर सकते हैं।

हम क्या चाहते हैं?

काम पूरा करने के लिए, हमें हर जगह इस्तेमाल होने वाले बुनियादी परिदृश्य में महारत हासिल करनी होगी।

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

इसे करने की क्या आवश्यकता है?

1. मुख्य शाखा में सभी वर्तमान परिवर्तन प्राप्त करें (उदाहरण के लिए, "मास्टर")।

2. इस मुख्य ब्रांच से अपने काम के लिए एक अलग ब्रांच बनाएं।

3. नई कार्यक्षमता लागू करें।

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

   क्या आप सोच रहे हैं कि आपको ऐसा क्यों करना चाहिए? यह अच्छा व्यवहार है और आपकी शाखा को स्थानीय रिपॉजिटरी में धकेलने के बाद होने वाले संघर्षों को रोकता है (बेशक, एक संभावना है कि संघर्ष अभी भी होगा, लेकिन यह बहुत छोटा हो जाता है)।

5. अपने परिवर्तनों को दूरस्थ रिपॉजिटरी में पुश करें।

रिमोट सर्वर से परिवर्तन कैसे प्राप्त करें?

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

CTRL+T दर्ज करें :

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

मास्टर के आधार पर एक नई शाखा बनाएँ

यहाँ सब कुछ सरल है।

निचले दाएं कोने पर जाएं और Git: मास्टर पर क्लिक करें । + नई शाखा का चयन करें ।

चेकआउट शाखा चेकबॉक्स को चयनित छोड़ दें और नई शाखा का नाम दर्ज करें। हमारे मामले में: यह रीडमी-इंप्रूवर होगा ।

गिट: मास्टर फिर गिट में बदल जाएगा : रीडमी-इंप्रूवर ।

आइए समानांतर काम का अनुकरण करें

संघर्ष प्रकट होने के लिए, किसी को उन्हें बनाना होगा।

हम ब्राउज़र के माध्यम से रीडमे को एक नई प्रतिबद्धता के साथ संपादित करेंगे, इस प्रकार समांतर कार्य को अनुकरण करेंगे। यह ऐसा है जैसे जब हम इस पर काम कर रहे थे तो किसी ने उसी फ़ाइल में परिवर्तन किया हो। परिणाम संघर्ष होगा। हम लाइन 10 से "fully" शब्द हटा देंगे।

हमारी कार्यक्षमता को लागू करें

हमारा काम रीडमे को बदलना और नए लेख में विवरण जोड़ना है। यानी Git में काम IntelliJ IDEA के जरिए होता है। इसमें जोड़ें:

बदलाव हो गए हैं। अब हम एक कमिट बना सकते हैं। CTRL+K दबाएं , जो हमें देता है:

कमिट बनाने से पहले, हमें यह देखना होगा कि यह विंडो क्या प्रदान करती है।

कमिट मैसेज सेक्शन में , हम कमिट से जुड़ा टेक्स्ट लिखते हैं। फिर इसे बनाने के लिए, हमें कमिट पर क्लिक करना होगा ।

हम लिखते हैं कि रीडमे बदल गया है और कमिट बनाता है। कमिट के नाम के साथ निचले बाएँ कोने में एक अलर्ट पॉप अप होता है:

जांचें कि क्या मुख्य शाखा बदल गई है

हमने अपना कार्य पूरा किया। यह काम करता है। हमने परीक्षण लिखे। और सब ठीक है न। लेकिन सर्वर पर पुश करने से पहले, हमें अभी भी यह जांचना होगा कि क्या इस दौरान मुख्य शाखा में कोई बदलाव हुआ है। ऐसा कैसे हो सकता है? काफी आसानी से: किसी को आपके बाद एक कार्य प्राप्त होता है, और यह कि कोई व्यक्ति आपके कार्य को पूरा करने की तुलना में तेज़ी से पूरा करता है।

इसलिए हमें मास्टर ब्रांच में जाने की जरूरत है। ऐसा करने के लिए, हमें वह करना होगा जो नीचे स्क्रीनशॉट में निचले दाएं कोने में दिखाया गया है:

मास्टर शाखा में, दूरस्थ सर्वर से इसके नवीनतम परिवर्तन प्राप्त करने के लिए CTRL+T दबाएँ। परिवर्तनों को देखते हुए, आप आसानी से देख सकते हैं कि क्या हुआ:

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

अब हमारे पास मास्टर शाखा के नवीनतम संस्करण की एक स्थानीय प्रति है। रीडमी-इंप्रूवर पर वापस जाएं ।

अब हमें मास्टर ब्रांच से अपने में हुए बदलावों को रिबेस करने की जरूरत है। हम यह करते हैं:

यदि आपने सब कुछ सही ढंग से किया और मेरे साथ अनुसरण किया, तो परिणाम को रीडमे फ़ाइल में एक विरोध दिखाना चाहिए:

यहां हमारे पास समझने और सोखने के लिए बहुत सारी जानकारी भी है। यहां फाइलों की एक सूची दिखाई गई है (हमारे मामले में, एक फाइल) जिसमें विरोध है। हम तीन विकल्पों में से चुन सकते हैं:

1. अपना स्वीकार करें - रीडमी-इंप्रूवर से केवल परिवर्तन स्वीकार करें।
2. उनका स्वीकार करो - केवल गुरु से परिवर्तन स्वीकार करो।
3. विलय - अपने आप को चुनें कि आप क्या रखना चाहते हैं और क्या त्यागना चाहते हैं।

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

यहाँ हम देख सकते हैं कि तीन भाग हैं:

1. ये रीडमी-इंप्रूवर के बदलाव हैं।
2. मिला हुआ परिणाम। अभी के लिए, यह वही है जो परिवर्तनों से पहले अस्तित्व में था।
3. मास्टर शाखा से परिवर्तन।

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

फिर एक सूचना पॉप अप होगी, जो हमें बताएगी कि रिबेस सफल रहा:

वहाँ! हमने IntelliJ IDEA के माध्यम से अपना पहला संघर्ष सुलझाया।

दूरस्थ सर्वर में परिवर्तन पुश करें

अगला चरण दूरस्थ सर्वर में परिवर्तनों को पुश करना और एक पुल अनुरोध बनाना है। ऐसा करने के लिए, बस CTRL+SHIFT+K दबाएँ । तब हमें मिलता है:

बाईं ओर, कमिट की एक सूची होगी जिसे दूरस्थ रिपॉजिटरी में नहीं धकेला गया है। दाईं ओर वे सभी फाइलें होंगी जो बदल गई हैं। और बस! पुश दबाएं और आपको खुशी का अनुभव होगा :)

यदि पुश सफल होता है, तो आपको निचले दाएं कोने में इस तरह की सूचना दिखाई देगी:

बोनस: एक पुल अनुरोध बनाना

आइए एक GitHub रिपॉजिटरी में जाएं और हम देखते हैं कि GitHub पहले से ही जानता है कि हम क्या चाहते हैं:

तुलना करें और अनुरोध खींचें पर क्लिक करें । फिर क्रिएट पुल रिक्वेस्ट पर क्लिक करें । क्योंकि हमने विरोधों को पहले ही हल कर लिया है, अब पुल अनुरोध बनाते समय, हम इसे तुरंत मर्ज कर सकते हैं:

अभी के लिए बस इतना ही!