गिट-चेकआउट - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

गिट-चेकआउट - शाखाएं बदलें या कार्यशील ट्री फ़ाइलों को पुनर्स्थापित करें

SYNOPSIS

Git जांच [-क्यू] [-एफ] [-एम] []
Git जांच [-q] [-f] [-m] --अलग करें []
Git जांच [-क्यू] [-एफ] [-एम] [--डिटैच]
Git जांच [-q] [-f] [-m] [[-b|-B|--अनाथ] ] []
Git जांच [-f|--हमारा|--उनका|-m|--संघर्ष=] [] [--] ...
Git जांच [-पी|--पैच] [] [--] [...]

वर्णन

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

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

यदि नहीं मिली है लेकिन ठीक एक रिमोट में एक ट्रैकिंग शाखा मौजूद है
(इसे कॉल करें ) एक मेल खाते नाम के साथ, इसके समकक्ष मानें

$ गिट चेकआउट -बी --ट्रैक /

आप को छोड़ सकते हैं, ऐसी स्थिति में कमांड "चेक आउट" में परिवर्तित हो जाता है
वर्तमान शाखा", जो कि महँगे दुष्प्रभावों वाला एक महिमामंडित नो-ऑप है
वर्तमान शाखा के लिए केवल ट्रैकिंग जानकारी दिखाएं, यदि मौजूद है।

Git जांच -बी|-बी []
-b निर्दिष्ट करने से मानो एक नई शाखा बन जाती है Git शाखा(1) को बुलाया गया और
फिर चेक आउट किया. इस स्थिति में आप --ट्रैक या --नो-ट्रैक विकल्प का उपयोग कर सकते हैं, जो
को पारित किया जाएगा Git शाखा. एक सुविधा के रूप में, -ट्रैक विदाउट -बी का तात्पर्य शाखा से है
निर्माण; --ट्रैक का विवरण नीचे देखें।

यदि -B दिया गया है, यदि यह अस्तित्व में नहीं है तो बनाया जाता है; अन्यथा, इसे रीसेट कर दिया जाता है.
यह का लेन-देन समतुल्य है

$ गिट शाखा -एफ []
$ गिट चेकआउट

कहने का तात्पर्य यह है कि, शाखा तब तक रीसेट/बनाई नहीं जाती जब तक कि "गिट चेकआउट" सफल न हो जाए।

Git जांच --अलग करें [], Git जांच [--डिटैच]
के शीर्ष पर HEAD को अलग करके काम करने की तैयारी करें (देखें "डिटैच्ड हेड"
अनुभाग), और कार्यशील ट्री में अनुक्रमणिका और फ़ाइलों को अद्यतन करना। स्थानीय
कार्यशील ट्री में फ़ाइलों में संशोधन रखे जाते हैं, ताकि परिणामी कार्यशील हो सके
ट्री कमिट में दर्ज की गई स्थिति और स्थानीय संशोधन होगा।

जब तर्क एक शाखा का नाम है, तो अलग करने के लिए --detach विकल्प का उपयोग किया जा सकता है
शाखा के सिरे पर HEAD (git checkout उस शाखा की जाँच करेगा
सिर अलग किए बिना)।

को छोड़ने से वर्तमान शाखा के सिरे पर HEAD अलग हो जाता है।

Git जांच [-पी|--पैच] [] [--] ...
जब या --पैच दिए जाते हैं, Git जांच कर देता है नहीं शाखाएँ बदलें. यह अद्यतन होता है
इंडेक्स फ़ाइल से या नामित से कार्यशील ट्री में नामित पथ
(अक्सर एक प्रतिबद्धता)। इस मामले में, -बी और --ट्रैक विकल्प अर्थहीन हैं और
इनमें से किसी एक को देने पर त्रुटि होती है। तर्क का उपयोग किया जा सकता है
के लिए इंडेक्स को अपडेट करने के लिए एक विशिष्ट ट्री-ईश (यानी कमिट, टैग या ट्री) निर्दिष्ट करें
वर्किंग ट्री को अपडेट करने से पहले दिए गए पथ।

