एक पुरानी प्रतिबद्धता की जाँच करना और मास्टर शाखा पर सिर बनाए रखना?


85

वर्तमान में एक और गिट कमिट (एक ही शाखा पर ... वास्तव में, मास्टर शाखा पर!) पर स्विच करने के लिए, मैं कमांड निष्पादित कर रहा हूं

git checkout ea3d5ed039edd6d4a07cc41bd09eb58edd1f2b3a

अब, हर बार जब मैं ऐसा करता हूं तो मुझे पता चलता है कि अब मैं एक अलग सिर के साथ हूं। मैं किसी बड़ी कमेटी में कैसे जाऊं और अभी भी उसी ब्रांच पर सिर रखूं?


1
उस आदेश को निष्पादित करने के बाद, आपका HEAD उस कमिट में परिवर्तन करता है । यह समझ में नहीं आता है कि HEAD भी कहीं और इशारा कर रहा है।
ग्रेग हेविगिल

मैं git के संदेश से जो समझता हूं, वह कहीं नहीं इंगित कर रहा है , जो अवांछनीय है।
व्यतीत हो चुके एलीसियम

1
संदेश Git शो जब आप किसी विशेष की जाँच के लिए प्रतिबद्ध है कि तरह कहते हैं, "सिर अब पर ea3d5ed है ..." है, जो आपको बताता है कि प्रमुख है कहीं ओर इशारा करते हुए। यह कहीं ओर इशारा कर रहा है जिसमें HEAD को छोड़कर कोई दूसरा नाम नहीं है (फिलहाल, एक git checkoutऔर प्रतिबद्ध या शाखा का नाम HEAD को उस नए स्थान पर ले जाएगा)।
ग्रेग हेविगिल

क्या दिए गए उत्तर पर्याप्त रूप से यह समझाते हैं, या क्या ऐसा कुछ है जिस पर हम अधिक स्पष्ट हो सकते हैं? अगर यह आपके प्रश्न का उत्तर नहीं देता है, तो मुझे आपके उत्तर को स्पष्ट करने में खुशी होगी।
ब्रायन कैंपबेल

यदि आप HEAD को पूरी तरह से अपरिवर्तित रखते हुए (किसी पुरानी कमेटी को वापस करने के लिए उदाहरण के लिए) रखते हुए किसी अन्य कमिटमेंट की जाँच करने का तरीका खोजने के लिए यहाँ आए थे: git revert --no-commit 0766c053..HEADतो यह वह करेगा, जहाँ 0766c053आप उस कमेटी की जाँच करना चाहते हैं। यह stackoverflow.com/a/21718540/525872 से है
जो लिस

जवाबों:


193

जब मैं ऐसा करता हूं तो ज्यादातर मैं एक अस्थायी शाखा में चेकआउट करता हूं:

git checkout -b temp-branch-name ea3d5ed039edd6d4a07cc41bd09eb58edd1f2b3a

फिर मैं कर रहा हूँ के बाद मैं बस शाखा को हटा दें


80

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

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

git checkout -b newbranch ea3d5ed

कल्पना करने में मदद करने के लिए, यहाँ कुछ आरेख हैं जो यह दर्शाते हैं कि अलग किए गए सिर पर काम करना किस तरह एक शाखा पर काम करने से अलग होता है।

चलो शुरू करते हैं 3 पर शुरू होता है master, ए, बी, और सी masterवर्तमान शाखा है, इसलिए HEADइंगित करता है master, जो सी को इंगित करता है।

एबीसी
* - * - * <- गुरु <- हेड

अब अगर हम प्रतिबद्ध होते हैं, तो git एक ऐसा कमेंट बनाएगा, जिसमें C एक अभिभावक के रूप में होगा (क्योंकि वह वर्तमान कमिट है, जिसके HEADमाध्यम से इंगित किया गया है master), और masterउस नई कमिट को इंगित करने के लिए अपडेट करेगा । हमारे सभी कमिट अब अंदर हैं master, और HEADनए कमिट के माध्यम से बताते हैं master

ऐ बी सी डी
* - * - * - * <- गुरु <- हेड

