रीफ्लॉग के साथ खोई हुई कमिट ढूंढें

• इस रिपॉजिटरी के रिकॉर्ड के रूप में रीफ्लॉग पढ़ें कि HEAD और शाखाएं कहां हैं।
• किसी उम्मीदवार की प्रतिबद्धता को बचाने से पहले उसकी सामग्री की जाँच करें।
• बिना जाँचे मापी गई कमिट पर एक शाखा बनाएँ।
• कहें कि रीफ्लॉग क्या वापस नहीं ला सकता: अप्रतिबद्ध कार्य और समाप्त प्रविष्टियाँ।

आप पाठ 18 के परिणाम एम से एक शाखा, private/lost-signup पर हैं। आपने एक नोट लिखा है, "दस्तावेज़: साइनअप पुनर्प्राप्ति नोट रखें", जिसमें docs/signup-recovery.md जोड़ा गया, और फिर एक हार्ड रीसेट एक कमिट वापस चलाया गया। नोट शाखा से, ग्राफ़ से और आपकी फ़ाइलों से चला गया है। आपके पास अभी तक कोई बचाव शाखा नहीं है, और आपने और कुछ नहीं बदला है।

Everything is local and on the Free plan (GitTree asks you to sign in): no hosting account, no provider, no internet. Every identity is fictional (example.com). Never run this lesson in a real project. The hard reset in the preparation is a rehearsal in a disposable copy.

परिवर्तन GitTree या मूल Git कमांड के साथ करें, दोनों एक ही प्रतिलिपि में नहीं। परिणाम पढ़ना हमेशा सुरक्षित होता है. मेनू लेबल 2.0 के स्वयं के स्ट्रिंग्स से आते हैं और मूल कमांड डिस्पोजेबल प्रतियों में Git 2.43 के साथ चलाए गए थे। GitTree चरण macOS, Windows या Linux पर नहीं चलाए गए।

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

HEAD@{1} जैसे चयनकर्ता अब से प्रविष्टियों की गिनती करते हैं, इसलिए वे प्रत्येक बाद के ऑपरेशन के साथ बदलते हैं। इसका उपयोग करने से पहले उम्मीदवार की कार्रवाई, समय, आईडी और फ़ाइल पढ़ें। किसी ऑफसेट को रेसिपी के रूप में याद न रखें।

रीफ्लॉग उन कमिटों को ढूंढता है जो सहेजे गए थे। इसे ऐसा कोई संपादन नहीं मिल सकता जो कभी प्रतिबद्ध न हो, जैसा कि पाठ 27 में दिखाया गया है। प्रविष्टियाँ समाप्त हो जाती हैं: डिफ़ॉल्ट रूप से Git उन प्रतिबद्धताओं के लिए प्रविष्टियाँ रखता है जिन तक कोई भी शाखा लगभग तीस दिनों तक नहीं पहुँचती है, और एक रिपॉजिटरी इसे बदल सकती है। ठीक होने के दौरान क्लीनअप या एक्सपायरी कमांड न चलाएं।

कमिट में एक शाखा बनाने से एक रेफरी जुड़ जाता है और कुछ नहीं। वर्तमान शाखा, अनुक्रमणिका और आपकी फ़ाइलें वहीं रहती हैं जहाँ वे हैं।

पाठ 18 के परिणाम एम की एक अलग सामान्य प्रति से प्रारंभ करें और अपनी मूल प्रति को अछूता छोड़ दें। शाखा बनाएं, DOC_LOST सहेजें, इसे कमिट करें और एक कमिट को हार्ड-रीसेट करें। यह विनाशकारी तैयारी केवल डिस्पोजेबल कॉपी के लिए है।

केवल नीचे नामित चरण पर ही सहेजें। ये अंतिम नई लाइन के साथ पूर्ण UTF-8/LF निकाय हैं; कभी भी मार्कडाउन बाड़ चिपकाएँ नहीं। अपरिवर्तित चलने योग्य फ़ाइलें नामित इनपुट प्राप्त करती हैं। अलग-अलग संस्करणों में मूल को अधिलेखित नहीं किया जाना चाहिए।

डॉक्स/साइनअप-रिकवरी.एमडी - DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

पैलेट को Command+Shift+P (Ctrl+Shift+P पर Ubuntu) से खोलें।