Git जांच संशोधित या हटाए गए पथों को पुनर्स्थापित करने के लिए या --पैच का उपयोग किया जाता है
सूचकांक से उनकी मूल सामग्री या किसी नामित सामग्री से पथ बदलें
(अक्सर एक प्रतिबद्ध-ish)।

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

विकल्प

-क्यू, --शांत
शांत रहें, प्रतिक्रिया संदेशों को दबाएँ।

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

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

सूचकांक से पथों की जाँच करते समय, असंबद्ध प्रविष्टियों पर असफल न हों; बजाय,
असंबद्ध प्रविष्टियों को नजरअंदाज कर दिया जाता है।

--हमारा, --उनका
सूचकांक से पथों की जाँच करते समय, चरण #2 (Pyrenean भालू (पृष्ठ मौजूद नहीं है)) या #3 (उन लोगों के) के लिए
असंबद्ध पथ.

ध्यान दें कि git रिबेस और git पुल--रीबेस के दौरान, Pyrenean भालू (पृष्ठ मौजूद नहीं है) और उन लोगों के बदला हुआ दिखाई दे सकता है;
--ours उस शाखा से संस्करण देता है जिस पर परिवर्तन पुनः आधारित होते हैं, जबकि --theirs
उस शाखा से संस्करण देता है जिसमें आपका कार्य रखा जाता है जिसे दोबारा आधार बनाया जा रहा है।

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

-बी
नाम से एक नई शाखा बनाएं और इसे पर शुरू करें; देखना गिट-
शाखा(२९) विवरण के लिए।

-बी
शाखा बनाता है और इसे पर प्रारंभ करता है; यदि यह पहले से मौजूद है,
फिर इसे पर रीसेट करें। यह "-f" के साथ "git ब्रांच" चलाने के बराबर है;
देखना Git शाखा(२९) विवरण के लिए।

-टी, --ट्रैक
नई शाखा बनाते समय, "अपस्ट्रीम" कॉन्फ़िगरेशन सेट करें। में "--ट्रैक" देखें गिट-
शाखा(२९) विवरण के लिए।

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

--कोई रास्ता नहीं हे
"अपस्ट्रीम" कॉन्फ़िगरेशन सेट न करें, भले ही शाखा.autoSetupMerge
कॉन्फ़िगरेशन चर सत्य है.

-l
नई शाखा का रीफ्लॉग बनाएं; देखना Git शाखा(२९) विवरण के लिए।

-- अलग करना
इस पर काम करने के लिए किसी शाखा की जाँच करने के बजाय, निरीक्षण के लिए एक समिति की जाँच करें
त्यागने योग्य प्रयोग. यह "git checkout " का डिफ़ॉल्ट व्यवहार है
एक शाखा का नाम नहीं है. विवरण के लिए नीचे "अलग किया गया सिर" अनुभाग देखें।

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

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

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

यदि आप एक डिस्कनेक्टेड इतिहास शुरू करना चाहते हैं जो पथों का एक सेट रिकॉर्ड करता है
में से एक से बिल्कुल अलग, तो आपको इंडेक्स को साफ़ करना चाहिए
"git rm -rf" चलाकर अनाथ शाखा बनाने के ठीक बाद कार्यशील वृक्ष। से
कार्यशील वृक्ष का शीर्ष स्तर। बाद में आप अपना नया तैयार करने के लिए तैयार होंगे
फ़ाइलें, कार्यशील वृक्ष को अन्यत्र से कॉपी करके, पुनः आबाद करना, a निकालना
टारबॉल, आदि

--अनदेखा-स्किप-वर्कट्री-बिट्स
विरल चेकआउट मोड में, git checkout -- केवल मिलान वाली प्रविष्टियों को अपडेट करेगा
$GIT_DIR/info/sparse-checkout में और विरल पैटर्न। यह विकल्प अनदेखा करता है
विरल पैटर्न और में किसी भी फ़ाइल को वापस जोड़ता है।

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

