Git का परिचय

सामग्री की तालिका

प्रस्तावना
1. गिटिंग को कॉन्फ़िगर करना
.... 1.1 विन्यास फाइल
.... 1.2 डिफ़ॉल्ट सेटिंग्स
.... 1.3 उपनाम
2. गिट की मूल बातें
.... २.१ एक भंडार बनाना
.... २.२ फ़ाइल स्थिति
.... 2.3 सूचकांक के साथ काम करना
.... 2.4 कमिट्स के साथ काम करना
.... २.५ इतिहास देखें
.... 2.6 एक दूरस्थ भंडार के साथ काम करना
3. गिट में शाखा
.... 3.1 मूल संचालन
.... ३.२ शाखाएँ मिलाना
.... ३.३ रीरेरे
4. पॉइंट इन गिट
.... ४.१ चलते बिंदु
5. पढ़ने की सलाह दी

प्रस्तावना

Git सबसे लोकप्रिय वितरित संस्करण नियंत्रण प्रणाली है। [१] [२]

Git का मुख्य उद्देश्य आपकी परियोजना की क्रमिक रूप से सुधार की स्थितियों के स्नैपशॉट को बचाना है (Pro git, 2019)।

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

गिट के दर्शन और इसके आंतरिक कार्यान्वयन में अधिक विस्तृत विसर्जन के लिए, गिट के केवल तकनीकी पहलुओं को यहां माना जाता है, मैं आपको कई उपयोगी पुस्तकों को पढ़ने की सलाह देता हूं ( अनुशंसित पढ़ने को देखें)।

1. गिटिंग को कॉन्फ़िगर करना

इससे पहले कि आप git के साथ काम करना शुरू करें, आपको इसे अपने लिए कॉन्फ़िगर करने की आवश्यकता है!

1.1 विन्यास फाइल

• / etc / gitconfig - सभी उपयोगकर्ताओं और रिपॉजिटरी के लिए सामान्य सेटिंग्स
• ~ / .itconfig या ~ / .config / git / config - विशिष्ट उपयोगकर्ता सेटिंग्स
• .it / config - एक विशिष्ट रिपॉजिटरी के लिए सेटिंग्स

एक विशेष टीम है

git config [<>] 

जो आपको आवश्यक होने पर मानक व्यवहार को बदलने की अनुमति देगा, लेकिन आप कॉन्फ़िगरेशन फ़ाइलों को मैन्युअल रूप से संपादित कर सकते हैं (मुझे लगता है कि इतनी तेजी से)।

किस पैरामीटर पर आप git config (--system, --global, --local) कमांड से गुजरते हैं, सेटिंग्स इन फ़ाइलों में से एक को लिखा जाएगा। इनमें से प्रत्येक "स्तर" (सिस्टम, वैश्विक, स्थानीय) पिछले स्तर के मूल्यों को फिर से परिभाषित करता है!

किस फ़ाइल में कौन सी सेटिंग्स स्थापित हैं, यह देखने के लिए, git config --list --show-Origin का उपयोग करें।

फाइलों को नजरअंदाज करना
Git में, आप तय करते हैं कि कौन सी फाइलें किस कमिट में जाएंगी, लेकिन शायद आप कुछ ऐसी फाइलें चाहेंगे जो इंडेक्स और कमिट में न हों, और न ही अनट्रेक्ड लिस्ट में भी दिखाई दें। ऐसा करने के लिए, आप अपनी रिपॉजिटरी में एक विशेष फ़ाइल (.gitignore) बना सकते हैं और वहाँ उपेक्षित फ़ाइलों का टेम्पलेट लिख सकते हैं। यदि आप प्रत्येक रिपॉजिटरी में ऐसी फाइल नहीं बनाना चाहते हैं, तो आप इसे core.excludesfile ( उपयोगी सेटिंग्स देखें) का उपयोग करके विश्व स्तर पर परिभाषित कर सकते हैं। आप जिस प्रोग्रामिंग लैंग्वेज पर काम कर रहे हैं, उसके लिए आप .gitignore फाइल को भी डाउनलोड कर सकते हैं।
.Gitignore को कस्टमाइज़ करने के लिए, बैश रेगुलर एक्सप्रेशन का उपयोग करें।

1.2 डिफ़ॉल्ट सेटिंग्स

सर्वर और क्लाइंट दोनों के लिए गिट सेटिंग्स का एक गुच्छा है, केवल बुनियादी क्लाइंट सेटिंग्स को यहां माना जाएगा।

उपयोग

 git config name value 

जहां नाम पैरामीटर का नाम है, और सेटिंग्स सेट करने के लिए मूल्य इसका मूल्य है।
एक उदाहरण:

 git config --global core.editor nano 

डिफ़ॉल्ट संपादक नैनो स्थापित करेगा।