1. जैसा कि अगले भाग में दिखाया गया है, रिहर्सल बनाएं और खोई हुई प्रतिबद्धता के विषय को नोट करें।
2. पैलेट खोलें और View Reflog… चलाएँ। संवाद "रीफ्लॉग" Reflog of को HEAD पर सेट करके खुलता है; प्रविष्टियाँ सबसे पहले नवीनतम सूचीबद्ध की जाती हैं।
3. शीर्ष प्रविष्टियाँ पढ़ें. नवीनतम कहता है "रीसेट करें" और उसके नीचे वाला कहता है "प्रतिबद्ध करें" विषय के साथ "दस्तावेज़: साइनअप पुनर्प्राप्ति नोट रखें"। यदि सूची लंबी है तो Show Older Entries का प्रयोग करें। यह मत मानिए कि दूसरी पंक्ति हमेशा सही होती है।
4. प्रतिबद्ध प्रविष्टि का चयन करें. संवाद Show in Graph और New branch name दिखाता है। Show in Graph केवल एक कमिट डाल सकता है जिस तक एक शाखा पहुंचती है, इसलिए इस खोई हुई कमिट के लिए यह संवाद बंद कर देता है और ग्राफ़ एम पर रहता है: अगले चरण के लिए रीफ्लॉग को फिर से खोलें। आप कमिट की फ़ाइल को पुनर्स्थापित करने के बाद उसे पढ़ते हैं।
5. संवाद में वापस, उसी प्रविष्टि का चयन करें, New branch name में rescue/signup टाइप करें और Restore as Branch चुनें। नोटिस में कहा गया है, "शाखा बचाव/साइनअप बनाया गया। पूर्ववत करें इसे फिर से हटा दें।"
6. परिणाम की जाँच करें: खोई हुई प्रतिबद्धता पर rescue/signup अंक, वर्तमान शाखा अभी भी एम पर private/lost-signup है, और आपकी फ़ाइलें अपरिवर्तित हैं। पुनर्स्थापित कमिट का चयन करें और उसकी फ़ाइल खोलें docs/signup-recovery.md: यह DOC_LOST है।
7. बचाव शाखा को यथास्थान छोड़ दें। ग्राफ़ को साफ़ करने के लिए कोई क्लीनअप न चलाएँ।

पाठ्यक्रम में प्रत्येक सामान्य प्रतिबद्धता के लिए: Summary बताया गया विषय है, Description खाली है और विकल्प Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit और Allow Empty Commit बंद रहते हैं।

केवल पाठ 18 के परिणाम की एक अलग, साफ़ प्रति में:

git switch --create private/lost-signup

DOC_LOST को docs/signup-recovery.md के रूप में सहेजें, फिर:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

उम्मीदवारों को उनकी आईडी के साथ सूचीबद्ध करें और जो आपको लगता है कि खो गया है उसकी जांच करें:

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

"प्रतिबद्ध: दस्तावेज़: साइनअप पुनर्प्राप्ति नोट रखें" पंक्ति पर आईडी के साथ <lost-sha> बदलें। इस तत्काल उदाहरण में HEAD@{1} वही प्रतिबद्धता है, लेकिन ऑफसेट कोई नियम नहीं है। इसकी जांच किए बिना बचाव शाखा बनाएं:

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

फ़ाइल DOC_LOST है, मुद्रित शाखा private/lost-signup है और स्थिति रिक्त है। आपकी फ़ाइलें नोट नहीं दिखाती हैं, क्योंकि HEAD एम पर रुका हुआ है। कोई समाप्ति या सफाई आदेश इसका हिस्सा नहीं है।

खोई हुई प्रतिबद्धता पर Where you end: rescue/signup अंक हैं और इसकी फ़ाइल DOC_LOST है। वर्तमान शाखा, अनुक्रमणिका और आपकी फ़ाइलें बिल्कुल वैसी ही हैं जैसी वे रीसेट के बाद थीं, और कुछ भी पुश नहीं किया गया था।

• प्रविष्टि को पढ़ने के बजाय एक निश्चित नुस्खा के रूप में HEAD@{1} का उपयोग करना।
• किसी शाखा को सहेजने से पहले दोबारा रीसेट करना या जाँच करना, जो अधिक प्रविष्टियाँ जोड़ता है और जो आप चाहते हैं उसे दबा देता है।
• रीफ्लॉग में ऐसे संपादन की अपेक्षा करना जो कभी प्रतिबद्ध नहीं था।
• किसी चीज़ की तलाश करते समय क्लीनअप कमांड चलाना।

यदि कमिट सूची में नहीं है, तो हो सकता है कि आप गलत रेफरी देख रहे हों: HEAD और शाखा के बीच Reflog of स्विच करें, और Show Older Entries का उपयोग करें। यदि यह वास्तव में चला गया है, तो यह समाप्त हो गया है या कभी प्रतिबद्ध नहीं था। ऐप में, Restore as Branch के बाद नोटिस में कहा गया है कि पूर्ववत करें शाखा को फिर से हटा देता है।

प्रत्येक प्रश्न का उत्तर दें, फिर क्यों पढ़ें। "आवश्यक" चिह्नित प्रश्न पाठ को पूरा करने में गिने जाते हैं।

