गिट के साथ आरंभ करना: नौसिखियों के लिए एक व्यापक मार्गदर्शिका

एक परिचय के बजाय

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

गिट मूल बातें

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

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

आइए आपके कंप्यूटर पर जावा स्थापित करें।

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

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

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

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

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

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

गिट सेटिंग्स

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

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

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

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

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

विषय में गोता लगाने के लिए, हमें आपको कुछ नए शब्दों और कार्यों से परिचित कराना चाहिए...

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

और इसी तरह।

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

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

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

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

ये ऐसी स्थितियाँ हैं जो हमारे कोड वाली फ़ाइलों पर लागू होती हैं:

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

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

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

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

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

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

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

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

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

आप एक स्थानीय रिपॉजिटरी के साथ-साथ एक रिमोट के साथ भी काम कर सकते हैं। आवश्यक आदेशों का अभ्यास करने के लिए, आप स्वयं को स्थानीय रिपॉजिटरी तक सीमित कर सकते हैं। यह केवल .git फ़ोल्डर में स्थानीय रूप से प्रोजेक्ट की सभी जानकारी संग्रहीत करता है। यदि हम दूरस्थ रिपॉजिटरी के बारे में बात कर रहे हैं, तो सभी जानकारी दूरस्थ सर्वर पर कहीं संग्रहीत की जाती है: केवल प्रोजेक्ट की एक प्रति स्थानीय रूप से संग्रहीत की जाती है। आपकी स्थानीय प्रति में किए गए परिवर्तन दूरस्थ रिपॉजिटरी में पुश (गिट पुश) किए जा सकते हैं। यहां और नीचे हमारी चर्चा में, हम कंसोल में गिट के साथ काम करने के बारे में बात कर रहे हैं। बेशक, आप किसी प्रकार के GUI-आधारित समाधान (उदाहरण के लिए, IntelliJ IDEA) का उपयोग कर सकते हैं, लेकिन पहले आपको यह पता लगाना चाहिए कि कौन से कमांड निष्पादित किए जा रहे हैं और उनका क्या मतलब है।

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

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

git init

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

git status

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

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

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

git add *.txt

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

git status

यहां आप देख सकते हैं कि रेगुलर एक्सप्रेशन ने सही तरीके से काम किया है: test_resource.txt की अब "स्टेज्ड" स्थिति है। और अंत में, स्थानीय रिपॉजिटरी के साथ काम करने का अंतिम चरण (रिमोट रिपॉजिटरी के साथ काम करते समय एक और है;)) - एक नया कमिट बनाना:

git commit -m "all txt files were added to the project"

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

git log

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

git status

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

git status

यहां आप स्पष्ट रूप से "अनट्रैक" और "संशोधित" स्थितियों के बीच अंतर देख सकते हैं। GitTest.java "अनट्रैक" है, जबकि test_resource.txt "संशोधित" है। अब जब हमारे पास संशोधित स्थिति में फ़ाइलें हैं, तो हम उनमें किए गए परिवर्तनों की जाँच कर सकते हैं। यह निम्न कमांड का उपयोग करके किया जा सकता है:

git diff

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

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

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

git log

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

git add GitTest.java
git commit -m "added GitTest.java"
git status

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

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

```
*.class
target/
*.iml
.idea/
```

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

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

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

git status

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

git add .gitignore
git commit -m "added .gitignore file"

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

git status

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

शाखाओं और इस तरह के साथ काम करना

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

git branch -a

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

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

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

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

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

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

git branch -a

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

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

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

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

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

git checkout -b feature/update-txt-files

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

युद्ध वियोजन

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

git add *.txt 
git commit -m "updated txt files"
git log

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

git checkout master
git merge feature/update-txt-files
git log

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

git branch -D feature/update-txt-files

अब तक सब कुछ स्पष्ट है, हाँ? आइए स्थिति को जटिल करें: अब मान लें कि आपको txt फ़ाइल को फिर से बदलने की आवश्यकता है। लेकिन अब यह फाइल मास्टर ब्रांच में भी बदली जाएगी। दूसरे शब्दों में, यह समानांतर में बदल जाएगा। जब हम अपने नए कोड को मास्टर ब्रांच में मर्ज करना चाहते हैं तो Git यह पता नहीं लगा पाएगा कि क्या करना है। चल दर! हम मास्टर के आधार पर एक नई शाखा बनाएंगे, text_resource.txt में बदलाव करेंगे और इस काम के लिए एक कमिट बनाएंगे:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

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

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

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

git merge feature/add-header

लेकिन परिणाम test_resource.txt फ़ाइल में एक विरोध होगा: यहां हम देख सकते हैं कि गिट इस कोड को मर्ज करने का तरीका तय नहीं कर सका। यह हमें बताता है कि हमें पहले संघर्ष को हल करने की जरूरत है, और उसके बाद ही कमिटमेंट करें। ठीक है। हम एक पाठ संपादक में विरोध के साथ फाइल खोलते हैं और देखते हैं: यह समझने के लिए कि गिट ने यहां क्या किया, हमें यह याद रखना होगा कि हमने कौन से बदलाव किए और कहां किए, और फिर तुलना करें:

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

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

git status

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

git add *.txt

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

git commit

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

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

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

• GitHub रिपॉजिटरी और सहयोगी विकास के लिए सबसे बड़ा स्टोरेज प्लेटफॉर्म है। मैंने पिछले लेखों में इसका वर्णन पहले ही कर दिया है। गिटहब
  पर मेरा अनुसरण करें । मैं अक्सर उन क्षेत्रों में अपना काम दिखाता हूँ जहाँ मैं काम के लिए अध्ययन कर रहा हूँ।

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

• BitBucket Mercurial और Git वर्जन कंट्रोल सिस्टम पर आधारित प्रोजेक्ट होस्टिंग और सहयोगी विकास के लिए एक वेब सेवा है। एक समय में गिटहब पर इसका बड़ा फायदा था कि यह मुफ्त निजी रिपॉजिटरी की पेशकश करता था। पिछले साल, GitHub ने भी इस क्षमता को सभी के लिए मुफ्त में पेश किया था।

• और इसी तरह…

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

git clone https://github.com/romankh3/git-demo

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

git pull

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

git add test_resource.txt
git commit -m "prepared txt for pushing"

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

git push

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

उपयोगी लिंक

• आधिकारिक गिट दस्तावेज । मैं इसे एक संदर्भ के रूप में अनुशंसा करता हूं।