अब हम बी को चेक करते हैं, हमें एक अलग करते हैं HEAD

ऐ बी सी डी
* - * - * - * <- गुरु
   ^
    \-- सिर

यहाँ सब कुछ ठीक काम करता है; हम सभी फाइलों को देख सकते हैं, अपने कार्यक्रम का निर्माण कर सकते हैं, इसका परीक्षण कर सकते हैं, आदि। हम नए कमिट भी बना सकते हैं; लेकिन अगर हम ऐसा करते हैं, तो कोई भी शाखा नहीं है जिस पर हम चल रहे हैं, इसलिए हम उस नई प्रतिबद्ध पर किसी भी शाखा को इंगित नहीं कर सकते हैं। केवल इस ओर इशारा करते हैं HEAD:

ऐ बी सी डी
* - * - * - * <- गुरु
    \
     * <- हेड
     इ

अगर हम बाद में masterफिर से जांच करने का फैसला करते हैं, तो ई के लिए कुछ भी नहीं होगा।

ऐ बी सी डी
* - * - * - * <- गुरु <- हेड
    \
     *
     इ

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

इसलिए, एक नंगे संशोधन की जांच करने और एक अलग सिर पाने के बजाय, अगर आपको लगता है कि आप अधिक कमिट करने जा रहे हैं, तो आपको git checkout -b branch Bएक शाखा बनाने और इसे जांचने के लिए उपयोग करना चाहिए । अब आपके कमिट्स खो नहीं जाएंगे, क्योंकि उन्हें एक शाखा में शामिल किया जाएगा, जिसे आप आसानी से संदर्भित कर सकते हैं और बाद में विलय कर सकते हैं।

ऐ बी सी डी
* - * - * - * <- गुरु
   ^
    \ - शाखा <- हेड

यदि आप ऐसा करना भूल जाते हैं, और एक शाखा बंद कर देते हैं, तो चिंता करने की कोई आवश्यकता नहीं है। आप हेड रिवीजन के साथ एक शाखा बना सकते हैं git checkout -b branch। यदि आप पहले से ही masterशाखा में वापस आ गए हैं , और महसूस करते हैं कि आप एक भटका प्रतिबद्ध भूल गए हैं, तो आप इसका उपयोग करके पा सकते हैं git reflog, जो आपको दिखाएगा HEADकि पिछले कुछ दिनों में क्या कमिट का संकेत दिया गया है। कुछ भी जो अभी भी रिफ्लॉग में है, कचरा एकत्र नहीं किया जाएगा, और आम तौर पर संदर्भ को कम से कम 30 दिनों के लिए रिफ्लॉग में रखा जाता है।


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

5
@devoured एलीसियम "अलग सिर" का मतलब है कि आपके पास एक HEADरेफरी है जो एक कमेटी के SHA-1 पर सीधे इशारा कर रहा है, बजाय एक शाखा पर इंगित करने के जो एक कमिट में इंगित करता है। चूँकि आपका सिर एक शाखा का संदर्भ नहीं देता है, Git को यह पता नहीं होता है कि जब आप नए कमिट जोड़ते हैं तो किस शाखा को अद्यतन करना है। जैसा कि मैंने अपने उत्तर की शुरुआत में समझाया था, यदि आप कोड बनाने या परीक्षण करने के लिए पुराने संस्करण में वापस जा रहे हैं, तो एक अलग सिर रखना पूरी तरह से ठीक है; आप हमेशा एक शाखा के साथ git checkout masterया इस तरह वापस आ सकते हैं। यदि आप एक अलग सिर रखते हैं तो यह केवल एक समस्या है।
ब्रायन कैंपबेल

@ ब्रायनकैंपबेल - शाखा पर कमिट करने के बाद (जहां आपका सिर वर्तमान में है), क्या आप तब शाखा को बी में विलय करते हैं और बी को मास्टर में विलय करते हैं। आपको आगे क्या करना चाहिए?
amey1908

आपके स्पष्टीकरण ने मेरे लिए अन्य चीजों का एक गुच्छा 'क्लिक' कर दिया। धन्यवाद। मैं अब अंत में समझ गया होगा ...
जो