आप मौजूदा पैरामीटर के मान को git config --get [name] के साथ देख सकते हैं, जहां नाम वह पैरामीटर है जिसका मान आप प्राप्त करना चाहते हैं।

उपयोगी सेटिंग्स:

• user.name - वह नाम जिसका उपयोग कमिट बनाते समय किया जाएगा
• user.email - प्रतिबद्ध बनाते समय उपयोग करने के लिए ईमेल
• core.excludesfile - एक फ़ाइल जिसका टेम्पलेट वैश्विक स्तर पर विशिष्ट फ़ाइलों को अनदेखा करने के लिए उपयोग किया जाएगा
• core.editor - डिफ़ॉल्ट संपादक
• प्रतिबद्ध .emplate - वह फ़ाइल जिसकी सामग्री डिफ़ॉल्ट प्रतिबद्ध संदेश के लिए उपयोग की जाएगी (कमिट के साथ कार्य करना देखें)।
• help.autocorrect - जब 1 पर सेट होता है, तो git गलत तरीके से लिखे गए कमांड को निष्पादित करेगा।
• credential.helper [मोड] - क्रेडेंशियल संग्रहण मोड सेट करता है। [कैश] - एक निश्चित अवधि के लिए क्रेडेंशियल सहेजे जाते हैं, पासवर्ड सहेजे नहीं जाते हैं (- समय [सेकंड] सेकंड की संख्या जिसके बाद डेटा हटा दिया जाता है, डिफ़ॉल्ट 15 मिनट है)। [स्टोर] - क्रेडेंशियल असीमित समय के लिए स्पष्ट (--फ़ाइल [फ़ाइल] में संग्रहीत किए जाते हैं, डिफ़ॉल्ट रूप से डेटा स्टोर करने के लिए पथ को इंगित करता है ~ / .गित-क्रेडेंशियल्स)।

1.3 उपनाम

यदि आप Git के लिए प्रत्येक कमांड को उसकी संपूर्णता में प्रिंट नहीं करना चाहते हैं, तो आप आसानी से उपनामों को कॉन्फ़िगर कर सकते हैं। एक उपनाम उपयोग बनाने के लिए:

 git config alias.SHORT_NAME COMMAND 

जहाँ SHORT_NAME संक्षिप्त करने के लिए नाम है, और संक्षिप्त होने के लिए कमांड (ओं) को साझा करें। एक उदाहरण:

 git config --global alias.last 'log -1 HEAD' 

इस कमांड को अंजाम देने के बाद, आप आखिरी बार git चलाकर करंट ब्रांच की आखिरी कमिटमेंट के बारे में जानकारी देख सकते हैं।

मैं आपको निम्नलिखित संक्षिप्ताक्षरों का उपयोग करने की सलाह देता हूं (आप अपने स्वयं के किसी भी परिभाषित कर सकते हैं):

• सेंट = स्थिति
• ch = चेकआउट
• ब्र = शाखा
• मिलीग्राम = विलय
• सेमी = कमिट
• रिबेट = रिबास
• lg = "git log --pretty = format: '% h -% ar:% s'"

कॉन्फ़िगरेशन सेटिंग्स देखने के लिए, उपयोग करें: git config --list।

2. गिट की मूल बातें

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

२.१ एक भंडार बनाना

• git init [<विकल्प>] - वर्तमान निर्देशिका में एक git रिपॉजिटरी और a .it डायरेक्टरी बनाता है (या --separate-git-dir <git_root> के बाद निर्दिष्ट की गई डायरेक्टरी में, .IT डाइरेक्टरी दूसरी जगह पर होगी);
• git क्लोन [<विकल्प>] [-] <repository> [<folder>] [-o ,-origin <name>] [-b, --branch <branch>] [--single-branch] [- -no-tags] [--separate-git-dir <git_root>] [-c, --config <key = value>] - नाम मूल के साथ क्लोन रिपॉजिटरी (या आपके द्वारा निर्दिष्ट -o / name> ), उस शाखा पर होना जो HEAD इंगित करता है (या जिसे आप निर्दिष्ट करते हैं -b <शाखा>)। आप केवल निर्दिष्ट हेड शाखा (या एक निर्दिष्ट इन-बी <शाखा>) को भी निर्दिष्ट कर सकते हैं - सिंगल्स-शाखा। डिफ़ॉल्ट रूप से, सभी टैग क्लोन किए जाते हैं, लेकिन --टैग निर्दिष्ट करके आप उन्हें क्लोन नहीं कर सकते। कमांड निष्पादित होने के बाद,। निर्देशिका को वर्तमान निर्देशिका में बनाया जाता है (या --separate-git-dir <git_root> के बाद निर्दिष्ट निर्देशिका में, जिस स्थिति में .IT निर्देशिका कहीं और स्थित होगी);

2.2 फ़ाइल स्थिति

अपनी रिपॉजिटरी में फ़ाइलों की स्थिति देखने के लिए, उपयोग करें:

 git status [<>] 

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

