Menu
১০.৭ রক্ষনাবেক্ষণ ও তথ্যাদি পুনরুদ্ধার
রক্ষণাবেক্ষণ এবং ডেটা পুনরুদ্ধার:
মাঝে মাঝে, আপনাকে কিছু ক্লিনআপ করতে হতে পারে – একটি রিপোজিটরিকে আরো বেশি কম্প্যাক্ট করতে কিংবা হারানো ডাটা ফিরে পেতে ইম্পর্টেড রিপোজিটোরিকে ক্লিন-আপ করতে হতে পারে। নিচে এই দৃশ্যপট নিয়ে আলোচনা করা হবে।রক্ষণাবেক্ষণ:
মাঝে মাঝে, গিট স্বয়ংক্রিয়ভাবে “auto gc” কমান্ডটি রান করে। বেশিরভাগ সময় এই কমান্ডটি কিছুই করে না। যাইহোক, যদি অনেকগুলি লুজ অবজেক্ট (প্যাকফাইলে নয় এমন অবজেক্ট) বা অনেকগুলি প্যাকফাইল থাকে, তাহলে গিট একটি পূর্ণাঙ্গ গিট gc কমান্ড চালু করে । “gc” বলতে বোঝায় গারবেজ সংগ্রহের জন্য, এবং কমান্ডটি বেশ কিছু কাজ করে: এটি সমস্ত লুজ অবজেক্টকে একত্রিত করে এবং প্যাকফাইলে রাখে, এটি প্যাকফাইলগুলিকে একটি বড় প্যাকফাইলে একত্রিত করে, এবং এটি এমন অব্জেক্টগুলোকে সরিয়ে দেয় যেগুলি কোনও কমিট থেকে পৌঁছানো যায় না এবং কয়েক মাস পুরনো ।আপনি “auto gc” কমান্ডটি ম্যানুয়ালি চালাতে পারেন।
$ git gc --auto
আবার, সাধারণত এটি কোন কিছু করে না। Git একটি gc কমান্ড বাস্তবায়নের জন্য আপনাকে 7,000 টি সাধারণ অবজেক্ট বা 50 টির বেশি প্যাকফাইল থাকতে হবে। আপনি সেই সীমাগুলি সম্পাদনা করতে পারেন gc.auto এবং gc.autopacklimit config সেটিংস দিয়ে।
gc আরেকটি কাজ করে যেটি হল আপনার প্রতিটি রেফারেনসকে একটি ফাইলে প্যাক করবে। যদি আপনার রিপোজিটরিতে নিম্নলিখিত শাখা (branch) এবং ট্যাগ থাকে:
gc আরেকটি কাজ করে যেটি হল আপনার প্রতিটি রেফারেনসকে একটি ফাইলে প্যাক করবে। যদি আপনার রিপোজিটরিতে নিম্নলিখিত শাখা (branch) এবং ট্যাগ থাকে:
$ find .git/refs -type f
.git/refs/heads/experiment
.git/refs/heads/master
.git/refs/tags/v1.0
.git/refs/tags/v1.1
যদি আপনি git gc চালান, তবে আপনি আর এই ফাইলগুলিকে refs ডিরেক্টরিতে রাখবেন না। গিট তাদের কার্যকারিতার জন্য .git/packed-refs নামের একটি ফাইলে সরাবে, যা এইরকম দেখাবে।
$ cat .git/packed-refs
# pack-refs with: peeled fully-peeled
cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment
ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master
cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1
^1a410efbd13591db07496601ebc7a059dd55cfe9
যদি আপনি একটি রেফারেন্স আপডেট করেন, তবে Git এই ফাইলটি সম্পাদন করার পরিবর্তে নতুন একটি ফাইল refs/heads এ লেখে। একটি নির্দিষ্ট রেফারেন্সের জন্য উপযুক্ত SHA-1 পেতে, Git রেফারেন্স ডিরেক্টরি এ তার জন্য চেক করে এবং packed-refs ফাইল এর সাথে fallback করে। তাই আপনি refs রেফারেন্স ডিরেক্টরিতে পাবেন না, সেটি সম্ভবত আপনার packed-refs ফাইলে রয়েছে।
ফাইলের শেষ লাইন নোটিশ করুন, যা একটি ^ দিয়ে শুরু হয়। এর মানে উপরের ট্যাগ একটি এনোটেশনাল ট্যাগ এবং তার লাইনটি হল এনোটেশনাল ট্যাগের কমিট ।
ফাইলের শেষ লাইন নোটিশ করুন, যা একটি ^ দিয়ে শুরু হয়। এর মানে উপরের ট্যাগ একটি এনোটেশনাল ট্যাগ এবং তার লাইনটি হল এনোটেশনাল ট্যাগের কমিট ।
ডেটা পুনরুদ্ধার
আপনার গিট ব্যবহারের সময় ভুলক্রমে একটি কমিট হারিয়ে ফেলতে পারেন। সাধারণত, এটি তখনই ঘটে যখন আপনি কোনো একটা ব্রাঞ্চে কাজ করার সময় ভুলবশত সেটি ফোর্স ডিলিট করছেন কিংবা কোনো একটা ব্রাঞ্চ হার্ড রিসেট করছেন। ধরে নিলাম, এমন একটা পরিস্থিতিতে আপনি পড়ছেন, তাহলে আপনি কিভাবে আপনার কমিটগুলো ফিরিয়ে আনতে পারবেন?এখানে এক উদাহরণ দেওয়া হলোঃ ধরেন, আপনার টেস্ট রিপোজিটরির মাস্টার ব্রাঞ্চ হার্ড রিসেট করে ফেললেন, এখন আপনার হারানো কমিট রিকোভার করতে চাচ্ছেন। প্রথমে দেখে নিই যে, আপনার রিপোসিটরি এই মূহুর্তে কি অবস্থায় আছেঃ
$ git log --pretty=oneline
ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit
484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
এখন, মাস্টার ব্রাঞ্চকে মাঝের কমিটে নিয়ে যাইঃ
$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9
HEAD is now at 1a410ef Third commit
$ git log --pretty=oneline
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
আপনি এখন সবার উপরের দুইটা কমিট হারিয়ে ফেলছেন – আপনার এখন এমন কোনো ব্রাঞ্চ নেই যার মাধ্যমে আপনি আপনার হারানো কমিট গুলো ফিরে পেতে পারেন। আপনাকে সর্বশেষ কমিটের SHA-1 খুজে বের করতে হবে এবং তার সাথে একটা ব্রাঞ্চ যোগ করতে হবে। এমন না যে আপনি সর্বশেষ কমিটের SHA-1 বের করার ট্রিক টি মুখস্থ করে রাখছেন, তাইনা?
এক্ষেত্রে, দ্রুততম উপায় হলো git reflog নামক কমান্ড ব্যবহার করা। আপনি যখন কিছু পরিবর্তন করেন, গিট তখন আপনার প্রতিটা পরিবর্তনের HEAD রেকর্ড করে রাখে। প্রত্যেকবার আপনার কমিট কিংবা ব্রাঞ্চে কোনো পরিবর্তনের সাথে সাথে reflog আপডেট হবে। reflog আপডেট করার জন্য git update-ref কমান্ড ব্যবহার করা যায়,আপনার রেফ ফাইলস গুলোতে SHA-1 লেখার পরিবর্তে এইটা ব্যবহার করা যায় যেটা আমরা Git References চ্যাপ্টারে কাভার করছি। আপনার ব্রাঞ্চ কি অবস্থায় আছে তা সবসময় git reflog কমান্ডের মাধ্যমে দেখতে পারবেনঃ
এক্ষেত্রে, দ্রুততম উপায় হলো git reflog নামক কমান্ড ব্যবহার করা। আপনি যখন কিছু পরিবর্তন করেন, গিট তখন আপনার প্রতিটা পরিবর্তনের HEAD রেকর্ড করে রাখে। প্রত্যেকবার আপনার কমিট কিংবা ব্রাঞ্চে কোনো পরিবর্তনের সাথে সাথে reflog আপডেট হবে। reflog আপডেট করার জন্য git update-ref কমান্ড ব্যবহার করা যায়,আপনার রেফ ফাইলস গুলোতে SHA-1 লেখার পরিবর্তে এইটা ব্যবহার করা যায় যেটা আমরা Git References চ্যাপ্টারে কাভার করছি। আপনার ব্রাঞ্চ কি অবস্থায় আছে তা সবসময় git reflog কমান্ডের মাধ্যমে দেখতে পারবেনঃ
$ git reflog
1a410ef HEAD@{0}: reset: moving to 1a410ef
ab1afef HEAD@{1}: commit: Modify repo.rb a bit
484a592 HEAD@{2}: commit: Create repo.rb
এখানে আমরা দুইটা কমিট দেখতে পাচ্ছি যেগুলো আমরা চেক আউট করে ফেলছি, যদিও এখানে বেশি তথ্য নাই। বিস্তারিত তথ্য দেখতে পারলে সেটা আরো সুবিধা হতো এবং আমরা সেইটা git log -g কমান্ড ব্যবহার করতে পারি, যা নিচের আউটপুট দেখাবেঃ
$ git log -g
commit 1a410efbd13591db07496601ebc7a059dd55cfe9
Reflog: HEAD@{0} (Scott Chacon <schacon@gmail.com>)
Reflog message: updating HEAD
Author: Scott Chacon <schacon@gmail.com>
Date: Fri May 22 18:22:37 2009 -0700
Third commit
commit ab1afef80fac8e34258ff41fc1b867c702daa24b
Reflog: HEAD@{1} (Scott Chacon <schacon@gmail.com>)
Reflog message: updating HEAD
Author: Scott Chacon <schacon@gmail.com>
Date: Fri May 22 18:15:24 2009 -0700
Modify repo.rb a bit
এখানে দেখতে পাচ্ছি আপনি সবার নিচের কমিট টা হারিয়ে ফেলছে্ন, তাই এই কমিটের সাথে একটা নতুন ব্রাঞ্চ ক্রিয়েট করে আপনি রিকোভার করতে পারবেন। উদাহরণস্বরুপ, আপনি recover-branch নামের একটা ব্রাঞ্চ ক্রিয়েট করবেন এবং সেইটা (ab1afef) কমিটের সাথে যুক্তঃ
$ git branch recover-branch ab1afef
$ git log --pretty=oneline recover-branch
ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit
484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
ঠিক আছে- এখন আপনার কাছে recover-branch নামক একটা ব্রাঞ্চ আছে যাকে master ব্রাঞ্চ ব্যবহার করে প্রথমের দুইটা কমিট আবারো ফিরে পেতে পারে। এখন, ধরেন আপনার হারানো ডাটা কোনো কারণে reflog এ নেই । সেটা recover-branch নামক ব্রাঞ্চ এবং reflog ডিলিট করার মাধ্যমে সিমুলেট করতে পারবেন। এখন, প্রথমের দুইটা কমিটে কোনোভাবেই পোঁছানো সম্ভব না।
$ git branch -D recover-branch
$ rm -Rf .git/logs/
কারণ reflog ডাটা .git/logs/ ডিরেক্টরিতে সংরক্ষিত থাকে, তাই এখন আপনার কাছে কোনো reflog নাই। এখন, এখান থেকে কিভাবে আপনার কমিট রিকোভারি করা যাবে? git fsck কমান্ড ব্যবহার করার মাধ্যমে করা যাবে,যেটার দ্বারা ডাটাবেজ ইন্টিগ্রিটি চেক করে। যদি এই কমান্ডের সাথে –full অপশন যুক্ত করে রান করেন,তাহলে সেটা সেসব অব্জেক্ট গুলো প্রদর্শন করবে যা অন্য কোনো অব্জেক্টের সাথে যুক্ত নেইঃ
$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (18/18), done.
dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
dangling commit ab1afef80fac8e34258ff41fc1b867c702daa24b
dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
এই ক্ষেত্রে, আপনি আপনার হারানো কমিট দেখতে পাবেন “dangling commit” স্ট্রিং এর পর।আপনি এখন আলাদা একটা ব্রাঞ্চ SHA-1 এ যুক্ত করার মাধ্যমে এইটা একইভাবে রিকোভার করতে পারবেন।
অবজেক্ট অপসারণ
গিটের অনেক দুর্দান্ত জিনিস রয়েছে, কিন্তু একটি বৈশিষ্ট্য যা সমস্যার কারণ হতে পারে তা হল যে একটি git clone প্রতিটি ফাইলের প্রতিটি ভার্সন সহ প্রোজেক্টের সম্পূর্ণ হিস্ট্রি ডাউনলোড করে । পুরো জিনিসটি সোর্স কোড হলে এটি ঠিক আছে, কারণ সেই ডেটাকে দক্ষতার সাথে সংকুচিত করার জন্য গিটকে অত্যন্ত অপ্টিমাইজ করা হয়েছে। যাইহোক, যদি কেউ আপনার প্রোজেক্টের হিস্ট্রিতে যে কোনও সময়ে একটি বিশাল ফাইল যোগ করে, তবে সর্বকালের জন্য প্রতিটি ক্লোনে সেই বড় ফাইলটি ডাউনলোড করতে বাধ্য করা হবে, এমনকি যদি এটি পরবর্তী কমিটে প্রকল্প থেকে সরিয়েও ফেলা হয় । কারণ এটি গিট হিস্ট্রি থেকে পৌঁছানো যাবে, এটি সর্বদা সেখানেই থাকবে ।আপনি যখন সাবভার্সন বা পারফোর্স রিপোজিটরিগুলিকে গিটে রূপান্তর করছেন তখন এটি একটি বিশাল সমস্যা হতে পারে। যেহেতু আপনি ঐ সিস্টেমে পুরো হিস্ট্রি ডাউনলোড করেন না, এই ধরনের সংযোজন কিছু ফলাফল বহন করে। আপনি যদি অন্য সিস্টেম থেকে ইম্পর্ট করেন বা অন্যথায় খুঁজে পান যে আপনার রিপোজিটরিটি যা হওয়া উচিত ছিল তার চেয়ে অনেক বড়, এখানে আপনি কিভাবে বড় অবজেক্টটি খুঁজে পেতে এবং অপসারণ করতে পারেন ।
সতর্ক থাকুন: এই কৌশলটি আপনার কমিট হিস্ট্রির জন্য ধ্বংসাত্মক । একটি বড় ফাইলের রেফারেন্স মুছে ফেলার জন্য আপনাকে প্রথম ট্রি এবং তার পরবর্তী থেকে প্রতিটি কমিট অবজেক্টকে পুনর্লিখন করতে হবে । আপনি যদি ইম্পর্টের পরপরই এটি করেন, কেউ কমিটের কাজ শুরু করার আগে, আপনি ঠিক আছেন – অন্যথায়, আপনাকে সমস্ত কন্ট্রিবিউটরদের অবহিত করতে হবে যে তাদের অবশ্যই আপনার নতুন কমিটের ওপর ভিত্তি করে তাদের কাজ রিবেজ করতে হবে।
প্রদর্শন করার জন্যে, আপনি আপনার টেস্ট রিপোজিটরিটে একটি বড় ফাইল যুক্ত করবেন, পরবর্তী কমিটে এটি সরিয়ে ফেলবেন, এটি সন্ধান করুন, এবং রিপোজিটরি থেকে স্থায়ীভাবে অপসারণ করুন। প্রথমত, আপনার হিস্ট্রিতে একটি বড় অবজেক্ট যোগ করুনঃ
$ curl -L https://www.kernel.org/pub/software/scm/git/git-2.1.0.tar.gz > git.tgz
$ git add git.tgz
$ git commit -m 'Add git tarball'
[master 7b30847] Add git tarball
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 git.tgz
ওহো – আপনি আপনার প্রোজেক্টে একটি বিশাল টারবল যোগ করতে চাননি৷ এটা থেকে পরিত্রাণ পেতে:
$ git rm git.tgz
rm 'git.tgz'
$ git commit -m 'Oops - remove large tarball'
[master dadf725] Oops - remove large tarball
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 git.tgz
এখন, আপনার ডাটাবেসে gc ব্যাবহার করুন এবং দেখুন আপনি কত স্পেস ব্যবহার করছেনঃ
$ git gc
Counting objects: 17, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (17/17), done.
Total 17 (delta 1), reused 10 (delta 0)
আপনি কত স্পেস ব্যবহার করছেন তা দেখার জন্য count-objects কমান্ডটি দ্রুত চালানঃ
$ git count-objects -v
count: 7
size: 32
in-pack: 17
packs: 1
size-pack: 4868
prune-packable: 0
garbage: 0
size-garbage: 0
সাইজ-প্যাক এন্ট্রিটি হল কিলোবাইটে আপনার প্যাকফাইলের আকার, অর্থাৎ আপনি প্রায় 5MB ব্যবহার করছেন। শেষ কমিটের আগে, আপনি 2K এর কাছাকাছি ব্যবহার করেছিলেন – স্পষ্টতই, পূর্ববর্তী কমিট থেকে ফাইলটি মুছে ফেলার হলেও এটি আপনার হিস্ট্রি থেকে মুছে যায়নি। প্রতিবার যে কেউ এই রিপোজিটরি ক্লোন করবে, এই ছোট প্রোজেক্টটি পেতে তাদেরকে সমস্ত 5MB ক্লোন করতে হবে, কারণ আপনি দুর্ঘটনাক্রমে একটি বড় ফাইল যোগ করেছেন। এখন এর থেকে পরিত্রাণ পাওয়া যাক ।
প্রথমেই আপনাকে এটি খুঁজে বের করতে হবে। এই ক্ষেত্রে, আপনি ইতিমধ্যে এটি কি ফাইল জানেন । কিন্তু ধরুন আপনি জানেননা; আপনি কিভাবে সনাক্ত করবেন কোন ফাইল বা ফাইলগুলি এত স্পেস নিচ্ছে? আপনি যদি গিট gc চালান তবে সমস্ত অবজেক্টটি একটি প্যাকফাইলে থাকে; আপনি git verify-pack নামে আরেকটি প্লাম্বিং কমান্ড চালিয়ে এবং আউটপুটের তৃতীয় ফিল্ডে ফাইলের আকার সাজানোর মাধ্যমে বড় অবজেক্টগুলি সনাক্ত করতে পারেন । আপনি tail কমান্ড পাইপ করতে পারেন কারণ আপনি শুধুমাত্র শেষ কয়েকটি বড় ফাইলের প্রতি আগ্রহীঃ
প্রথমেই আপনাকে এটি খুঁজে বের করতে হবে। এই ক্ষেত্রে, আপনি ইতিমধ্যে এটি কি ফাইল জানেন । কিন্তু ধরুন আপনি জানেননা; আপনি কিভাবে সনাক্ত করবেন কোন ফাইল বা ফাইলগুলি এত স্পেস নিচ্ছে? আপনি যদি গিট gc চালান তবে সমস্ত অবজেক্টটি একটি প্যাকফাইলে থাকে; আপনি git verify-pack নামে আরেকটি প্লাম্বিং কমান্ড চালিয়ে এবং আউটপুটের তৃতীয় ফিল্ডে ফাইলের আকার সাজানোর মাধ্যমে বড় অবজেক্টগুলি সনাক্ত করতে পারেন । আপনি tail কমান্ড পাইপ করতে পারেন কারণ আপনি শুধুমাত্র শেষ কয়েকটি বড় ফাইলের প্রতি আগ্রহীঃ
$ git verify-pack -v .git/objects/pack/pack-29…69.idx \
| sort -k 3 -n \
| tail -3
dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12
033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 22044 5792 4977696
82c99a3e86bb1267b236a4b6eff7868d97489af1 blob 4975916 4976258 1438
নীচে বড় অবজেক্টটি রয়েছে: 5MB। এটি ফাইলটি কি তা খুঁজে বের করতে, আপনি rev-list কমান্ডটি ব্যবহার করবেন, যা আপনি সংক্ষেপে একটি নির্দিষ্ট কমিট-মেসেজ ফর্ম্যাটে ব্যবহার করেছেন । আপনি যদি –objects অপশনটি rev-list-এ পাস করেন, তাহলে এটি সমস্ত SHA-1s কমিট এবং ব্লব SHA-1s-এর সাথে সংশ্লিষ্ট ফাইল পাথগুলিকে তালিকাভুক্ত করে। আপনি আপনার ব্লবের নাম খুঁজে পেতে এটি ব্যবহার করতে পারেনঃ
$ git rev-list --objects --all | grep 82c99a3
82c99a3e86bb1267b236a4b6eff7868d97489af1 git.tgz
এখন, আপনাকে আপনার অতীতের সমস্ত ট্রি থেকে ফাইলটি অপসারণ করতে হবে। আপনি সহজেই দেখতে পারেন কোন কমিটগুলি এই ফাইলটিকে পরিবর্তন করেছেঃ
$ git log --oneline --branches -- git.tgz
dadf725 Oops - remove large tarball
7b30847 Add git tarball
আপনার গিট হিস্ট্রি থেকে এই ফাইলটিকে সম্পূর্ণরূপে মুছে ফেলার জন্য আপনাকে অবশ্যই 7b30847 থেকে সমস্ত কমিট ডাউনস্ট্রিম পুনরায় লিখতে হবে। এটি করার জন্য, আপনি filter-branch ব্যবহার করেন, যা আপনি রিরাইটিং হিস্ট্রিতে ব্যবহার করেছেনঃ
$ git filter-branch --index-filter \
'git rm --ignore-unmatch --cached git.tgz' -- 7b30847^..
Rewrite 7b30847d080183a1ab7d18fb202473b3096e9f34 (1/2)rm 'git.tgz'
Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 (2/2)
Ref 'refs/heads/master' was rewritten
–index-filter অপশনটি রিরাইটিং হিস্ট্রিতে ব্যবহৃত –tree-filter অপশনের অনুরূপ, কমান্ড পাস করে ডিস্কে চেক আউট করা ফাইলগুলিকে পরিবর্তন করার পরিবর্তে, আপনি প্রতিবার আপনার স্টেজিং এরিয়া বা ইনডেক্স পরিবর্তন করছেন।
rm file মতো কিছু দিয়ে একটি নির্দিষ্ট ফাইল মুছে ফেলার পরিবর্তে, আপনাকে এটিকে git rm –cached দিয়ে মুছে ফেলতে হবে – আপনাকে অবশ্যই এটিকে ইনডেক্স থেকে সরিয়ে ফেলতে হবে, ডিস্ক থেকে নয়। এইভাবে এটি করার কারণ হল গতি – যেহেতু গিটকে আপনার ফিল্টার চালানোর আগে ডিস্কে প্রতিটি রিভিশন চেক করতে হবে না, প্রক্রিয়াটি অনেক, অনেক দ্রুত হতে পারে। আপনি চাইলে –tree-filter দিয়ে একই কাজ সম্পন্ন করতে পারেন। git rm-এর –ignore-unmatch অপশনটি এটিকে বলে যে আপনি যে প্যাটার্নটি সরানোর চেষ্টা করছেন সেটি যদি না থাকে তবে ত্রুটি না ধরতে। অবশেষে, আপনি filter-branch অপশনটিকে শুধুমাত্র 7b30847 কমিটের পর থেকে আপনার গিট হিস্ট্রি পুনরায় লিখতে বলবেন, কারণ আপনি জানেন যে এই সমস্যাটি সেখান থেকেই শুরু হয়েছিল। অন্যথায়, এটি শুরু থেকে শুরু হবে এবং অপ্রয়োজনীয়ভাবে বেশি সময় লাগবে।
আপনার গিট হিস্ট্রিতে আর সেই ফাইলের রেফারেন্স নেই। যাইহোক, আপনার reflog এবং একটি নতুন সেটের refs যা গিট এ যোগ করেছে যখন আপনি .git/refs/original এর অধীনে filter-branch এ করেছিলেন, তাই আপনাকে সেগুলি সরাতে হবে এবং তারপর ডাটাবেসটি পুনরায় প্যাক করতে হবে। আপনি রিপ্যাক করার আগে আপনাকে সেই নির্দেশিত কমিটগুলিকে অপসারণ করতে হবেঃ
rm file মতো কিছু দিয়ে একটি নির্দিষ্ট ফাইল মুছে ফেলার পরিবর্তে, আপনাকে এটিকে git rm –cached দিয়ে মুছে ফেলতে হবে – আপনাকে অবশ্যই এটিকে ইনডেক্স থেকে সরিয়ে ফেলতে হবে, ডিস্ক থেকে নয়। এইভাবে এটি করার কারণ হল গতি – যেহেতু গিটকে আপনার ফিল্টার চালানোর আগে ডিস্কে প্রতিটি রিভিশন চেক করতে হবে না, প্রক্রিয়াটি অনেক, অনেক দ্রুত হতে পারে। আপনি চাইলে –tree-filter দিয়ে একই কাজ সম্পন্ন করতে পারেন। git rm-এর –ignore-unmatch অপশনটি এটিকে বলে যে আপনি যে প্যাটার্নটি সরানোর চেষ্টা করছেন সেটি যদি না থাকে তবে ত্রুটি না ধরতে। অবশেষে, আপনি filter-branch অপশনটিকে শুধুমাত্র 7b30847 কমিটের পর থেকে আপনার গিট হিস্ট্রি পুনরায় লিখতে বলবেন, কারণ আপনি জানেন যে এই সমস্যাটি সেখান থেকেই শুরু হয়েছিল। অন্যথায়, এটি শুরু থেকে শুরু হবে এবং অপ্রয়োজনীয়ভাবে বেশি সময় লাগবে।
আপনার গিট হিস্ট্রিতে আর সেই ফাইলের রেফারেন্স নেই। যাইহোক, আপনার reflog এবং একটি নতুন সেটের refs যা গিট এ যোগ করেছে যখন আপনি .git/refs/original এর অধীনে filter-branch এ করেছিলেন, তাই আপনাকে সেগুলি সরাতে হবে এবং তারপর ডাটাবেসটি পুনরায় প্যাক করতে হবে। আপনি রিপ্যাক করার আগে আপনাকে সেই নির্দেশিত কমিটগুলিকে অপসারণ করতে হবেঃ
$ rm -Rf .git/refs/original
$ rm -Rf .git/logs/
$ git gc
Counting objects: 15, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (15/15), done.
Total 15 (delta 1), reused 12 (delta 0)
আপনি কত জায়গা সংরক্ষণ করেছেন তা দেখা যাক।
$ git count-objects -v
count: 11
size: 4904
in-pack: 15
packs: 1
size-pack: 8
prune-packable: 0
garbage: 0
size-garbage: 0
প্যাক করা রিপোজিটরির আকার 8K-এ নেমে এসেছে, যা 5MB থেকে অনেক ভালো। আপনি আকারের মান থেকে দেখতে পাচ্ছেন যে বড় অবজেক্টটি এখনও আপনার লুজ অবজেক্ট হিসেবে রয়েছে, তাই এটি চলে যায়নি; কিন্তু এটি একটি পুশ বা পরবর্তী ক্লোনের মাধ্যমে স্থানান্তরিত হবে না, যা গুরুত্বপূর্ণ। আপনি যদি সত্যিই চান তবে আপনি –expire অপশনের সাথে git prune চালিয়ে অবজেক্টটিকে সম্পূর্ণরূপে সরিয়ে ফেলতে পারেন।
$ git prune --expire now
$ git count-objects -v
count: 0
size: 0
in-pack: 15
packs: 1
size-pack: 8
prune-packable: 0
garbage: 0
size-garbage: 0