1. प्रश्न 1 में से 6

   प्रश्न 1 में से 6

   रिफ्लॉग क्या है?

   एक उत्तर चुनें.

   एक साझा लॉग जिसे प्रत्येक क्लोन और सर्वर चरणबद्ध तरीके से रखते हैं।

   आपकी फ़ाइलों का बैकअप.

   HEAD और प्रत्येक शाखा ने कहाँ इंगित किया है इसका एक स्थानीय रिकॉर्ड।

   कमिट ग्राफ़ जैसी ही चीज़।

   उत्तर जांचें
2. प्रश्न 2 में से 6

   प्रश्न 2 में से 6

   इनमें से कौन सा रीफ्लॉग के बारे में सत्य है?

   लागू होने वाला प्रत्येक उत्तर चुनें.

   यह उन संपादनों को संग्रहीत करता है जिन्हें आपने कभी प्रतिबद्ध नहीं किया।

   HEAD और प्रत्येक शाखा का अपना है।

   पुरानी प्रविष्टियाँ समाप्त हो रही हैं.

   प्रोजेक्ट के किसी अन्य क्लोन में आपकी प्रविष्टियाँ नहीं हैं।

   उत्तर जांचें
3. प्रश्न 3 में से 6

   प्रश्न 3 में से 6आवश्यक

   आपने रिफ्लॉग में खोई हुई कमिट पाई और rescue/signup नाम के साथ रीस्टोर को ब्रांच के रूप में इस्तेमाल किया। आप क्या देखते हैं?

   एक उत्तर चुनें.

   खोई हुई प्रतिबद्धता पर rescue/signup अंक हैं, और आप अभी भी अपनी फ़ाइलों के अपरिवर्तित होने के साथ एम पर private/lost-signup पर हैं।

   अब आप rescue/signup पर हैं और नोट आपकी फ़ाइलों में वापस आ गया है।

   private/lost-signup खोई हुई प्रतिबद्धता की ओर आगे बढ़ता है।

   रीफ्लॉग प्रविष्टि हटा दी गई है.

   उत्तर जांचें
4. प्रश्न 4 में से 6

   प्रश्न 4 में से 6

   इनपुट बदलें: आपने नोट कभी प्रतिबद्ध नहीं किया, और फिर आपने हार्ड रीसेट चलाया। क्या रीफ्लॉग इसे वापस ला सकता है?

   एक उत्तर चुनें.

   हाँ, पुरानी प्रविष्टियाँ दिखाएँ के माध्यम से।

   हाँ, HEAD@{1} के साथ।

   नहीं, रीफ्लॉग कमिट पर इंगित करता है, और यह सामग्री कभी भी एक में नहीं थी।

   हां, रीफ्लॉग को शाखा में स्विच करके।

   उत्तर जांचें
5. प्रश्न 5 में से 6

   प्रश्न 5 में से 6आवश्यक

   आपने कुछ और ऑपरेशन किए, फिर git branch rescue HEAD@{1} चलाया, और फ़ाइल वह नहीं है जो आप चाहते थे। क्या हुआ?

   एक उत्तर चुनें.

   रीसेट के बाद HEAD@{1} हमेशा सही कमिट होता है।

   रीफ्लॉग भ्रष्ट है.

   खोई हुई प्रतिबद्धता को नई शाखा द्वारा हटा दिया गया था।

   HEAD@{1} अब से गिनती करता है, इसलिए प्रत्येक नया ऑपरेशन उसका नाम बदल देता है। सूची पढ़ें और खोई हुई कमिट की आईडी का उपयोग करें।

   उत्तर जांचें
6. प्रश्न 6 में से 6

   प्रश्न 6 में से 6आवश्यक

   आपके द्वारा बचाव शाखा बनाने के बाद, कौन से रीडबैक से पता चलता है कि यह पाठ में बताए अनुसार काम करता है?

   लागू होने वाला प्रत्येक उत्तर चुनें.

   docs/signup-recovery.md अब आपकी फ़ाइलों में मौजूद है।

   git show rescue/signup:docs/signup-recovery.md "# पुनर्प्राप्त साइनअप कार्य" से प्रारंभ करते हुए, पुनर्प्राप्त नोट को प्रिंट करता है।

   git status --short कुछ भी प्रिंट नहीं करता.

   git symbolic-ref --short HEAD प्रिंट private/lost-signup करता है।

   उत्तर जांचें

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

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

• रीसेट: नरम, मिश्रित और कठोर (पाठ 27)
• बिना सिर हिलाए इतिहास पढ़ें (पाठ 8)
• डाउनलोड करें GitTree

रीफ्लॉग - سجل المراجع; बचाव शाखा - فرع حفظ; चयनकर्ता - محدِّد.