फ़ाइल जीवन चक्र
जैसा कि आप तस्वीर में देख सकते हैं, फाइलें अनट्रैक और ट्रैक की जा सकती हैं। मॉनिटर की गई फाइलें 3 अवस्थाओं में हो सकती हैं: संशोधित (अनमॉडिफाइड), संशोधित (संशोधित), तैयार (मंचित) नहीं।
यदि आप एक "अनटमिटेड" फ़ाइल का उपयोग करते हैं, तो यह "तैयार" स्थिति में चला जाता है।
यदि आप फ़ाइल को "परिवर्तित नहीं" स्थिति में बदलते हैं, तो यह "परिवर्तित" स्थिति में चला जाता है। यदि आप संशोधित फ़ाइल ("संशोधित" स्थिति में) को सहेजते हैं, तो यह "तैयार" स्थिति में चली जाती है। यदि आप कोई फ़ाइल बनाते हैं (यानी "तैयार" स्थिति में), तो यह "परिवर्तित नहीं" स्थिति में चला जाता है।
अगर HEAD और वर्किंग डायरेक्टरी में फाइल के वर्जन अलग-अलग हैं, तो फाइल "मॉडिफाइड" स्टेट्स में होगी, अन्यथा (अगर HEAD में वर्जन और वर्किंग डायरेक्टरी एक ही हैं "), फाइल" नॉट चेंज "स्टेट्स में होगी।
अगर HEAD में फाइल का वर्जन वर्किंग डायरेक्टरी से अलग है, लेकिन इंडेक्स के वर्जन से अलग नहीं है, तो फाइल "रेडी" स्थिति में होगी।

इस चक्र को निम्न प्रकार से दर्शाया जा सकता है:
अनमोडिफाइड -> संशोधित -> मंचन -> अनमॉडिफाइड
यही है, आप फ़ाइल को संशोधित करते हैं, इसे इंडेक्स में सहेजते हैं और कमिट करते हैं, और फिर सभी पर।

2.3 सूचकांक के साथ काम करना

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

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

सूचकांक को देखने के लिए, git स्थिति का उपयोग करें।

सूचकांक उपयोग के लिए फाइल को जोड़ने के लिए

 git add [<>] 

उपयोगी गिट कमांड आदेश विकल्प जोड़ें:

• -f, --force - उपेक्षित फ़ाइलों को भी जोड़ें
• -u, --update - ट्रैक की गई फ़ाइलों को अपडेट करें

सूचकांक से फ़ाइलों को हटाने के लिए, आप 2 git रीसेट और git रिस्टोर कमांड का उपयोग कर सकते हैं।
गिट-रिस्टोर - वर्किंग ट्री फ़ाइलों को पुनर्स्थापित करता है।
git-reset - वर्तमान HEAD को निर्दिष्ट स्थिति में रीसेट करता है।
वास्तव में, आप दोनों कमांड के साथ एक ही चीज हासिल कर सकते हैं।

सूचकांक से कुछ फ़ाइलों को निकालने के लिए, उपयोग करें:

 git restore --staged <file> 

इस तरह से आप अपने सूचकांक को पुनर्स्थापित करेंगे (या बल्कि, सूचकांक से विशिष्ट फ़ाइलों को हटा दें), जैसे कि अंतिम प्रतिबद्ध के बाद से उनके लिए गिट ऐड को निष्पादित नहीं किया गया था। इस कमांड से आप वर्किंग डायरेक्टरी को रिस्टोर कर सकते हैं ताकि ऐसा लगे कि कमिट के बाद कोई बदलाव नहीं किया गया। लेकिन इस कमांड में थोड़ा अजीब व्यवहार है - यदि आपने अपनी फ़ाइल का नया संस्करण अनुक्रमणिका में जोड़ा है, तो आप अपनी कार्यशील निर्देशिका को तब तक नहीं बदल सकते जब तक कि सूचकांक HEAD से अलग न हो। इसलिए, आपको पहले अपने सूचकांक को पुनर्स्थापित करने की आवश्यकता है और उसके बाद ही काम करने वाली निर्देशिका। दुर्भाग्यवश, एक आदेश के साथ ऐसा करना संभव नहीं है, क्योंकि दोनों तर्कों को पारित करते समय (git Restore -SW) कुछ भी नहीं होता है। और सिर्फ वही, जब -W पारित हो जाता है, तो इंडेक्स और हेड में फाइल अलग होने पर कुछ नहीं होगा। संभवतः, उन्होंने इसे संरक्षण के लिए किया ताकि आप गलती से अपनी कार्यशील निर्देशिका को न बदल दें। लेकिन इस मामले में, डिफ़ॉल्ट रूप से -W तर्क क्यों पारित किया जाता है? सामान्य तौर पर, मुझे यह समझ में नहीं आता है कि ऐसा क्यों किया गया था और इस कमांड को बिल्कुल क्यों जोड़ा गया था। मेरे लिए, इस कार्य के साथ तालमेल को बेहतर तरीके से रीसेट करें, और इसकी समृद्ध कार्यक्षमता भी है क्योंकि यह सूचकांक और कामकाजी निर्देशिका को न केवल अंतिम प्रतिबद्ध तक ले जा सकता है, बल्कि किसी अन्य को भी।

लेकिन डेवलपर्स खुद ही सूचकांक को रीसेट करने के लिए git रिस्टोर -S का उपयोग करने की सलाह देते हैं। इसके बजाय git रीसेट HEAD।

Git स्टेटस का उपयोग करके आप देख सकते हैं कि कौन सी फाइलें बदल गई हैं, लेकिन अगर आप यह भी जानना चाहते हैं कि फाइलों में वास्तव में क्या बदलाव आया है, तो कमांड का उपयोग करें:

 git diff [<options>] 

इस प्रकार, तर्कों के बिना कमांड निष्पादित करना, आप अपने सूचकांक की तुलना कार्यशील निर्देशिका से कर सकते हैं। यदि आपने पहले ही फाइल को इंडेक्स में शामिल कर लिया है, तो अंतिम अंतर (या आपके द्वारा निर्दिष्ट) और कार्यशील निर्देशिका के बीच अंतर देखने के लिए git diff --cached का उपयोग करें। आप दो कमिट या शाखाओं के बीच के अंतर को एक तर्क के रूप में पारित करके भी देख सकते हैं। उदाहरण: git diff 00656c 3d5119 प्रतिबद्ध 00656c और 3d5119 के बीच अंतर दिखाता है।

२.४ कमिट्स के साथ काम करना

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

अपने परिवर्तन करने के लिए, उपयोग करें:

 git commit [<>] 

Git प्रतिबद्ध कमांड के लिए उपयोगी विकल्प:

• -F, --file [फ़ाइल] - निर्दिष्ट फ़ाइल से एक प्रतिबद्ध संदेश लिखें
• -ओथोर [लेखक] - बदलें प्रतिबद्ध लेखक
• - दिनांक [तारीख] - प्रतिबद्ध दिनांक बदलें
• -m, - मेसेजेज [मैसेज] - मैसेज कमिट
• -a, --all - फ़ाइलों में सभी परिवर्तन करें
• -i, --include [फाइलें ...] - अगली प्रतिबद्ध के लिए निर्दिष्ट फ़ाइलों को सूचकांक में जोड़ें
• -o, --only [files ...] - केवल निर्दिष्ट फ़ाइलों को कमिट करें
• --amend - पिछली प्रतिबद्धता को अधिलेखित करें

आप एक डिफ़ॉल्ट कमिट का उपयोग कर सकते हैं। कॉन्फ़िगरेशन फ़ाइल में यह निर्देश उस फ़ाइल के लिए ज़िम्मेदार है, जिसकी सामग्री डिफ़ॉल्ट प्रतिबद्ध के लिए उपयोग की जाएगी। उदाहरण: git config --global प्रतिबद्ध.template ~ / .gitmessage.txt।

आप किसी भी कमिट को बदल सकते हैं, हटा सकते हैं, मर्ज कर सकते हैं।
जैसा कि आपने देखा होगा, आप जल्दी से अंतिम प्रतिबद्ध को जीआईटी कमिट के साथ लिख सकते हैं।
अपनी कहानी में प्रतिबद्धता को बदलने के लिए, का उपयोग करें

 git rebase -i <commit> 

जहां आपकी श्रृंखला में शीर्ष प्रतिबद्धता है, जहां से आप कुछ भी बदलना चाहते हैं।

इंटरएक्टिव मेनू में git rebase -i निष्पादित करने के बाद, आप जो करना चाहते हैं उसे चुनें।

• पिक <प्रतिबद्ध> = उपयोग कमिट
• reword <प्रतिबद्ध> = कमिट का उपयोग करें, लेकिन प्रतिबद्ध संदेश को बदलें
• <प्रतिबद्ध> = उपयोग प्रतिबद्ध संपादित करें, लेकिन ठीक करने के लिए बंद करें
• स्क्वैश <प्रतिबद्ध> = उपयोग कमिट, लेकिन पिछली प्रतिबद्ध के साथ मर्ज करें
• फिक्स <प्रतिबद्ध> = "स्क्वैश" के रूप में, लेकिन प्रतिबद्ध संदेश को छोड़ दें
• निष्पादित <कमांड> = शेल का उपयोग करके कमांड (लाइन के शेष) को निष्पादित करें
• ब्रेक = यहां रुकें ("गिट रिबेस - कॉन्टिन्यू" के साथ जारी रखें)
• ड्रॉप <कमिट> = कमिट कमिट
• लेबल <लेबल> = वर्तमान HEAD को नाम दें
• रीसेट <लेबल> = निर्दिष्ट लेबल पर हेड को रीसेट करें

एक विशिष्ट प्रतिबद्ध के संदेश को बदलने के लिए।
आप जिस बदलाव को बदलना चाहते हैं, उसे संपादित करने के लिए आपको पिक को बदलना होगा।
उदाहरण: आप 750f5ae प्रतिबद्ध संदेश बदलना चाहते हैं।

2748cb4 को पहले कमिट करें
750f5ae दूसरी प्रतिबद्धता संपादित करें
716eb99 तीसरी कमिटि चुनें

स्क्रिप्ट को सहेजने के बाद, आप कमांड लाइन पर लौट आएंगे और आपको बताएंगे कि आगे क्या करना है:

750f5ae पर रोक दिया गया ... दूसरा प्रतिबद्ध
आप अभी के साथ, संशोधन कर सकते हैं

git प्रतिबद्ध - काम करना

एक बार जब आप अपने परिवर्तनों से संतुष्ट हो जाते हैं, तो दौड़ें

git rebase - कॉन्टिन्यू

जैसा कि ऊपर बताया गया है, आपको प्रतिबद्ध संदेश को बदलने के लिए git कमिट -मेंड चलाना होगा। इसके बाद git rebase --continue निष्पादित करें। यदि आपने नाम बदलने के लिए कई कमिट्स का चयन किया है, तो इन ऑपरेशनों को प्रत्येक कमिट पर करना होगा।

एक कमिट को हटाने के लिए
आपको कमिट के साथ लाइन को हटाना होगा।
उदाहरण: आप प्रतिबद्ध 750f5ae हटाना चाहते हैं
आपको इससे स्क्रिप्ट बदलने की आवश्यकता है:
2748cb4 तीसरी प्रतिबद्धता लें
750f5ae दूसरी प्रतिबद्धता उठाओ
716eb99 पहले कमिट करें
इस पर:
2748cb4 को पहले कमिट करें
716eb99 तीसरी कमिटि चुनें

मर्ज करने के लिए
आप मर्ज करने के लिए इच्छित स्क्वैश पर स्क्वैश को बदल सकते हैं।
उदाहरण: आप 750f5ae और 716eb99 वाले कम्बाइन को जोड़ना चाहते हैं।
आपको इससे स्क्रिप्ट बदलने की आवश्यकता है:
2748cb4 तीसरी प्रतिबद्धता लें
750f5ae दूसरी प्रतिबद्धता उठाओ
716eb99 पहले कमिट करें
ऐसे पर
2748cb4 तीसरी प्रतिबद्धता लें
स्क्वैश 750f5ae दूसरी प्रतिबद्धता
स्क्वैश 716eb99 पहली प्रतिबद्ध

ध्यान दें कि इंटरैक्टिव स्क्रिप्ट में, कमिट्स को गिट लॉग की तुलना में रिवर्स ऑर्डर में दिखाया गया है। स्क्वैश का उपयोग करते हुए, आप 750f5ae कमिट को 716eb99 और 750f5ae कमिट के साथ 2748cb4 के साथ जोड़ते हैं। नतीजतन, तीनों में परिवर्तन करने वाला एक प्रतिबद्ध हो रहा है।

2.5 इतिहास देखें

कमांड का उपयोग करना

 git log [<>] [<->] 

आप अपने भंडार का प्रतिबद्ध इतिहास देख सकते हैं। एक विशिष्ट प्रतिबद्ध के लिए छंटाई और खोज के लिए कई विकल्प भी हैं।

उपयोगी गिट लॉग कमांड विकल्प:

• -p - प्रत्येक प्रतिबद्ध के लिए अंतर दिखाता है।
• --stat - प्रत्येक प्रतिबद्ध के लिए संशोधित फ़ाइलों के आँकड़े दिखाता है।
• --graph - शाखाओं के साथ एक ASCII ग्राफ प्रदर्शित करता है और इतिहास का विलय करता है।

आप समय, मात्रा, आदि के अनुसार भी छांट सकते हैं।

• - (n) केवल अंतिम n कमिट दिखाता है।
• --since, --after - निर्दिष्ट तिथि के बाद किए गए शो दिखाता है।
• --until, --before - निर्दिष्ट तिथि से पहले किए गए शो दिखाता है।
• --author - केवल वही दिखाता है जिसमें लेखक प्रविष्टि निर्दिष्ट स्ट्रिंग से मेल खाती है।
• --committer - केवल उन कमिट्स को दिखाता है जिसमें कमिट्री एंट्री निर्दिष्ट स्ट्रिंग से मेल खाती है।
• --grep - केवल वही दिखाता है जिसके संदेश में निर्दिष्ट स्ट्रिंग है।
• -एस - केवल वही दिखाता है जिसमें कोड में बदलाव के कारण निर्दिष्ट लाइन को जोड़ना या हटाना शामिल है।

यहाँ कुछ उदाहरण हैं:
git log --since = 3.weeks - पिछले 2 सप्ताह में प्रदर्शित होता है
git log --since = "2019-01-14" - 2019-01-14 पर किए गए कमिट दिखाएं
git log --since = "2 वर्ष 1 दिन पहले" - 2 वर्ष और एक दिन पहले किए गए कमिट दिखाएं।

आप अपने कम्यूट आउटपुट फॉर्मेट को भी कस्टमाइज़ कर सकते हैं

 git log --format:["format"] 

गिट लॉग --फॉर्म के लिए प्रारूपण विकल्प।

• % ह - कमश हश
• % ज - कमिटेड कम हैश
• % T - ट्री हैश
• % t - छोटा पेड़ हैश
• % P - जनक हैश
• % p - लघु अभिभावक हैश
• % a - लेखक का नाम -% ae - लेखक ईमेल
• % विज्ञापन - लेखक की तारीख (तिथि प्रारूप विकल्प के साथ सेट किया जा सकता है --डेट = विकल्प)
• % ar - लेखक की सापेक्ष तिथि
• % cn - कमेटी का नाम
• % CE - कमेटी ईमेल
• % cd - दिनांक निर्धारित करें
• % cr - सापेक्ष वचन दिनांक
• % s - सामग्री

एक उदाहरण:

 git log --pretty=format:"%h - %ar : %s" 

एक समय हैश और एक प्रतिबद्ध संदेश से मिलकर कमिट की एक सूची दिखाएगा।

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

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

रिमोट रिपॉजिटरी एक बाहरी सर्वर पर संग्रहीत आपकी परियोजना के संस्करण हैं।

बाहरी रिपोजिटरी के साथ काम करने के लिए, उपयोग करें:

 git remote [<options>] 

यदि आपने http URL के माध्यम से रिपॉजिटरी को क्लोन किया है, तो आपके पास पहले से ही बाहरी लिंक है। अन्यथा, आप इसे जोड़ सकते हैं

 git remote add [<options>] <name> <adres> 

आप तुरंत -f, --fetch का उपयोग करके बाहरी शाखाओं को निकाल सकते हैं (आपको बाहरी रिपॉजिटरी की शाखाओं के नाम और राज्य मिलते हैं)। आप केवल --mirror [= (push | fetch)] का उपयोग करके डेटा भेजने या प्राप्त करने के लिए रिपॉजिटरी कॉन्फ़िगर कर सकते हैं। टैग प्राप्त करने के लिए, --tags निर्दिष्ट करें।

कनेक्टेड बाहरी रिपॉजिटरी देखने के लिए, रिपॉजिटरी से डेटा भेजने और प्राप्त करने के लिए पते देखने के लिए कोई तर्क या गिट रिमोट -v के साथ git रिमोट का उपयोग करें।

शाखाओं को ट्रैक करने के लिए, git शाखा का उपयोग करें -u <rep / br> जहां rep रिपॉजिटरी का नाम है, br बाहरी शाखा का नाम है, और शाखा स्थानीय शाखा का नाम है। या git शाखा --सेट-अपस्ट्रीम local_br मूल / br को इंगित करने के लिए कि कौन सी स्थानीय शाखा बाहरी शाखा की निगरानी करेगी।

जब आपकी शाखा किसी बाहरी व्यक्ति पर नज़र रखती है, तो आप यह पता लगा सकते हैं कि कौन सी शाखा (स्थानीय या बाहरी) पीछे या आगे है और कितने पर है। उदाहरण के लिए, यदि एक प्रतिबद्ध के बाद आपने गिट पुश नहीं किया है, तो आपकी शाखा 1 कमिट द्वारा बाहरी एक से आगे होगी। आप git Branch -vv चलाकर इस बारे में पता कर सकते हैं, लेकिन सबसे पहले बाहरी रिपॉजिटरी से नवीनतम डेटा प्राप्त करने के लिए git fetch [रिमोट-नेम] ((सभी रिपॉजिटरी से अपडेट प्राप्त करने के लिए) करें। शाखा ट्रैकिंग को रद्द करने के लिए, git शाखा का उपयोग करें-unset-upstream [<local_branch>]।

बाहरी रिपॉजिटरी से डेटा डाउनलोड करने के लिए, गिट पुल [प्रतिनिधि] [शाखा] का उपयोग करें। यदि आपकी शाखाएं बाहरी ट्रैक करती हैं, तो आप गिट पुल का प्रदर्शन करते समय उन्हें निर्दिष्ट नहीं कर सकते। डिफ़ॉल्ट रूप से, आपको सभी मॉनिटर की गई शाखाओं से डेटा प्राप्त होगा।

शाखाओं को एक नई शाखा में अपलोड करने के लिए, git checkout -b <new_branch_name> <rep / branch> का उपयोग करें।

सर्वर को डेटा भेजने के लिए, का उपयोग करें

 git push [<rep>] [<br>] 

जहाँ प्रतिनिधि बाहरी रिपॉजिटरी का नाम है, और br वह स्थानीय शाखा है जिसे आप भेजना चाहते हैं। आप इस प्रविष्टि git पुश ओरिजिन मास्टर का उपयोग कर सकते हैं: dev। इस प्रकार, आप अपनी स्थानीय मास्टर शाखा को मूल में अपलोड करते हैं (लेकिन वहां इसे देव कहा जाएगा)। यदि आपके पास ऐसा करने की अनुमति नहीं है, तो आप बाहरी भंडार को डेटा नहीं भेज पाएंगे। इसके अलावा, आप किसी बाहरी शाखा को डेटा भेजने में सक्षम नहीं होंगे यदि यह आपके से आगे है (सामान्य तौर पर, आप -f का उपयोग करके भेज सकते हैं, - इस मामले में, आप बाहरी भंडार पर इतिहास को फिर से लिखेंगे)। यदि आपकी शाखा बाहर की ओर ट्रैकिंग कर रही है तो आप शाखा का नाम छोड़ सकते हैं।

बाहरी शाखाओं के उपयोग को हटाने के लिए

 git push origin --delete branch_name 

बाहरी भंडार के बारे में विस्तृत जानकारी के लिए (पते भेजने और प्राप्त करने के लिए, जैसा कि HEAD, बाहरी शाखाओं, गिट्ट पुल के लिए कॉन्फ़िगर की गई स्थानीय शाखाएं और गिट पुश के लिए कॉन्फ़िगर किए गए स्थानीय लिंक)

 git remote show <remote_name> 

बाहरी रिपॉजिटरी का नाम बदलने के लिए, उपयोग करें

 git remote rename <last_name> <new_name> 

बाहरी रिपॉजिटरी के लिंक हटाने के लिए, उपयोग करें

 git remote rm <name> 

3. गिट में शाखा

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

3.1 मूल संचालन

एक शाखा बनाने के लिए, का उपयोग करें

 git branch <branch_name> [<start_commit>] 

यहाँ ब्रांच_नाम नई ब्रांच का नाम है, और start_commit वह कमिट है जिसके लिए ब्रांच इंगित करेगा (अर्थात, इसमें अंतिम कमिट)। डिफ़ॉल्ट रूप से, शाखा मूल शाखा के अंतिम प्रतिबद्ध पर होगी।

Git शाखा विकल्प:

• -आर | -ए [- डूबा हुआ | --no-merged] — -r. -a. --merged. --no-merged.
• -l, -f <-> [<->] — -l. , -f. < >.
• -r (-d | -D) — -r. -d. ( ) -D.
• -m | -M [< >] < > — / (-m). / , -M.
• (- | -) [<->] <-> — -c. , -C.
• -v, -vv - -v शाखा पर अंतिम प्रतिबद्ध के साथ शाखाओं की सूची। अंतिम प्रतिबद्ध के साथ निगरानी शाखाओं की सूची और स्थिति।

अधिक जानकारी के लिए git Branch -h देखें | --help।

शाखा में जाने के लिए, गिट चेकआउट का उपयोग करें। आप git checkout -b <शाखा> चलाकर भी एक शाखा बना सकते हैं।

3.2 शाखाओं को मिलाना

Git रिपोजिटरी की 2 शाखाओं को मर्ज करने के लिए, git मर्ज का उपयोग करें।

गिट मर्ज के लिए उपयोगी विकल्प:

• --squash - विलय के बजाय एक प्रतिबद्ध बनाएँ। यदि आपका शाखाओं पर विरोधाभास है, तो इसे हल करने के बाद, आपके पास शाखा पर जोड़े गए 2 कमिट होंगे (मर्ज की गई शाखा से + मर्ज कमिट), लेकिन इस तर्क को निर्दिष्ट करके आप केवल एक कमिट (मर्ज की गई कमिट) जोड़ देंगे।
• --ff-only - संघर्ष होने पर विलय न करें। किसी और को विवादों को हल करने दें: डी
• -X [रणनीति] - चयनित मर्ज रणनीति का उपयोग करें।
• --abort - मर्ज रद्द करें।

विलय की प्रक्रिया।
यदि आपने मूल शाखा पर नए कमिट को निष्पादित नहीं किया है, तो मर्ज तेजी से आगे की ओर तेजी से बढ़ता है, जैसे कि आप एक नई शाखा नहीं बना रहे हैं, और सभी परिवर्तन यहीं (मूल शाखा पर) हुए हैं।

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

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

करते हैं, उन्होंने संघर्ष को हल कर दिया है, तो आपको कमिट करके मर्ज पूरा करना होगा।

एक संघर्ष के दौरान, आप देख सकते हैं कि किन फ़ाइलों में अंतर मौजूद हैं।
git diff --ours - विलय से पहले अंतर और
git भिन्न - अंतर - विलय से पहले विलय की शाखा का अंतर और
git का अंतर --base - विलय से पहले और बाद में दोनों शाखाओं के साथ अंतर

यदि आप विलय की अनुमति नहीं देना चाहते हैं, तो विभिन्न मर्ज रणनीतियों का उपयोग करें, या तो "हमारा" संस्करण चुनें (जो कि वर्तमान शाखा पर स्थित है) या संघर्ष को ठीक किए बिना मर्ज किए गए शाखा पर स्थित "उनके" संस्करण का चयन करें। क्रमशः git मर्ज - Xours या git मर्ज - Xtheirs चलाएं।

३.३ दुर्लभ

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

फिर से सक्रिय करने के लिए

 git config --global rerere.enabled true 

आप वांछित रिपॉजिटरी में .it / rr-cache डायरेक्टरी बनाकर भी रेयर को सक्षम कर सकते हैं।

मर्ज करने से पहले स्नैपशॉट को सहेजने के लिए कौन सी फाइलें रेयर हैं, यह देखने के लिए गिट रेयर स्टेटस का उपयोग करें।

संघर्ष की वर्तमान स्थिति को देखने के लिए गिट रीरे का उपयोग करें।

यदि मर्ज के दौरान यह कहता है: पिछले समाधान का उपयोग करके 'nameFile' को हल किया गया है। इसलिए रीयर ने पहले ही कैश का उपयोग करते हुए संघर्ष को हल कर दिया है।

स्वचालित विरोध रिज़ॉल्यूशन को रद्द करने के लिए, git checkout --conflict = मर्ज का उपयोग करें ताकि आप स्वचालित विरोध रिज़ॉल्यूशन को रद्द कर दें और फ़ाइल (s) को मैनुअल रिज़ॉल्यूशन के लिए संघर्ष स्थिति में लौटा दें।

4. पॉइंट इन गिट

git में HEAD ब्रांच जैसे पॉइंटर्स हैं। वास्तव में, सब कुछ बहुत सरल है, वर्तमान शाखा को इंगित करता है, और शाखा अंतिम प्रतिबद्ध में इंगित करती है। लेकिन समझने के लिए यह कल्पना करना बेहतर है कि HEAD अंतिम प्रतिबद्ध इंगित करता है।

4.1 मूविंग पॉइंट्स

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

• हेड - अंतिम प्रतिबद्ध का स्नैपशॉट, अगले का जनक
• सूचकांक - अगले आगामी कमिट का स्नैपशॉट
• कार्य निर्देशिका - सैंडबॉक्स

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

इस आदेश के विभिन्न विकल्पों का उपयोग कर आप कर सकते हैं:

• --soft - केवल रीसेट करें
• - मिश्रित - रीसेट हेड और सूचकांक
• --hard - हेड, इंडेक्स और वर्किंग डायरेक्टरी को रीसेट करें

रीसेट के माध्यम से निर्दिष्ट कमिट में जाने का मतलब है। डिफ़ॉल्ट है --mixed।

उदाहरण 1. आपने 3 अतिरिक्त कमिट किए, जिनमें से प्रत्येक में छोटे-छोटे बदलाव किए गए हैं और आप उनमें से एक को बनाना चाहते हैं, इसलिए आप सूचकांक और वर्किंग डायरेक्टरी को अनछुए और कमिट करते हुए HEAD पॉइंटर को स्थानांतरित करने के लिए git reset --soft का उपयोग कर सकते हैं। नतीजतन, आपकी कहानी एक प्रतिबद्ध में हुए सभी परिवर्तनों की तरह दिखाई देगी।

उदाहरण 2. आपने इंडेक्स में अतिरिक्त फाइलें जोड़ीं और उन्हें वहां से हटाना चाहते हैं। आप इसके लिए git reset HEAD <files ...> का उपयोग कर सकते हैं। या क्या आप चाहते हैं कि प्रतिबद्ध फाइलें वापस आने के एक जोड़े की तरह दिखें। जैसा कि मैंने पहले कहा था, आप git रिस्टोर के विपरीत किसी भी कमिट में इंडेक्स को रीसेट कर सकते हैं, जो केवल आखिरी कमिट पर रीसेट होता है। केवल मिश्रित विकल्प के साथ आप निर्दिष्ट फ़ाइल पर कार्रवाई लागू कर सकते हैं!

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

सामान्य तौर पर, मुझे लगता है कि आप मेरे मुकाबले बहुत अधिक उदाहरणों के साथ आ सकते हैं। अंत में, मैं कह सकता हूँ कि गिट रीसेट के साथ आप जादू कर सकते हैं ...

5.

1. Pro git — Scott Chacon
2. Git — . , ,
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Git (2016) — .
14. A Hacker's Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby