आकस्मिक चेकआउट के बाद परिवर्तन वापस प्राप्त करें?

Question

निम्नलिखित मेरे रेपो की स्थिति थी।

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst 
# On branch design 
# Changed but not updated: 
# (use "git add/rm <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: _layouts/default.html 
# deleted: _site/blog/2010/04/07/welcome-to-niraj-blog/index.html 
# deleted: _site/blog/2010/04/08/the-code-syntax-highlight/index.html 
# deleted: _site/blog/2010/05/01/showing-demo-to-kalyan/index.html 
# deleted: _site/config.ru 
# deleted: _site/index.html 
# deleted: _site/static/css/style.css 
# deleted: _site/static/css/syntax.css 
# modified: static/css/style.css 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

Accedently, मैं git checkout -f किया था और अब परिवर्तन चले गए हैं जो मुझे क्या करना चाहिए एकदम चमक।

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f 
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst 
# On branch design 
nothing to commit (working directory clean) 
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ 

क्या मैं वापस बदलाव वापस कर सकता हूं?

Answer 1

मुझे नहीं लगता कि आप उन निजी डेटा को पुनर्प्राप्त कर सकते हैं ("निजी" जैसे "इंडेक्स में नहीं जोड़ा गया है, न ही प्रतिबद्ध है", गिट के लिए अज्ञात है), जब तक कि आपके वर्तमान काम के लिए अन्य बैकअप प्रक्रिया न हो निर्देशिका।

भले ही इस Git Aliases page में प्रस्तावित नहीं है, मैं चेकआउट के लिए किसी तरह का अन्य नाम के लिए तर्क है (वहाँ की तरह alias rm /bin/rm -i उपयोग):

[alias] 
co = !sh -c 'git stash; git stash apply; git checkout "$*"' 

, 'git stash; git stash apply' के साथ जा रहा है " चेकपॉइंट तकनीक " द्वारा his answer में उपयोग किया जाता है।

यह समस्या मुझे ycombinator (अर्क) पर इस व्यवहार पर एक बहस की याद दिलाता है:

---

मैं Git के साथ डेटा के बहुत खो दिया है।
इसमें से अधिकांश को निर्दोष ध्वनि वाले आदेशों के साथ करना है जो डेटा हटाते समय पुष्टि के लिए नहीं पूछते हैं।
उदाहरण के लिए, git checkout filenamesvn revert filename के बराबर है।
बेशक git checkout branchname कुछ पूरी तरह से अलग करता है।
यदि कोई शाखा और फ़ाइल एक ही नाम साझा करती है, तो गिट शाखाओं को स्विच करने के लिए डिफ़ॉल्ट होगा, लेकिन यह दिन को बर्बाद करने से स्वत: पूर्ण नहीं रोकता है।

यहां एक पागल विचार है: यदि आपके पास निर्दोष कार्रवाई और खतरनाक कार्रवाई है, तो उन्हें एक ही आदेश के साथ लेबल न करें।

---

कष्टप्रद, हो सकता है, लेकिन यह उपयोगकर्ता त्रुटि है, तो त्रुटि डिजाइन नहीं। गिट के साथ, अगर मैं अपनी कामकाजी प्रतिलिपि को निर्बाध रूप से त्यागना चाहता हूं, तो मैं बस "git stash" कर सकता हूं।
आपके तर्क से, "आरएम" त्रुटिपूर्ण है क्योंकि यह -i के बजाय -f पास करते समय पुष्टि के लिए नहीं पूछता है। अच्छी तरह से हाँ। माफ़ कीजिये।यदि rm somenameapt-get update के बराबर था, और rm othernamerm -fr othername था

---

आपका सादृश्य ज्यादा सही होगा।
फिर भी, यह सही है कि "get checkout foo" ये दोनों बिल्कुल अलग चीजों में से एक है या नहीं, वहाँ एक फ़ाइल वर्तमान निर्देशिका

---