जब मर्ज विरोध होता है, तो परस्पर विरोधी पथों के लिए सूचकांक प्रविष्टियाँ छोड़ दी जाती हैं
असंबद्ध, और आपको विरोधों को हल करने और हल किए गए पथों को गिट के साथ चिह्नित करने की आवश्यकता है
जोड़ें (या git rm यदि मर्ज के परिणामस्वरूप पथ हट जाना चाहिए)।

इंडेक्स से पथों की जांच करते समय, यह विकल्प आपको विवादित को फिर से बनाने की सुविधा देता है
निर्दिष्ट पथों में विलय करें.

--संघर्ष=
उपरोक्त --merge विकल्प के समान, लेकिन परस्पर विरोधी समूहों के तरीके को बदल देता है
मर्ज.कॉन्फ्लिक्टस्टाइल कॉन्फ़िगरेशन वैरिएबल को ओवरराइड करते हुए प्रस्तुत किया गया। संभावित मान
"मर्ज" (डिफ़ॉल्ट) और "diff3" हैं ("मर्ज" शैली द्वारा दिखाए गए के अलावा,
मूल सामग्री दिखाता है)।

-पी, --पैच
(या सूचकांक, यदि) के बीच अंतर में इंटरएक्टिव रूप से हंक का चयन करें
अनिर्दिष्ट) और कार्यशील वृक्ष। फिर चुने गए हंक को इसके विपरीत लगाया जाता है
कार्यशील वृक्ष (और यदि निर्दिष्ट किया गया था, तो सूचकांक)।

इसका मतलब यह है कि आप अपने संपादनों को चुनिंदा रूप से हटाने के लिए git checkout -p का उपयोग कर सकते हैं
वर्तमान कार्यशील वृक्ष. का "इंटरएक्टिव मोड" अनुभाग देखें git-जोड़ें(1) कैसे सीखें
--पैच मोड संचालित करें।

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


चेकआउट करने के लिए शाखा; यदि यह किसी शाखा को संदर्भित करता है (अर्थात, एक नाम जिसके साथ जोड़ने पर
"रेफ्स/हेड्स/", एक वैध रेफरी है), फिर उस शाखा की जांच की जाती है। अन्यथा, यदि यह
एक वैध प्रतिबद्धता को संदर्भित करता है, आपका HEAD "अलग" हो जाता है और आप अब किसी पर नहीं हैं
शाखा (विवरण के लिए नीचे देखें)।

एक विशेष मामले के रूप में, एन-वें अंतिम शाखा/प्रतिबद्धता के लिए "@{-N}" सिंटैक्स की जांच की जाती है
शाखाएँ (अलग करने के बजाय)। आप यह भी निर्दिष्ट कर सकते हैं - जिसका पर्यायवाची है
"@{-1}"।

एक और विशेष मामले के रूप में, आप ए के मर्ज बेस के शॉर्टकट के रूप में "ए...बी" का उपयोग कर सकते हैं
और बी यदि बिल्कुल एक मर्ज आधार है। आप ए और बी में से अधिकतम एक को छोड़ सकते हैं
किस स्थिति में यह HEAD पर डिफ़ॉल्ट होता है।


नई शाखा का नाम.


उस प्रतिबद्धता का नाम जिस पर नई शाखा शुरू की जानी है; देखना Git शाखा(२९) विवरण के लिए।
डिफ़ॉल्ट रूप से HEAD.


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

अलग सिर

HEAD सामान्यतः एक नामित शाखा को संदर्भित करता है (उदा. मास्टर). इस बीच, प्रत्येक शाखा एक को संदर्भित करती है
विशिष्ट प्रतिबद्धता. आइए तीन कमिट वाले रेपो को देखें, उनमें से एक को टैग किया गया है, और साथ में
शाखा मास्टर बाहर की जाँच:

प्रमुख (शाखा 'मास्टर' को संदर्भित करता है)
|
v
ए---बी---सी शाखा 'मास्टर' (कमिट 'सी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

जब इस स्थिति में एक कमिट बनाई जाती है, तो नई कमिट को संदर्भित करने के लिए शाखा को अद्यतन किया जाता है।
विशेष रूप से, Git करना एक नई प्रतिबद्धता बनाता है d, जिसके माता-पिता प्रतिबद्ध हैं c, और फिर
अद्यतन शाखा मास्टर नई प्रतिबद्धता का उल्लेख करने के लिए d. HEAD अभी भी शाखा को संदर्भित करता है मास्टर इसलिए
अप्रत्यक्ष रूप से अब प्रतिबद्धता को संदर्भित करता है d:

$ संपादित करें; गिट जोड़ें; गिट प्रतिबद्ध

प्रमुख (शाखा 'मास्टर' को संदर्भित करता है)
|
v
ए---बी---सी---डी शाखा 'मास्टर' (कमिट 'डी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

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

$ git चेकआउट v2.0 # या
$ गिट चेकआउट मास्टर^^

प्रमुख (प्रतिबद्ध 'बी' को संदर्भित करता है)
|
v
ए---बी---सी---डी शाखा 'मास्टर' (कमिट 'डी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

ध्यान दें कि चाहे हम किसी भी चेकआउट कमांड का उपयोग करें, HEAD अब सीधे संदर्भित करता है
करना b. इसे पृथक् HEAD अवस्था में होना कहा जाता है। इसका सीधा मतलब यह है कि HEAD का तात्पर्य है
किसी नामित शाखा को संदर्भित करने के विपरीत, किसी विशिष्ट प्रतिबद्धता के लिए। चलो देखते हैं क्या होता हैं
जब हम एक कमिट बनाते हैं:

$ संपादित करें; गिट जोड़ें; गिट प्रतिबद्ध

हेड (प्रतिबद्ध 'ई' को संदर्भित करता है)
|
v
e
/
ए---बी---सी---डी शाखा 'मास्टर' (कमिट 'डी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

अब एक नई प्रतिबद्धता है e, लेकिन इसका संदर्भ केवल HEAD द्वारा दिया गया है। हम निश्चित रूप से अभी भी जोड़ सकते हैं
इस राज्य में एक और प्रतिबद्धता:

$ संपादित करें; गिट जोड़ें; गिट प्रतिबद्ध

HEAD (प्रतिबद्ध 'एफ' को संदर्भित करता है)
|
v
ई---एफ
/
ए---बी---सी---डी शाखा 'मास्टर' (कमिट 'डी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

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

$ गिट चेकआउट मास्टर

प्रमुख (शाखा 'मास्टर' को संदर्भित करता है)
ई---एफ |
/ वी
ए---बी---सी---डी शाखा 'मास्टर' (कमिट 'डी' को संदर्भित करता है)
^
|
टैग 'v2.0' (कमिट 'बी' को संदर्भित करता है)

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

$ गिट चेकआउट -बी फू (1)
$ गिट शाखा फू (2)
$ गिट टैग फू (3)

1. एक नई शाखा बनाता है foo, जो प्रतिबद्धता को संदर्भित करता है f, और फिर संदर्भित करने के लिए HEAD को अपडेट करता है
शाखा foo. दूसरे शब्दों में, इस आदेश के बाद हम अब अलग HEAD स्थिति में नहीं रहेंगे।
2. इसी प्रकार एक नई शाखा बनाता है foo, जो प्रतिबद्धता को संदर्भित करता है f, लेकिन HEAD को अलग छोड़ देता है।
3. एक नया टैग बनाता है foo, जो प्रतिबद्धता को संदर्भित करता है f, HEAD को अलग छोड़कर।

अगर हम प्रतिबद्धता से दूर चले गए हैं f, तो हमें पहले इसका ऑब्जेक्ट नाम (आमतौर पर) पुनर्प्राप्त करना होगा
git reflog का उपयोग करके), और फिर हम इसका एक संदर्भ बना सकते हैं। उदाहरण के लिए, देखने के लिए
अंतिम दो कमिट जिन्हें HEAD ने संदर्भित किया है, हम इनमें से किसी भी कमांड का उपयोग कर सकते हैं:

$ गिट रीफ्लॉग -2 हेड # या
$ गिट लॉग -जी -2 हेड

उदाहरण

1. निम्नलिखित अनुक्रम मास्टर शाखा की जांच करता है, मेकफ़ाइल को दो में वापस लाता है
संशोधन वापस करता है, गलती से hello.c को हटा देता है, और इसे सूचकांक से वापस ले लेता है।

$ गिट चेकआउट मास्टर (1)
$ गिट चेकआउट मास्टर~2 मेकफ़ाइल (2)
$ आरएम-एफ हेलो.सी
$ गिट चेकआउट हेलो.सी (3)

1. स्विच शाखा
2. किसी अन्य कमिट से एक फ़ाइल निकालें
3. इंडेक्स से hello.c को पुनर्स्थापित करें

आप की जाँच करना चाहते हैं सब सी स्रोत फ़ाइलें अनुक्रमणिका से बाहर हैं, आप कह सकते हैं

$ गिट चेकआउट -- '*.c'

*.c के आसपास के उद्धरणों पर ध्यान दें। फ़ाइल hello.c की भी जाँच की जाएगी, भले ही यह
अब कार्यशील ट्री में नहीं है, क्योंकि फ़ाइल ग्लोबिंग का उपयोग प्रविष्टियों के मिलान के लिए किया जाता है
सूचकांक में (शेल द्वारा कार्यशील वृक्ष में नहीं)।

यदि आपके पास एक दुर्भाग्यपूर्ण शाखा है जिसका नाम hello.c है, तो यह कदम भ्रमित करने वाला होगा
उस शाखा में स्विच करने के निर्देश के रूप में। आपको इसके बजाय लिखना चाहिए:

$ गिट चेकआउट -- हेलो.सी

2. गलत ब्रांच में काम करने के बाद सही ब्रांच में स्विच करना होगा
का उपयोग कर:

$ गिट चेकआउट मायटॉपिक

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

$ गिट चेकआउट मायटॉपिक
त्रुटि: आपके पास 'फ्रोट्ज़' में स्थानीय परिवर्तन हैं; शाखाएँ नहीं बदलना.

आप कमांड को -m फ़्लैग दे सकते हैं, जो तीन-तरफ़ा मर्ज का प्रयास करेगा:

$ गिट चेकआउट -एम मायटॉपिक
ऑटो-मर्जिंग फ्रोट्ज़

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

3. जब -m विकल्प के साथ शाखाओं को स्विच करने के दौरान मर्ज संघर्ष होता है, तो आप ऐसा करेंगे
कुछ इस तरह देखें:

$ गिट चेकआउट -एम मायटॉपिक
ऑटो-मर्जिंग फ्रोट्ज़
त्रुटि: फ़्रोट्ज़ में संघर्ष को मर्ज करें
घातक: मर्ज प्रोग्राम विफल रहा

इस बिंदु पर, git diff पिछले उदाहरण की तरह स्पष्ट रूप से मर्ज किए गए परिवर्तनों को दिखाता है,
साथ ही विवादित फ़ाइलों में परिवर्तन भी। विवाद को संपादित करें और हल करें और चिह्नित करें
इसे हमेशा की तरह git add के साथ हल किया गया:

$ फ्रोट्ज़ संपादित करें
$ git फ्रोट्ज़ जोड़ें

GIT

का हिस्सा Git(1) सुइट

onworks.net सेवाओं का उपयोग करके ऑनलाइन git-checkout का उपयोग करें