আপনার ম্যাকের কোনো লোকাল গিট প্রজেক্টে কোন কমিটটি সর্বশেষ একটি লাইন পরিবর্তন করেছে তা খুঁজে পেতে, টার্মিনাল খুলুন, রিপোজিটরিতে যান এবং লাইন নম্বর রেঞ্জ সহ ফাইলটিতে git blame চালান। তারপর এর মেসেজ এবং ডিফারেন্স (diff) পড়তে git show দিয়ে সেই কমিটটি পরীক্ষা করুন। Blame বর্তমান লাইনে হওয়া সর্বশেষ পরিবর্তনটি চিহ্নিত করে; লাইনটি প্রথমে কখন উপস্থিত হয়েছিল বা কেন এটি লেখা হয়েছিল তা এটি সবসময় প্রকাশ করে না।

১. টার্মিনালে রিপোজিটরিটি খুলুন

যদি আপনার প্রজেক্টটি ইতোমধ্যে ফাইন্ডারে খোলা থাকে, তবে টার্মিনাল খুলে cd টাইপ করুন, তারপর প্রজেক্ট ফোল্ডারটি টার্মিনাল উইন্ডোতে ড্র্যাগ করে এনে Return চাপুন। macOS ফোল্ডারের পাথটি বসিয়ে দেবে; এটি ভুল টাইপ হওয়া এড়ায়। বিকল্পভাবে, নিজেই পাথটি লিখুন এবং এতে স্পেস থাকলে কোটেশন চিহ্নের মধ্যে রাখুন, উদাহরণস্বরূপ:

cd "/Users/sam/Projects/My App"

আপনি একটি গিট ওয়ার্কিং ট্রির ভেতরে আছেন কি না এবং গিট উপলব্ধ আছে কি না তা যাচাই করুন:

git status --short
git --version

যদি প্রথম কমান্ডটি জানায় যে বর্তমান ডিরেক্টরিটি কোনো গিট রিপোজিটরি নয়, তবে প্রজেক্টের আসল রিপোজিটরি ডিরেক্টরিতে যান। যদি git অনুপলব্ধ থাকে, তবে পরবর্তী পদক্ষেপে যাওয়ার আগে আপনার নির্ভরযোগ্য কোনো সেটআপের মাধ্যমে গিট ইনস্টল বা সক্রিয় করুন। নিচের কমান্ডগুলো স্ট্যান্ডার্ড শেল সিনট্যাক্স ব্যবহার করে এবং macOS টার্মিনালের ডিফল্ট শেলের পাশাপাশি অন্যান্য সাধারণ শেলগুলোতেও কাজ করে।

২. যে লাইনটি নিয়ে আপনি কাজ করছেন তার জন্য blame চালান

আপনার এডিটরে লাইন নম্বরটি খুঁজুন, তারপর নিচের ফাইল পাথ এবং লাইন নম্বরটি প্রতিস্থাপন করুন। পাথটি রিপোজিটরি রুটের সাপেক্ষে আপেক্ষিক (relative); এতে স্পেস বা শেল মেটাক্যারেক্টার থাকলে কোটেশন চিহ্নের ভেতরে রাখুন।

git blame -L 42,42 -- "Sources/Settings.swift"

-L 42,42 অ্যানোটেশনটিকে ৪২ নম্বর লাইনে সীমাবদ্ধ করে। গিট ১ থেকে লাইন গণনা শুরু করে। আশেপাশের প্রসঙ্গ পরীক্ষা করতে, -L 38,46-এর মতো একটি রেঞ্জ ব্যবহার করুন। গিট একটি কমিট আইডেন্টিফায়ার, লেখকের বিবরণ, তারিখের তথ্য এবং লাইনের টেক্সট প্রদর্শন করে। এর ডকুমেন্টেশনে ব্লেমকে প্রতিটি লাইন সর্বশেষ পরিবর্তনকারী রিভিশন এবং লেখক প্রদর্শনকারী হিসেবে বর্ণনা করা হয়েছে এবং এটি -L দিয়ে লাইনের রেঞ্জ নির্বাচন সমর্থন করে। Git blame documentation

আপনি যদি লাইন নম্বর না জানেন, তবে আপনার এডিটরে ফাইলটি খুলুন এবং এর প্রদর্শিত লাইন নম্বরগুলো ব্যবহার করুন। আপনি -L বাদ দিয়ে পুরো ফাইলটির ওপরেও blame চালাতে পারেন:

git blame -- "Sources/Settings.swift"

আপনি যখন রিপোজিটরি রুটে না থাকেন, তখন যে ডিরেক্টরিতে কমান্ডটি চালিয়েছেন তার সাপেক্ষে আপেক্ষিক পাথ ব্যবহার করুন। গিট যদি বলে যে পাথটির অস্তিত্ব নেই, তবে আপনার বর্তমান ডিরেক্টরি (pwd) এবং পাথের সঠিক ক্যাপিটালাইজেশন ও বানান উভয়ই পরীক্ষা করুন।

৩. blame দ্বারা চিহ্নিত কমিটটি পড়ুন

টার্গেট লাইনের জন্য দেখানো কমিট আইডেন্টিফায়ারটি কপি করুন এবং এটি git show-তে পাস করুন:

git show --format=fuller --stat a1b2c3d

আপনার আউটপুট থেকে পাওয়া আইডেন্টিফায়ার দিয়ে a1b2c3d প্রতিস্থাপন করুন। এটি কমিট মেটাডেটা এবং একটি ফাইলের সারাংশ প্রদর্শন করে। প্যাচটিও পড়তে চাইলে, --stat বাদ দিন:

git show --format=fuller a1b2c3d

টার্গেট লাইনের আশেপাশের পরিবর্তিত লাইনগুলো, কমিট মেসেজ এবং একই কমিটে পরিবর্তিত অন্যান্য ফাইলগুলো দেখুন। এই বিবরণগুলো পরিবর্তনের প্রেক্ষাপট ব্যাখ্যা করতে সাহায্য করতে পারে। একটি কমিট মেসেজ তার লেখক যা লিখেছেন তা রেকর্ড করে; এটি ডিজাইনের মূল যুক্তির প্রমাণ নয়। গিট git show-কে কমিটের তথ্য এবং এর টেক্সচুয়াল ডিফারেন্স প্রদর্শনকারী হিসেবে নথিভুক্ত করে। Git show documentation

যখন blame কোনো ফরম্যাটিং বা মুভ সংক্রান্ত কমিট নির্দেশ করে

একটি লাইন কোনো ব্যাপক ফরম্যাটিং পরিবর্তন, নাম পরিবর্তন বা কোড সরানোর দ্বারা স্পর্শিত হতে পারে। সেক্ষেত্রে, অভিযুক্ত কমিটটি হয়তো সেই কমিট নয় যা মূলত লজিকটি প্রবর্তন করেছিল। মুভ এবং কপি সনাক্তকরণ চেষ্টা করুন:

git blame -M -C -L 42,42 -- "Sources/Settings.swift"

-M গিটকে একটি ফাইলের ভেতরে সরানো লাইনগুলো সনাক্ত করতে বলে, আর -C অন্য ফাইল থেকে কপি করা বা সরানো লাইনগুলোও খুঁজে দেখে। এই অপশনগুলো গিটকে কিছু রিফ্যাক্টর ট্রেস করতে সহায়তা করে, তবে সনাক্তকরণ বিষয়বস্তুর মিলের ওপর নির্ভর করে এবং এটি প্রতিটি হিস্ট্রি সমাধান করতে নাও পারে। Git blame documentation

ফরম্যাটিংয়ের মতো ব্যাপক পরিবর্তনের জন্য যদি কোনো রিপোজিটরিতে একটি .git-blame-ignore-revs ফাইল থাকে, তবে আপনি গিটকে সেটি ব্যবহার করতে বলতে পারেন:

git blame --ignore-revs-file .git-blame-ignore-revs -L 42,42 -- "Sources/Settings.swift"

এটি প্রাসঙ্গিক পরিবর্তনটি সহজে চিহ্নিত করতে সাহায্য করতে পারে, তবে উপেক্ষা করা রিভিশনগুলো অ্যানোটেশনকে প্রভাবিত করে; ফলাফলটি অপ্রত্যাশিত মনে হলে রিপোজিটরির ইগনোর ফাইলটি পরীক্ষা করুন বা সেই অপশন ছাড়া চালানো blame-এর সাথে তুলনা করুন। গিটের ডকুমেন্টেশনে এই বিকল্পটি তালিকাভুক্ত রয়েছে এবং গিটহাবও একই ইগনোর-রিভিশন ফাইল রীতি নথিভুক্ত করে। Git blame documentation

blame আপনাকে যা জানাতে পারে না

নির্বাচিত ফাইল সংস্করণে যেসব লাইন বিদ্যমান রয়েছে, Blame কেবল সেগুলোর ওপর অ্যানোটেশন দেয়। এটি মুছে ফেলা বা প্রতিস্থাপিত লাইনগুলো সরাসরি দেখায় না, এবং অতি সাম্প্রতিক পরিবর্তনকারী কমিটটি মূল প্রবর্তনের থেকে ভিন্ন হতে পারে। মুছে ফেলা টেক্সট বা আগের ফাইল অবস্থার জন্য, কমিট ডিফারেন্স এবং হিস্ট্রি পরীক্ষা করুন; বিষয়বস্তু অপসারণ বা প্রতিস্থাপনকারী পরিবর্তনগুলোর জন্য গিটের ব্লেম ডকুমেন্টেশন git diff এবং হিস্ট্রি অনুসন্ধানের নির্দেশনা দেয়। Git blame documentation

রিপোজিটরিটি যদি গিটহাবে হোস্ট করা থাকে এবং আপনার এতে অ্যাক্সেস থাকে, তবে ব্রাউজারে লাইন-বাই-লাইন হিস্ট্রি দেখতে আপনি ফাইলটি খুলে Blame নির্বাচন করতে পারেন। সেই পরিবর্তনটি পরীক্ষা করতে একটি কমিট মেসেজে ক্লিক করুন, অথবা তার আগের ফাইলটি দেখতে ভার্সন কন্ট্রোল ব্যবহার করুন। GitHub Docs: Viewing and understanding files

উৎসসমূহ