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

1558

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

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

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

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

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

git

— बेन ज़ोटो
स्रोत

क्या आपने रिबेट से पहले कमिट को धक्का दिया है?

— 18

@manojlds: निश्चित नहीं कि आपका क्या मतलब है। मैंने रिबास से कुछ समय पहले धक्का दिया, लेकिन तुरंत पहले नहीं।

— बेन ज़ोटो

जैसा कि आपने पहले किया था कि कमिट को आपने रिबेस-आई में हटा दिया था .. आपके उत्तर से मुझे लगता है कि नहीं।

— मनोज् यों

@ श्रमजीवी: सही। मैंने केवल उन कमिट्स को मार दिया जो हाल ही में हुए सबसे ज्यादा पुश थे। (हालांकि जैसा कि मैंने उल्लेख किया है, मैंने तब से धक्का दिया है, जब से मैंने सोचा कि सब कुछ ठीक था)

— बेन झोट्टो

क्या आप बता सकते हैं कि आपने क्या किया I did a reset of some files to get them out of commit staging? प्रश्नों के लिए खेद है :)

— manojisions

2521

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

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

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

हम HEAD→ refs/heads/master→17a02998078923f2d62811326d130de991d1a95a

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

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

हमारे पास HEAD→ है17a02998078923f2d62811326d130de991d1a95a

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

¹ एक अलग सिर के साथ "सामान्य" काम करना पूरी तरह से ठीक है, आपको बस इस बात का ध्यान रखना होगा कि आप क्या कर रहे हैं कि मछली को इतिहास से हटा दिया जाए।

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

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

git branch temp
git checkout temp

_{(इन दोनों आदेशों को संक्षिप्त रूप में देखा जा सकता है git checkout -b temp)}

यह आपके HEAD को नई tempब्रांच में पहुंचा देगा ।

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

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

