दिलचस्प पोस्ट
प्राइवेट फील्ड सदस्य और जवासCRIPT मॉड्यूल पैटर्न में विरासत को परिभाषित करें वेबव्यू एंड्रॉइड पर वेबपेज का एक हिस्सा प्रदर्शित करें सी ++ में मुझे फ़ॉर्मेटमैसेज () ठीक से कैसे उपयोग करना चाहिए? कर सकते हैं AFNetworking वापसी डेटा synchronously (एक ब्लॉक के अंदर)? जावा प्रोग्राम को अपनी स्वयं की प्रक्रिया आईडी कैसे मिल सकती है? GIT submodules एसवीएन बाह्य के साथ असंगत क्यों हैं? फोन देश से कोड देश निकालें क्या एक एकल अद्यतन एसक्यूएल स्टेटमेंट के साथ कई अपडेट करना संभव है? शीघ्र बिना डायल नंबर क्या मेवेन अचूक प्लगइन के साथ जूनियर के लिए "तेज़ विफल" का कोई तरीका है? पायथन में साइन फंक्शन क्यों नहीं है? कैलेंडर के लिए साप्ताहिक ईवेंट जोड़ें एस्पनेट वेब एपीआई के लिए जेडब्ल्यूटी प्रमाणीकरण प्रॉक्सी के पीछे मेवेन और SSL का उपयोग करने में समस्याएं एक स्ट्रिंग लौटने के लिए एक मौजूदा PHP फ़ंक्शन को संशोधित करें

मैं मास्टर / मूल के साथ अलग सिर कैसे सम्मिलित कर सकता हूं?

मैं गिट की शाखाओं की जटिलताओं में नया हूँ मैं हमेशा एक शाखा पर काम करता हूं और परिवर्तन करता हूं और फिर समय-समय पर अपने दूरस्थ मूल को धक्का देता हूं।

कहीं हाल में, मैंने कुछ फाइलों को रीसेट करने के लिए उन्हें मंचन करने से बाहर निकाला, और बाद में एक rebase -i हाल ही में एक स्थानीय स्थानीय प्रतिबद्धता से छुटकारा पाने के लिए अब मैं एक राज्य में हूं जो मुझे काफी समझ में नहीं आ रहा है।

मेरे काम के क्षेत्र में, git log पता चलता है कि मुझे क्या उम्मीद थी – मैं सही ट्रेन पर हूं जो मैं नहीं चाहता था, और वहां नए, आदि।

लेकिन मैं सिर्फ रिमोट रिपॉजिटरी में धकेल दिया, और क्या अलग है – रिवाज़ में मार डाले गये कुछ कथनों को धक्का दिया और स्थानीय स्तर पर बने नए लोग वहां नहीं हैं।

मुझे लगता है कि "मास्टर / मूल" सिर से अलग है, लेकिन मैं इसका मतलब क्या है, यह कैसे कमांड लाइन उपकरण के साथ कल्पना करने के लिए 100% स्पष्ट नहीं है, और इसे कैसे ठीक करें

Solutions Collecting From Web of "मैं मास्टर / मूल के साथ अलग सिर कैसे सम्मिलित कर सकता हूं?"

सबसे पहले, चलो स्पष्ट है कि सिर क्या है और इसका क्या मतलब है जब यह अलग है।

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

  • git symbolic-ref HEAD उपज refs/heads/master
    "मास्टर" नाम की शाखा की जांच की जाती है
  • git rev-parse refs/heads/master 17a02998078923f2d62811326d130de991d1a95a git rev-parse refs/heads/master yield 17a02998078923f2d62811326d130de991d1a95a
    यह प्रतिबद्ध है वर्तमान टिप या मास्टर शाखा के "सिर"।
  • git rev-parse HEAD भी पैदावार 17a02998078923f2d62811326d130de991d1a95a
    यह एक "प्रतीकात्मक रेफरी" होने का अर्थ है यह किसी अन्य संदर्भ के माध्यम से किसी ऑब्जेक्ट को इंगित करता है
    (प्रतीकात्मक रिफॉल्ड्स को मूल रूप से प्रतीकात्मक लिंक के रूप में लागू किया गया था, लेकिन बाद में अतिरिक्त व्याख्या के साथ सादे फाइलों में बदल दिया गया ताकि वे प्लेटफॉर्म्स पर उपयोग किए जा सकें, जिनके लिए सिमुलेशन न हो।)

हमारे पास HEAD refs/heads/master17a02998078923f2d62811326d130de991d1a95a

जब सिर अलग हो जाते हैं, तो यह प्रत्यक्ष रूप से प्रत्यक्ष रूप से एक शाखा के माध्यम से एक ओर इंगित करने के बदले बदले-बदले में इंगित करता है। आप एक अलग सिर के बारे में एक अज्ञात शाखा पर होने के बारे में सोच सकते हैं।

  • git symbolic-ref HEAD fatal: ref HEAD is not a symbolic ref साथ विफल fatal: ref HEAD is not a symbolic ref
  • git rev-parse HEAD उपज 17a02998078923f2d62811326d130de991d1a95a
    चूंकि यह एक प्रतीकात्मक रेफरी नहीं है, इसलिए इसे सीधे खुद को प्रतिबद्ध करना चाहिए।

हमारे पास HEAD17a02998078923f2d62811326d130de991d1a95a

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

1 पृथक प्रधान के साथ "सामान्य" काम करने के लिए पूरी तरह से ठीक है, आपको बस उस ट्रैक का ध्यान रखना होगा कि आप मछली के खाने से बचने के लिए क्या कर रहे हैं।


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

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

 git branch temp git checkout temp 

(इन दो आज्ञाओं को संक्षिप्त रूप में git checkout -b temp रूप से किया जा सकता है)

यह आपके सिर को नई temp शाखा पर फिर से जोड़ देगा।

इसके बाद, आपको वर्तमान शाखा (और उसके इतिहास) की सामान्य शाखा से तुलना करना चाहिए, जिस पर आप काम कर रहे थे:

 git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp git diff master temp git diff origin/master temp 