यहाँ में foo कहा जाता है के आधार पर एक और पागल है नहीं हो सकता है विचार: गंदे काम के पेड़ पर 'git checkout ...' चलाएं नहीं। समस्या सुलझ गयी।
एक और: फ़ाइल नामों को शाखा-नामों के रूप में पुन: उपयोग न करें।
ईमानदारी से कहूं तो मैं 'rm' के लापरवाह आमंत्रण के साथ एक ही समस्या को बर्बाद कर मेरा दिन है, लेकिन जब मैं शाप बड़बड़ाहट कर रहा हूँ यह मेरी lazyness/मूर्खता पर है और पार्टी पूर्ण करने पर नहीं या 'rm'

के व्यवहार

Answer 2

जब तक आपने कभी भी उन फ़ाइलों के साथ git add या git stash का उपयोग नहीं किया है, तो दुर्भाग्य से नहीं। यदि आपने उन्हें जोड़ा या रखा है, तो आप git reflog के माध्यम से अपने हैंश ढूंढ सकते हैं।

मैं git checkout के इस विनाशकारी व्यवहार से कभी भी सहज नहीं रहा हूं। शायद आपके काम को ओवरराइट करने से पहले git checkout इस तरह के एक उपयोगी वृद्धि के लिए स्वचालित रूप से एक स्टैश (ताकि फ़ाइलों को रिफ्लॉग के माध्यम से पकड़ा जा सके) बनाना होगा।

Answer 3

एक और चीज जिसे आप देख सकते हैं वह आपके आईडीई के माध्यम से है। मैंने गलती से 2 फाइलों की जांच की और मेरे आईडीई (नेटबीन) के 'स्थानीय इतिहास' के माध्यम से परिवर्तन वापस लाने में सक्षम था। क्या आशीर्वाद है!

Answer 4

यदि आप लिनक्स पर विम का उपयोग कर रहे हैं तो निम्नलिखित लागू हो सकते हैं।

• फ़ाइलें एक सक्रिय बफर में खुले हैं तो आप जब तक आप vim में फ़ाइल पुनः लोड नहीं है, और यह सहेज कर बहाल कर सकते हैं फ़ाइल सामग्री मिल गया है। ।

• यदि फ़ाइलें सक्रिय बफर में खुली नहीं हैं, लेकिन गंदे हैं, तो स्रोत निर्देशिका में एक .swp फ़ाइल होनी चाहिए जिसमें vim -r file.swp के माध्यम से पुनर्प्राप्त करने योग्य सामग्री की एक प्रति भी होनी चाहिए।

• यदि फ़ाइलें एंटीव बफर में न तो खुली हैं और न ही गंदे हैं, और यदि आपकी कार्यशील प्रति ext3 या ext4 विभाजन पर है, तो extundelete हाल ही में हटाए गए .swp फ़ाइलों और/या पुराने संस्करण को ढूंढने में सक्षम हो सकता है स्रोत फाइलें विभाजन को केवल पढ़ने के लिए याद रखें, उदा। mount -o remount,ro /mnt/point, और

  extundelete --recover-directory /path/to/working/copy /dev/sdaX 
  

  चलाने विभाजन कि काम कर रहे प्रतिलिपि शामिल जड़ विभाजन है, तो इसे पुन: माउंट करने के लिए है, तो सभी सेवाओं की हत्या की कोशिश, और अभी भी कोई जाने, फिर बंद और बूट एक लाइव सीडी का उपयोग कर यदि मना कर सकते हैं/यूएसबी/पीएक्सई, GRML की तरह, और ऊपर चलाएं। मैं इस तरह से तीन खोए गए फाइलों में से एक को पुनर्प्राप्त करने में सफल रहा था।

Answer 5

अगर आप आईडीई और EGit रूप ग्रहण का उपयोग करें, आप टीम-मेनू अपनी फ़ाइल पर है:

1. सही भीतर
2. सूची आइटम "टीम की ओर से अपनी फ़ाइल पर क्लिक करें "->" स्थानीय इतिहास दिखाएं "

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

Answer 6

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