(आप लॉग विकल्पों के साथ प्रयोग करना चाहेंगे: संपूर्ण लॉग संदेश, आदि देखने के लिए -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, लेकिन यह कुछ अतिरिक्त रीसेट करता है जिसे आप शायद बचना चाहते हैं (यह HEAD को मूल शाखा में वापस ले जाता है और इसे वापस मूल प्रतिबद्ध में रीसेट करता है, जो हमारे द्वारा किए गए कुछ कार्यों को पूर्ववत कर देगा)।

— क्रिस जॉन्सन
स्रोत

6

इससे दिलचस्प man git-symbolic-ref: "अतीत में, .git/HEADएक सांकेतिक लिंक था जो इंगित करता था refs/heads/master। जब हम किसी अन्य शाखा में स्विच करना चाहते थे, हमने किया था ln -sf refs/heads/newbranch .git/HEAD, और जब हम यह पता लगाना चाहते थे कि हम किस शाखा पर हैं, तो हमने किया readlink .git/HEAD। लेकिन प्रतीकात्मक लिंक पूरी तरह से पोर्टेबल नहीं हैं। , इसलिए वे अब पदावनत और प्रतीकात्मक रेफ (जैसा कि ऊपर वर्णित है) डिफ़ॉल्ट रूप से उपयोग किया जाता है। "

— दिमित्री मिंकोवस्की

10

मैं @AntonioSesto से सहमत हूं: अधिकांश परियोजनाओं के लिए (यहां तक कि काफी बड़े लोगों के लिए) आपको मन की जटिल जटिलता की आवश्यकता नहीं है जो कि Git है। मेरा दिमाग किसी ऐसी चीज़ से जूझ रहा है जो इतनी स्पष्ट रूप से अति-इंजीनियर है। मुझे इसकी आवश्यकता नहीं है, और मुझे यह नहीं चाहिए।

— जैस्पर स्प्रेयर्स

36

यह एक अच्छा उत्तर है, लेकिन मुझे लगता है कि अस्थायी शाखा की कोई आवश्यकता नहीं है (हालांकि मैं आमतौर पर अपने स्वयं के उपयोग करता हूं)। git branch -f master HEAD && git checkout masterपर्याप्त है - अपने लक्ष्य को संभालने के लिए अपने वर्तमान सिर रखने के लिए लेकिन यह रूप में नामित है master। अन्य लक्ष्य भी समझ में आते हैं, और अन्य व्यंजनों के लिए कॉल करते हैं।

— एड्रियन रत्नापला

38

लंबाई के बारे में टिप्पणी करने पर योग्य। जबकि हम में से बाकी लोग बस तब तक स्कैन करते हैं जब तक हम उस रेखा तक नहीं पहुंच जाते हैं जो कहती है कि "अपनी स्थिति से उबरने के लिए [...]", और वहां से जाएं - एक मानसिक नोट बनाते हुए कि एक उपयोगी अच्छी तरह से समझाया गया बैकस्टोरी है जिसे हम पढ़ सकते हैं एक बरसात के दिन में। विकल्प और अधिक तुम्हें चोट लगी नहीं है पढ़ने के लिए, लेकिन यह करता है लाभ दूसरों को खड़े हैं।

— अंडरस्कोर_ड

5

यह इसलिए है कि मुझे गिट से नफरत है।

— मोनिका हेडडेक

626

बस यह करें:

git checkout master

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

git checkout -b temp
git checkout -B master temp

— डैनियल एलेक्सी
स्रोत

57

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

— आर्चोनिक

15

"डिटेल चेकआउट मास्टर" सभी बदलावों का कारण बन जाएगा अगर अलग किया गया सिर मास्टर का हिस्सा नहीं है !!

— टोनी

3

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

— डैनियल अलेक्सियस जू

1

git resetएक चेतावनी के साथ आना चाहिए "यदि आपके पास कोई विचार नहीं है कि आप क्या कर रहे हैं, तो इसे रोकें"। बस एक घंटे की आतंकी सोच से उबरकर मैं काम के आखिरी हफ्ते में हार गया। धन्यवाद!

— Opus1217

1

@Archonic से सहमत होना यह समझना महत्वपूर्ण है कि किसी भी कमांड को आँख बंद करके चलाने से पहले git कैसे काम करता है। आप बड़े उत्तर को न पढ़कर समय बचा सकते हैं, लेकिन यदि आपका काम खो गया है तो अधिक समय खो सकते हैं।

— युसुफाली २०२६

132

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

HEAD वर्तमान में जाँच की गई कमेटी का प्रतीकात्मक नाम है।

मैंने सोचा: आह-हा! यदि HEADकर्नेलिटी चेकआउट कमेटी के लिए प्रतीकात्मक नाम है, तो मैं इसके खिलाफ masterपलटवार करके इसे समेट सकता हूं master:

git rebase HEAD master

यह आदेश:

चेक आउट master
मूल HEADबिंदु से वापस आने वाले अभिभावकों की पहचान करता HEADहैmaster
उन लोगों के शीर्ष पर खेलता है master

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

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

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

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

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

— दिमित्री मिनकोवस्की
स्रोत

3

git: "सबसे पहले, अपने काम को फिर से करने के लिए सिर को फिर से खोलना ... HEAD को फास्ट-फॉरवर्ड मास्टर।" मुझे: "अच्छा!"

— बेंजामिन

81

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

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

यह कल्पना करने के लिए कमांड लाइन:

git branch

या

git branch -a

आपको नीचे जैसा आउटपुट मिलेगा:

* (no branch)
master
branch1

* (no branch)शो आप अलग सिर में कर रहे हैं।

आप git checkout somecommitआदि करके इस अवस्था में आ सकते हैं और यह आपको निम्नलिखित बातों से आगाह कर सकता है:

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

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

git चेकआउट -b new_branch_name

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

एक git reflogया भी बस करो git logऔर अपने कामों पर ध्यान दें। अब git checkout masterऔर git mergeकरता है।

git merge HEAD@{1}

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

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

— manojlds
स्रोत

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

— बेन ज़ोट्टो

6

"@ {1}" क्या करता है?

— ईबी

35

अपनी शाखा पर अपनी अलग कमिट करें

बस चलाते हैं git checkout -b mynewbranch।

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

— रोज़ पेरोन
स्रोत

यदि मैं ऐसा करता हूं, तो क्या mynewbranchकुछ भी संलग्न है?

— बेन्जोन

1

हां, यह संलग्न करता है कि अलग किए गए सिर को कहां संलग्न किया गया है, जो कि वास्तव में मैं चाहता था। धन्यवाद!

— बेन्जोन

22

यदि आपके पास सिर्फ मास्टर शाखा है और "विकास" या एक सुविधा के लिए वापस आना चाहते हैं:

git checkout origin/develop

नोट: मूल की जाँच / विकास ।

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

फिर

git checkout -b develop

यह काम करता हैं :)

— amdev
स्रोत

7

मेरे लिए जो काम किया है वह 'git checkout उत्पत्ति / विकास' नहीं है, बल्कि 'git checkout develop' है। 'उत्पत्ति / विकास' का उपयोग करने से हमेशा कोई परिवर्तन नहीं होता है, जिससे "उत्पत्ति / विकास में बाधा" होती है। 'मूल' भाग को छोड़कर सब कुछ तय हो गया।

— DrStrangepork

18

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

git push origin HEAD:master

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

परिवर्तनों को ध्यान में रखते हुए, मुख्य शाखा पर वापस जाने के लिए, निम्न आदेशों को आज़माएँ:

git rebase HEAD master
git checkout master