(आप शायद लॉग विकल्पों के साथ प्रयोग करना चाहेंगे: add -p , छोड़ दें – --pretty=…

अगर आपकी नई temp शाखा अच्छी दिखती है, तो आप उसे इंगित करने के लिए (उदाहरण के लिए) master को अद्यतन करना चाह सकते हैं:

 git branch -f master temp git checkout master 

(इन दो कमांड को git checkout -B master temp रूप में संक्षिप्त किया जा सकता है)

फिर आप अस्थायी शाखा हटा सकते हैं:

 git branch -d temp 

अंत में, आप शायद पुनर्स्थापना इतिहास को पुश करना चाहते हैं:

 git push origin master 

आपको इस आदेश के अंत में --force को जोड़ने की आवश्यकता हो सकती है यदि रिमोट शाखा को नए कमिट के लिए "तेज़-अग्रेषित" नहीं किया जा सकता (यानी आपने कुछ मौजूदा कमेंट को हटा दिया है, या फिर कुछ मौजूदा इतिहास को पुनः लिखना है, या फिर कुछ इतिहास को पुनः लिखना है )।

यदि आप रिबेस ऑपरेशन के बीच में थे तो आपको इसे साफ करना चाहिए आप जांच सकते हैं कि क्या डायरेक्टरी .git/rebase-merge/ तलाश में एक रिसाव प्रक्रिया में था। आप उस निर्देशिका को हटाकर मैन्युअल रूप से इन-प्रगति रिबेस को साफ़ कर सकते हैं (उदाहरण के लिए यदि आपको सक्रिय रिबेस ऑपरेशन के उद्देश्य और संदर्भ याद नहीं हैं)। आम तौर पर आप git rebase --abort प्रयोग करेंगे, लेकिन वह कुछ अतिरिक्त रिसेट करता है जो आप संभवत: से बचने के लिए चाहते हैं (यह मूल को मूल शाखा में वापस git rebase --abort और इसे मूल प्रतिबद्ध में रीसेट कर देता है, जो हम ऊपर दिए गए कुछ काम को पूर्ववत करेंगे )।

बस ऐसा करें:

 git checkout master 

या, अगर आपके पास जो परिवर्तन है जिसे आप रखना चाहते हैं, तो ऐसा करें:

 git checkout -b temp git checkout -B master temp 

मैं इस मुद्दे पर गया था और जब मैंने शीर्ष मतदान में जवाब पढ़ा था:

हेड वर्तमान चेक आउट प्रतिबद्ध के लिए प्रतीकात्मक नाम है।

मैंने सोचा: आह-हा! अगर HEAD currenlty चेकआउट प्रतिबद्ध के लिए प्रतीकात्मक नाम है, तो मैं इसे master विरुद्ध इसे रिसाव करके master साथ सामंजस्य कर सकता हूं:

 git rebase HEAD master 

यह कमांड:

  1. master जांच करता है
  2. माता-पिता को HEAD वापस इंगित करता है master से अलग बिंदु
  3. master शीर्ष पर उन कमान नाटकों

अंतिम परिणाम यह है कि सभी चीजें जो HEAD लेकिन master नहीं हैं, फिर भी mastermaster जाँच की गई है


रिमोट के बारे में:

रिवाज में मारे गए कुछ कथनों को धक्का दे दिया गया, और स्थानीय स्तर पर बने नए लोग वहां नहीं हैं।

आपके स्थानीय इतिहास का उपयोग करके दूरस्थ इतिहास को अब तेज़ी से अग्रेषित नहीं किया जा सकता है दूरस्थ इतिहास को अधिलेखित करने के लिए आपको बल-पुश ( git push -f ) को git push -f की आवश्यकता होगी। यदि आपके पास कोई सहयोगी है, तो यह आमतौर पर उनके साथ समन्वय करने के लिए समझ में आता है ताकि सभी एक ही पृष्ठ पर हों।

master को दूरस्थ origin लिए पुश करने के बाद, आपकी रिमोट ट्रैकिंग शाखा origin/master को उसी प्रतिबद्धता को इंगित करने के लिए अपडेट किया जाएगा, जो master रूप में है।

अलग सिर की बुनियादी व्याख्या के लिए यहां देखें:

http://git-scm.com/docs/git-checkout

इसे देखने के लिए कमांड लाइन:

 git branch 

या

 git branch -a 

आप नीचे की तरह उत्पादन प्राप्त करेंगे:

 * (no branch) master branch1 

* (no branch) पता चलता है कि आप अलग सिर में हैं

आप इस स्थिति में git checkout somecommit आदि कर सकते git checkout somecommit । और इससे आपको निम्नलिखित के साथ चेतावनी दी होगी:

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

यदि आप अपने द्वारा बनाई गई कमिट को बनाए रखने के लिए एक नई शाखा बनाना चाहते हैं, तो आप चेकआउट कमांड के साथ -b का उपयोग करके ऐसा (अब या बाद में) कर सकते हैं। उदाहरण:

जीआईटी चेकआउट- B new_branch_name

अब, उन्हें मास्टर पर लाने के लिए:

एक git reflog या यहां तक ​​कि बस git log और अपने कमान नोट करें। अब git checkout master और git merge कमिट्स को मिला देते हैं।

 git merge HEAD@{1} 

संपादित करें:

जोड़ने के लिए, git rebase -i उपयोग करें git rebase -i न केवल हटाने / हत्या करने की जरूरत है, लेकिन यह भी उन्हें संपादित करने के लिए करता है बस कमिट सूची में "संपादित करें" का उल्लेख करें और आप अपनी प्रतिबद्धता में संशोधन कर सकते हैं और फिर एक git rebase --continue कर सकते हैं – आगे बढ़ने के लिए जारी रखें। यह सुनिश्चित किया होगा कि आप कभी अलग सिर में नहीं आएंगे।

अपनी अलग शाखा को अपनी शाखा पर प्राप्त करें

बस git checkout -b mynewbranch

फिर git log चलाएं, और आप देखेंगे कि प्रतिबद्ध इस नई शाखा पर अब HEAD

अगर आपके पास सिर्फ मास्टर शाखा है और "डेवलपमेंट" या एक फीचर को वापस करना चाहते हैं तो ऐसा करें:

 git checkout origin/develop 

नोट: मूल जांच / विकसित करना

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

फिर

 git checkout -b develop 

यह काम करता हैं 🙂

यदि आप अपने वर्तमान अलग सिर को दबाएं (पहले git log चेक करें), तो कोशिश करें:

 git push origin HEAD:master 

अपने पृथक हेड को मूल शाखा में मूल शाखा में भेजने के लिए यदि आपका धक्का खारिज हो जाता है, तो git pull origin master से परिवर्तन प्राप्त करने के लिए पहले git pull origin master प्रयास करें। यदि आप मूल से परिवर्तनों की परवाह नहीं करते हैं और इसे अस्वीकार कर दिया गया है, क्योंकि आपने कुछ जानबूझकर रिबेस किया है और आप अपने वर्तमान अलग शाखा के साथ मूल / मास्टर को बदलना चाहते हैं – तब आप इसे लागू कर सकते हैं ( -f )। अगर आपने पिछली कमाई तक कुछ एक्सेस खो दी है, तो आप हमेशा सभी शाखाओं से इतिहास देखने के लिए git reflog चला सकते हैं।


किसी मास्टर शाखा पर वापस लाने के लिए, परिवर्तनों को रखने के लिए, निम्न आदेशों का प्रयास करें:

 git rebase HEAD master git checkout master 

देखें: गिट: "वर्तमान में किसी भी शाखा में नहीं।" परिवर्तनों को रखने के दौरान, एक शाखा पर वापस जाने का एक आसान तरीका है?

यदि आप पूरी तरह से सुनिश्चित हैं कि HEAD एक अच्छी स्थिति है:

 git branch -f master HEAD git checkout master 

आप शायद मूल को धक्का नहीं कर सकते, क्योंकि आपका स्वामी मूल से अलग हो चुका है यदि आप निश्चित हैं कि कोई भी रिपो का उपयोग नहीं कर रहा है, तो आप मजबूर कर सकते हैं:

 git push -f 

सबसे उपयोगी यदि आप सुविधा शाखा पर हैं तो कोई और नहीं उपयोग कर रहा है।

आपको केवल 'जीआईटी चेकआउट [शाखा का नाम]' करना है, जहां [शाखा का नाम] मूल शाखा का नाम है, जिसमें से आप एक अलग सिर वाले राज्य में मिला है। (Asdfasdf से अलग) गायब हो जाएगा।

उदाहरण के लिए, शाखा 'देव' में आप asdfasd14314 प्रतिबद्धता जांचते हैं->

 'git checkout asdfasd14314' 

आप एक अलग सिर राज्य में अब कर रहे हैं

'जीआईटी शाखा' की तरह कुछ की सूची होगी ->

 * (detached from asdfasdf) dev prod stage 

लेकिन अलग सिर राज्य से बाहर निकलने के लिए और वापस dev ->

 'git checkout dev' 

और फिर 'git शाखा' की सूची ->

 * dev prod stage 

लेकिन यह निश्चित रूप से है कि यदि आप अलग-अलग सिर वाले राज्य से कोई भी बदलाव रखने का इरादा नहीं करते हैं, लेकिन मुझे कोई ऐसा करने का इरादा नहीं है जो कि कोई बदलाव करने का इरादा रखता है, लेकिन पिछले प्रतिबद्धता को देखने के लिए

आज मैं इस मुद्दे पर बस गया बहुत यकीन है कि मैं इसे करने से हल किया:

 git branch temp git checkout master git merge temp 

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

git checkout origin/master बजाय

बस git checkout master

तो git branch आपकी शाखा की पुष्टि करेगा।

मेरे लिए यह स्थानीय शाखा को फिर से हटाना जितना आसान था, क्योंकि मेरे पास कोई स्थानीय प्रतिबद्धता नहीं थी जिसे मैं धक्का देना चाहता था:

तो मैंने किया: जीआईटी शाखा- D ब्रैंचनमेम

और फिर शाखा को फिर से जांचना

जीआईटी चेकआउट ब्रैनकोनेम

सरल शब्दों में, अलग-अलग सिर वाले राज्य का अर्थ है कि आप किसी भी शाखा के सिर (या टिप) की जांच नहीं कर रहे हैं

उदाहरण के साथ समझें

अधिकांश मामलों में एक शाखा में कई तरह के अनुक्रम का अनुक्रम होता है: –

प्रतिबद्ध 1: मास्टर -> शाखा_एचईएडी (123 बी 6a76168aca712aea16076e971c23835f8ca)

प्रतिबद्ध 2: मास्टर -> 123 बी 6a76168 काका 712aea16076e971c23835f8ca -> शाखा_एचईएडी (100644a76168aca712aea16076e971c23835f8ca)

जैसा कि आप अनुक्रम के मामले में उपरोक्त देख सकते हैं, आपकी शाखा के अंक आपके नवीनतम पापों के अनुसार आते हैं। तो उस स्थिति में अगर आप 123 बी 6 ए 76168ैक 712 एएआई 16076 ई 9 7 सीसी 23835 एफ 8 सी करने का चेकआउट करते हैं तो आप अलग-अलग राज्य में रहेंगे क्योंकि आपकी शाखा के मुख्यालय 100644a76168aca712aea16076e971c23835f8ca से तकनीकी रूप से आपको शाखा की हेड की ओर से जाँच की जाती है। इसलिए, आप अलग-अलग सिर में हैं

सैद्धांतिक व्याख्या

इस ब्लॉग में स्पष्ट रूप से बताते हुए कि गीता भंडार एक पेड़-ऑफ-कमेट्स है, प्रत्येक कमिट पॉइंटर के साथ अपने पूर्वजों की ओर इशारा करते हुए हर अद्यतन को अपडेट किया जाता है और प्रत्येक शाखा में ये पॉइंटर्स .git / refs उप-डायरेक्टरी में जमा होते हैं। टैग्स .git / refs / tags में संग्रहीत किए जाते हैं और शाखाएं .git / refs / heads में संग्रहीत हैं। यदि आप किसी भी फाइल को देखते हैं, तो आप प्रत्येक टैग को एक एकल फ़ाइल के साथ मिलते हैं, 40-वर्णबद्ध हैश के साथ और जैसा कि ऊपर वर्णित है @ क्रिस जॉन्सन और @ यारोस्लाव निकितेंको आप इन संदर्भों को देख सकते हैं

अगर आपने कुछ मास्टर के शीर्ष पर काम किया है और सिर्फ वहां master को "पीछे की तरफ" मर्ज करना चाहते हैं (यानी आप master को इंगित करने के लिए चाहते हैं) तो एक लाइनर होगा:

 git checkout -B master HEAD 
  1. यह master नाम की एक नई शाखा बनाता है, भले ही वह पहले से ही मौजूद हो (जो master तरह चल रहा है और यही हम चाहते हैं)।
  2. नव निर्मित शाखा HEAD को इंगित करने के लिए सेट है, जो कि आप कहां हैं।
  3. नई शाखा बाहर की जाँच की है, तो आप बाद में master पर हैं।

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

मैं वास्तव में मूर्खतापूर्ण स्थिति में आया, मुझे शक है कि किसी और को यह उपयोगी मिलेगा …. लेकिन सिर्फ मामले में

 git ls-remote origin 0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b HEAD 6f96ad0f97ee832ee16007d865aac9af847c1ef6 refs/heads/HEAD 0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b refs/heads/master 

जो मैं अंततः साथ तय की

 git push origin :HEAD 

मेरे मामले में, मैं git status चलाता हूं और मैंने देखा कि मेरी कार्यरत निर्देशिका में कुछ अनचाहे फाइलें थीं।

रिबेस काम करने के लिए, मुझे उन्हें साफ करना पड़ा (क्योंकि मुझे उनकी ज़रूरत नहीं थी)।

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

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

इसके बाद आपको मूल-मास्टर को फिर से जोड़ने में सक्षम होना चाहिए

यह मेरे लिए बिल्कुल काम किया है:

1. अपने स्थानीय संशोधनों को बचाने के लिए git stash

यदि आप परिवर्तनों को छोड़ना चाहते हैं
git clean -df
git checkout -- .
जीआईटी क्लीन ने सभी अनछुटेड फाइलों को हटा दिया है (चेतावनी: जबकि इसे अनदेखी हुई फ़ाइलों को सीधे गितग्नोर में उल्लिखित नहीं हटाया जाएगा, यह फ़ोल्डर्स में रहते हुए अनदेखी हुई फ़ाइलों को हटा सकता है) और जीआईटी चेकआउट सभी अस्थिर बदलावों को साफ करता है

2. मुख्य शाखा में स्विच करने के लिए git checkout master (मान लें कि आप मास्टर का उपयोग करना चाहते हैं)
3. गुरु शाखा से आखिरी प्रतिबद्धता को git pull लिए खींचें
4. सभी की जांच करने के लिए git status बहुत अच्छी लगती है

 On branch master Your branch is up-to-date with 'origin/master'. 

क्रिस के मुताबिक, मैंने निम्नलिखित स्थिति की थी

git symbolic-ref HEAD fatal: ref HEAD is not a symbolic ref साथ विफल fatal: ref HEAD is not a symbolic ref

हालांकि git rev-parse refs/heads/master एक अच्छे काम की ओर इशारा कर रहा था, जहां से मैं ठीक हो सकता हूं (मेरे मामले में आखिरी प्रतिबद्ध है और आप देख सकते हैं कि git show [SHA]

उसके बाद मैंने बहुत गन्दा बातें कीं, लेकिन जो तय हुआ लगता है वह बस है,

git symbolic-ref HEAD refs/heads/master

और सिर फिर से जुड़ा हुआ है!

जब मैं खुद को किसी स्थिति में मिल जाता हूं, जब यह पता चला है कि जब मैं master में नहीं हूं (यानी HEAD master ऊपर अलग है और बीच में कोई कमी नहीं है) सहेजे हुए हो सकता है:

 git stash # HEAD has same content as master, but we are still not in master git checkout master # switch to master, okay because no changes and master git stash apply # apply changes we had between HEAD and master in the first place 
 git checkout checksum #you could use this to peek previous checkpoints git status # you will see HEAD detached at checksum git checkout master #this moves HEAD to master branch