8

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

git co <previous-commit-id>

आप इस आदेश के बाद "(कोई शाखा नहीं)" नामक शाखा पर होंगे।

इसके द्वारा पुष्टि करें

git br

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

git co <the-branch-you-were-on>

"(कोई शाखा नहीं)" स्वचालित रूप से हटा दिया जाएगा। इस तरह आपको एक अस्थायी शाखा बनाने की आवश्यकता नहीं है।


5

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

यही संक्षिप्त व्याख्या है। नीचे दिए गए क्रियात्मकता को समझने में मदद मिलेगी कि कैसे हेड और मास्टर अलग हैं:

आम तौर पर, चीजें इस तरह दिखती हैं:

C ← refs/heads/master ← HEAD 
↓
B
↓
A

यह कहना है: "C का जनक B है, और B का माता-पिता A है। शाखा गुरु C की ओर संकेत कर रहा है, और मैंने वर्तमान में मास्टर की सामग्री की जाँच की है। इसके अलावा, जब मैं प्रतिबद्ध होता हूं, तो मास्टर को अपडेट किया जाएगा। "

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

इस प्रकार, यदि आप एक पुरानी प्रतिबद्धता की जांच करना चाहते हैं, तो HEAD को वांछित प्रतिबद्ध को इंगित करने के लिए अद्यतन किया जाना चाहिए। git-checkoutबस यही करता है:

C ← refs/heads/master 
↓
B ← HEAD
↓
A

अब, आप अपनी शाखा को आपके पीछे छोड़ गए हैं, क्योंकि आप कुछ पुराना देख रहे हैं। यह पूरी तरह से ठीक है, जैसा कि "अलग सिर" सलाह आपको शांति से बताती है (जोर मेरा):

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

दूसरी तरफ, अपनी शाखा को रीसेट करते समय भी HEAD हो जाता है जहाँ इसकी आवश्यकता होती है, इसका बहुत अलग प्रभाव होगा!

C
↓
B ← refs/heads/master ← HEAD
↓
A

प्रतिबद्ध सी कचरा बन जाएगा, क्योंकि आपने घोषणा की है कि आप इसके लिए मास्टर शाखा का हिस्सा बनने की इच्छा नहीं रखते हैं।

संक्षेप में, आपको बस यह समझना है कि "हेड" का अर्थ क्या है - यह वह जगह है जहां आप हैं, न कि जहां कोई दी गई शाखा है। और यदि आप जहां हैं, जहां नहीं है, जहां एक शाखा है, वहां एक अलग जगह का उपयोग करने के अलावा कोई विकल्प नहीं है।

(शायद कमिट हिस्ट्री को ब्राउज़ करने के लिए GitHub, gitk, या gitweb में भी देखें, अगर आपके HEAD को पटरी से उतारना आपको परेशान करता है।)


1

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

git checkout [commit|branch] -- .

आप परिवर्तनों को चरणबद्ध कर सकते हैं और यदि आप चाहें तो एक नई प्रतिबद्धता बना सकते हैं। यह कभी-कभी बहुत उपयोगी होता है।


0

मुझे लगता है कि मैं आपके सवालों को समझता हूं। यहाँ मैं इसे हल करने के लिए क्या पाया है। और इसका कोई GUI समाधान नहीं है, आप इसे हल करने के लिए केवल कमांड का उपयोग कर सकते हैं, और यह वास्तव में सरल है।

चरण 1: पुरानी कमिट का एक टैग बनाएं, जिसे आप वापस जाना चाहते हैं।

जैसे टैग v2.0

चरण 2: गिट चेकआउट v2.0

यहाँ यह है, अब आपका HEAD 'v2.0' कमिट की ओर इशारा कर रहा है, लेकिन मास्टर अभी भी आखिरी कमिट पर इशारा कर रहा है।

C:\Program Files\Git\doc\git\html\git-checkout.html यह दस्तावेज़ आपकी मदद कर सकता है

या git सहायता <चेकआउट> टाइप करें

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.