देखें: Git: "वर्तमान में किसी भी शाखा में नहीं।" क्या बदलावों को ध्यान में रखते हुए, एक शाखा पर वापस जाने का एक आसान तरीका है?

— kenorb
स्रोत

2

यह वास्तव में मूल / मास्टर को अलग किए गए कमिट भेजता है। स्थानीय शाखा के प्रमुख को संलग्न करने के लिए ऐसा करें: stackoverflow.com/a/17667057/776345

— पास्कलिस

जब मैं ऐसा करता हूं तो मुझे यह रिपॉजिटरी Git LFS के लिए कॉन्फ़िगर किया जाता है, लेकिन 'git-lfs' आपके पथ पर नहीं मिला। यदि आप Git LFS का उपयोग नहीं करना चाहते हैं, तो। हुक / हुक / पोस्ट-चेकआउट हटाकर इस हुक को हटा दें।

— user2568374

16

खोजते समय मुझे यह प्रश्न मिला You are in 'detached HEAD' state.

मैंने यहाँ आने के लिए जो किया था उसका विश्लेषण करने के बाद, जैसा कि मैंने अतीत में किया था, मुझे पता चला कि मैंने गलती की थी।

मेरा सामान्य प्रवाह है:

git checkout master
git fetch
git checkout my-cool-branch
git pull

इस बार मैंने किया:

git checkout master
git fetch
git checkout origin/my-cool-branch
# You are in 'detached HEAD' state.

समस्या यह है कि मैंने गलती से:

git checkout origin/my-cool-branch

बजाय:

git checkout my-cool-branch

फिक्स (मेरी स्थिति में) बस उपरोक्त कमांड चलाने के लिए था और फिर प्रवाह जारी रखें:

git checkout my-cool-branch
git pull

— user664833
स्रोत

11

निम्नलिखित ने मेरे लिए काम किया (केवल शाखा मास्टर का उपयोग करके):

git push origin HEAD:master
git checkout master        
git pull

पहले वाला दूरस्थ स्थान पर अलग किए गए HEAD को धकेलता है।

दूसरा एक शाखा मास्टर के पास जाता है।

तीसरा एक हेड को ठीक करता है जो शाखा मास्टर से जुड़ जाता है।

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

— डैनियल पोरुम्बेल
स्रोत

काम नहीं किया, मुझे मिल गया: यह रिपॉजिट Git LFS के लिए कॉन्फ़िगर किया गया है लेकिन 'git-lfs' आपके पथ पर नहीं मिला। यदि आप Git LFS का उपयोग नहीं करना चाहते हैं, तो। हुक / हुक / पूर्व-पुश को हटाकर इस हुक को हटा दें। और आप वर्तमान में एक शाखा पर नहीं हैं। कृपया निर्दिष्ट करें कि आप किस शाखा के साथ विलय करना चाहते हैं।

— user2568374

11

मैं आज इस मुद्दे पर भाग गया और मुझे पूरा यकीन है कि मैंने इसे हल कर लिया है:

git branch temp
git checkout master
git merge temp

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

— adamwineguy
स्रोत

@StarShine केनोरब ने इसे ठीक किया। अब यह आपके अलग किए गए कमिट को एक नई शाखा, टेम्प, मास्टर में स्विच करता है और टेम्प को मास्टर में विलय करता है।

— सेस टिम्मरमैन

मुझे नहीं पता कि ppl इसे क्यों डाउनवोट कर रहा है, इसने मेरी समस्या स्टेट को ठीक कर दिया है लेकिन आप डिलीट टेंप ब्रांच कमांड को शामिल करना चाह सकते हैं।

— ग्लासगॉस्ट

8

यदि आप पूरी तरह से आश्वस्त हैं कि हेड अच्छा राज्य है:

git branch -f master HEAD
git checkout master

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

git push -f

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

— geon
स्रोत

6

आपको बस इतना करना है कि 'git checkout [ब्रांच-नेम]' जहां [ब्रांच-नेम] ओरिजिनल ब्रांच का नाम है, जहां से आप अलग हेड स्टेट में आए थे। गायब हो जाएगा (asdfasdf से अलग)।

उदाहरण के लिए, शाखा 'देव' में आप कमिट करें asdfasd14314 ->

'git checkout asdfasd14314'

अब आप अलग अवस्था में हैं

'गिट ब्रांच ’कुछ इस तरह सूचीबद्ध करेगी ->

* (detached from asdfasdf)
  dev
  prod
  stage

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

'git checkout dev'

और फिर 'गिट ब्रांच' सूची देगी ->

* dev
  prod
  stage

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

— एडम फ्रीमैन
स्रोत

6

जैसा कि क्रिस ने कहा था, मेरी निम्नलिखित स्थिति थी

git symbolic-ref HEAD के साथ विफल रहता है fatal: ref HEAD is not a symbolic ref

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

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

