গৃহীত উত্তরের সাথে একটি অতিরিক্ত যোগ করুন, যদি আপনার ভুলভাবে যুক্ত হওয়া ফাইলটি বিশাল ছিল তবে আপনি সম্ভবত লক্ষ্য করবেন যে, ' git reset' এর সাহায্যে সূচক থেকে অপসারণ করার পরেও এটি .gitডিরেক্টরিতে স্থান দখল করে আছে বলে মনে হচ্ছে ।
এটি নিয়ে উদ্বিগ্ন হওয়ার কিছু নেই; ফাইলটি প্রকৃতপক্ষে সংগ্রহস্থলের মধ্যে রয়েছে তবে কেবল একটি "লুজ অবজেক্ট" হিসাবে রয়েছে। এটি অন্য সংগ্রহস্থলগুলিতে অনুলিপি করা হবে না (ক্লোন, ধাক্কা দিয়ে) এবং স্থানটি শেষ পর্যন্ত পুনরায় দাবি করা হবে - যদিও খুব শীঘ্রই নয়। আপনি যদি উদ্বিগ্ন হন তবে আপনি চালাতে পারেন:
git gc --prune=now
আপডেট (এরপরে যা কিছু উত্সাহিত উত্তর থেকে উদ্ভূত হতে পারে এমন কিছু বিভ্রান্তি পরিষ্কার করার আমার প্রচেষ্টা):
সুতরাং, যা বাস্তব হয় পূর্বাবস্থা এর git add?
git reset HEAD <file> ?
অথবা
git rm --cached <file>?
কড়া কথা বলতে, এবং যদি আমি ভুল না হয়: কিছুই না ।
git add পূর্বাবস্থায় ফেরানো যাবে না - নিরাপদে, সাধারণভাবে।
আসুন প্রথমে স্মরণ করি আসুন git add <file>আসলে কী করে:
যদি <file>হয় পূর্বে ট্র্যাক করা হয়নি , git add ক্যাশে সেটিকে যোগ করে , তার বর্তমান কন্টেন্ট সঙ্গে।
যদি <file>হয় ইতিমধ্যে ট্র্যাক , git add বর্তমান সামগ্রী সংরক্ষণ ক্যাশে করার জন্য (স্ন্যাপশট, সংস্করণ)। গিট-এ, এই ক্রিয়াটিকে এখনও অ্যাড বলা হয় (কেবল এটি আপডেট নয়) কারণ কোনও ফাইলের দুটি পৃথক সংস্করণ (স্ন্যাপশট) দুটি পৃথক আইটেম হিসাবে বিবেচিত হয়: সুতরাং, আমরা প্রকৃতপক্ষে ক্যাশে একটি নতুন আইটেম যুক্ত করছি, শেষ পর্যন্ত পরে প্রতিশ্রুতিবদ্ধ।
এর আলোকে প্রশ্নটি কিছুটা অস্পষ্ট:
কমান্ডটি ব্যবহার করে আমি ভুল করে ফাইল যুক্ত করেছি ...
ওপি'র দৃশ্যমানটি প্রথমটি (চিহ্নবিহীন ফাইল) বলে মনে হচ্ছে, আমরা ট্র্যাকড আইটেমগুলি থেকে ফাইলটি (কেবলমাত্র বর্তমান সামগ্রীগুলি নয়) সরিয়ে ফেলার জন্য "পূর্বাবস্থায় ফিরে যেতে" চাই। যদি এটি হয় তবে চালানো ঠিক হবে git rm --cached <file>।
এবং আমরা চালাতে পারে git reset HEAD <file>। এটি সাধারণভাবে পছন্দনীয়, কারণ এটি উভয় পরিস্থিতিতেই কাজ করে: যখন আমরা ইতিমধ্যে ট্র্যাক করা আইটেমটির কোনও সংস্করণ ভুলভাবে সংযোজন করি তখন এটি পূর্বাবস্থায় ফিরে আসে।
তবে দুটি ক্যাভেট রয়েছে।
প্রথম: (উত্তরে বর্ণিত হিসাবে) কেবলমাত্র একটি দৃশ্য রয়েছে যা git reset HEADকাজ করে না, তবে git rm --cachedতা করে: একটি নতুন সংগ্রহশালা (কোনও অঙ্গীকার নেই)। কিন্তু, সত্যই, এটি একটি ব্যবহারিকভাবে অপ্রাসঙ্গিক কেস।
দ্বিতীয়: সচেতন হন যে git reset HEAD পূর্বে ক্যাশেড ফাইলের সামগ্রীগুলি যাদুকরীভাবে পুনরুদ্ধার করতে পারে না, এটি কেবল এটি হেড থেকে পুনরায় সংশ্লেষিত করে। যদি আমাদের বিভ্রান্ত হয়git add কোনও পূর্ববর্তী মঞ্চস্থ অননুমোদিত সংস্করণটি ওভাররোট করে, আমরা এটি পুনরুদ্ধার করতে পারি না। এই কারণেই, কঠোরভাবে বলতে গেলে, আমরা [*] কে পূর্বাবস্থায় ফিরিয়ে আনতে পারি না।
উদাহরণ:
$ git init
$ echo "version 1" > file.txt
$ git add file.txt # First add of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add file.txt # Stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt
$ git diff file.txt
-version 2
+version 3
$ git add file.txt # Oops we didn't mean this
$ git reset HEAD file.txt # Undo?
$ git diff --cached file.txt # No dif, of course. stage == HEAD
$ git diff file.txt # We have irrevocably lost "version 2"
-version 1
+version 3
অবশ্যই, এটি খুব সমালোচিত নয় যদি আমরা কেবলমাত্র 'নতুন' ফাইল (কেস 1) যুক্ত করার জন্য 'গিট অ্যাড' করার স্বাভাবিক অলস কর্মপ্রবাহটি অনুসরণ করি এবং আমরা কমিট, git commit -aকমান্ডের মাধ্যমে নতুন বিষয়বস্তু আপডেট করি ।
* (সম্পাদনা করুন: উপরেরটি ব্যবহারিকভাবে সঠিক, তবে এখনও পর্যায়ক্রমে পরিবর্তনগুলি পুনরুদ্ধার করার জন্য কিছুটা হ্যাকিশ / কনভোল্টেড উপায় থাকতে পারে তবে প্রতিশ্রুতিবদ্ধ নয় এবং তারপরে ওভাররাইট করা হয়েছে - জোহানেস ম্যাটোকিক এবং আইলসমিটের মন্তব্য দেখুন)
HEADবাheadএখন ব্যবহার করতে পারেন@স্থানেHEADপরিবর্তে। আপনি কেন এটি করতে পারেন তা জানতে এই উত্তরটি (শেষ বিভাগ) দেখুন ।