git symbolic-ref HEAD refs/heads/master

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

— वरुण गर्ग
स्रोत

1

धन्यवाद! मेरा सिर अलग हो गया था। मैं इसे मास्टर तक पकड़ सकता था, लेकिन वे सिर्फ मास्टर की ओर इशारा करने के बजाय एक ही प्रतिबद्ध पर इंगित करने के लिए हुए थे जो कि इस ओर इशारा करता था। गुड टिप = डी

— रैगिंगरोज़वेल्ट

4

करने के बजाय git checkout origin/master

बस करो git checkout master

फिर git branchअपनी शाखा की पुष्टि करेगा।

— गोरन च।
स्रोत

4

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

git checkout master
git cherry-pick 99fe23ab

मेरी सोच चली गई: मैं एक अलग सिर पर हूं, लेकिन मैं मास्टर बनना चाहता हूं। मेरी अलग अवस्था को मान लेना गुरु से बहुत अलग नहीं है, अगर मैं अपनी प्रतिबद्धता को गुरु पर लागू कर सकता हूं, तो मैं सेट हो जाऊंगा। ठीक यही चेरी-पिक करती है।

— Prewett
स्रोत

3

यदि आपने मास्टर के ऊपर कुछ काम किया है और बस masterवहाँ "बैकवर्ड मर्ज" करना चाहते हैं (यानी आप जिस ओर masterइशारा करना चाहते हैं HEAD), वह वन-लाइनर होगा:

git checkout -B master HEAD

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

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

— quazgar
स्रोत

3

मुझे भी यही समस्या थी और मैंने निम्न चरणों से गुजरकर इसे हल किया है।

अगर आपको अपने बदलाव रखने की जरूरत है

पहले आपको git checkout masterआपको मास्टर शाखा में वापस लाने के लिए कमांड चलाने की आवश्यकता है ।
अगर आपको अपने बदलावों को बस चलाने की जरूरत है git checkout -b changesऔर git checkout -B master changes

यदि आपको अपने परिवर्तनों की आवश्यकता नहीं है

अपनी शाखा चलाने से सभी अनट्रैक की गई फ़ाइलों को हटाने के लिए git clean -df।
तब आपको अपने रिपॉजिटरी के भीतर सभी अस्थिर परिवर्तनों को साफ़ करना होगा। ऐसा करने के लिए आपको दौड़ना होगाgit checkout --
अंत में आपको git checkout masterकमांड का उपयोग करके अपनी शाखा को मास्टर शाखा में वापस लाना होगा।

— अरविंदा मेवालालचची
स्रोत

3

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

तो मैंने किया:

git branch -d branchname

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

git checkout branchname

— क्लाउस
स्रोत

1

जब मैं व्यक्तिगत रूप से खुद को ऐसी स्थिति में पाता हूं, जब यह पता चलता है कि मैंने कुछ बदलाव किए हैं, जबकि मैं अंदर नहीं हूं 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

— बेन उस्मान
स्रोत

1

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

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

अधिकांश मामलों में एक शाखा कई हिट का क्रम है जैसे:

प्रतिबद्ध 1: मास्टर -> ब्रांच_एचएडी (123be6a76168aca712aea16076e971c23835f8ca)

प्रतिबद्ध 2: मास्टर -> 123be6a76168aca712aea16076e971c23835f8ca -> Branch_HEAD (100644a76168aca712aea16076e971c23835f8ca)

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

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

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

— केशव
स्रोत

0

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

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

जिसे मैंने अंततः तय कर लिया

git push origin :HEAD

— KCD
स्रोत

0

यह मेरे लिए पूरी तरह से काम किया:

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

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

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

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

— jmojico
स्रोत

0

मेरे मामले में, मैं भागा git status, और मैंने देखा कि मेरी काम करने वाली डायरेक्टरी में कुछ अनट्रेक्टेड फाइलें थीं।

रिबास काम करने के लिए, मुझे बस उन्हें साफ करना था (क्योंकि मुझे उनकी आवश्यकता नहीं थी)।

— falsarella
स्रोत

0

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

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

इसके बाद आपको मूल-गुरु को पुन: संकलित करने में सक्षम होना चाहिए।

— जुन्चेन लियू
स्रोत

-1

मुझे भी यही समस्या थी। मैं अपने बदलावों को git stashकड़ी मेहनत करता हूं और स्थानीय रूप से शाखा को पिछली कमिटमेंट में रीसेट करता हूं (मुझे लगा कि इसका कारण है) तब ए git pullऔर मैंने अब उस सिर को अलग नहीं किया है। git stash applyफिर से अपने परिवर्तन करना न भूलें ।

— SAML
स्रोत

-2

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

— डेविड यांग
स्रोत