Git-এর ইন্টারভিউ প্রশ্ন: ২৫টি প্রশ্ন ও উত্তর

Git প্রায় যেকোনো ডেভেলপার, টেস্টার বা DevOps ইন্টারভিউয়ে আসে: কখনো আলাদা অংশে, কখনো ফাঁকে ফাঁকে ("খারাপ রিলিজ কীভাবে ফেরাবেন?")। ইন্টারভিউয়ার কমান্ডের ফ্ল্যাগ নয়, বরং মডেলটি বোঝা দেখতে চান: কমিট কী, ব্রাঞ্চ কোথায় তাকিয়ে থাকে, ইতিহাস কী বদলায়। নিচে সবচেয়ে বেশি আসা ২৫টি প্রশ্ন, সঙ্গে ভালো প্রভাব ফেলার মতো উত্তর।

প্রশ্নগুলো মূল থেকে উন্নত স্তরে সাজানো। উত্তর দেওয়ার সময় যতটা সম্ভব একটি ছোট বাস্তব উদাহরণ যোগ করুন — এটি ডকুমেন্টেশন মুখস্থ বলার চেয়ে বেশি মূল্য পায়।

মূল প্রশ্ন

১. Git কী, এবং বিতরণকৃত (distributed) সংস্করণ নিয়ন্ত্রণ কেন কেন্দ্রীভূত ব্যবস্থার থেকে আলাদা?

Git একটি বিতরণকৃত সংস্করণ নিয়ন্ত্রণ ব্যবস্থা: এটি প্রজেক্টের ইতিহাস রাখে এবং কয়েকজন মানুষকে একসাথে কাজ করতে দেয়। কেন্দ্রীভূত ব্যবস্থায় (যেমন SVN) পূর্ণ ইতিহাস একটি সার্ভারে থাকে, আর ডেভেলপারের কাছে থাকে শুধু ওয়ার্কিং কপি। Git-এ প্রতিটি ক্লোনে পূর্ণ ইতিহাস থাকে, তাই কমিট, ব্রাঞ্চ, ইতিহাস দেখা ও merge স্থানীয়ভাবে, নেটওয়ার্ক ছাড়াই চলে।

এতে ব্যবহারিক সুবিধা: দ্রুত গতি, অফলাইনে কাজ, একক ব্যর্থতার বিন্দু না থাকা। GitHub বা GitLab-এর মতো সার্ভার Git-এ শুধু দলের একটি "মূল" কপি সম্পর্কে চুক্তি, কোনো প্রযুক্তিগত বাধ্যবাধকতা নয়।

২. Git-এর কাজে কোন তিনটি অংশ থাকে?

ওয়ার্কিং ডিরেক্টরি (ডিস্কের ফাইল), ইনডেক্স বা staging area (পরের কমিটের প্রস্তুত স্ন্যাপশট) এবং লোকাল রিপোজিটরি (.git ফোল্ডারের ইতিহাস)। git add ওয়ার্কিং ডিরেক্টরি থেকে ইনডেক্সে, আর git commit ইনডেক্স থেকে রিপোজিটরিতে পরিবর্তন নেয়।

একটি ভালো সংযোজন: চতুর্থ অংশ হিসেবে দূরবর্তী রিপোজিটরি এবং সেটির সঙ্গে কাজ করা git push ও git fetch-এর কথা উল্লেখ করুন।

৩. কমিট সরাসরি করা যায় তো, ইনডেক্সের দরকার কী?

ইনডেক্স কমিট সচেতনভাবে গড়তে দেয়: দশটি বদলানো ফাইলের মধ্যে একই কাজের তিনটি কমিট করে বাকি অংশ রাখা যায়। git add -p দিয়ে এমনকি একটি ফাইলের ভেতরের আলাদা অংশও বাছা যায়।

এটি পারমাণবিক (atomic) কমিটের ভিত্তি: একটি কমিট — একটি যুক্তিসংগত পরিবর্তন। এমন ইতিহাস পড়া, রিভিউ করা, revert দিয়ে বাতিল করা ও cherry-pick দিয়ে নেওয়া সহজ।

৪. অভ্যন্তরীণভাবে Git-এ কমিট কী?

কমিট এমন একটি অবজেক্ট, যা একটি ট্রি (tree) — প্রজেক্টের সব ফাইলের স্ন্যাপশট — এর রেফারেন্স, প্যারেন্ট কমিটের রেফারেন্স, লেখক, কমিটার, তারিখ ও বার্তা ধরে রাখে। এটি চিহ্নিত হয় SHA-1 হ্যাশ দিয়ে (নতুন সংস্করণে SHA-256-এর পরীক্ষামূলক সমর্থনও আছে), যা পুরো কনটেন্ট থেকে তৈরি।

মূল ধারণা: Git স্ন্যাপশট সংরক্ষণ করে, ডিফ নয়। বদলায়নি এমন ফাইল নকল হয় না — ট্রি একই blob-কে নির্দেশ করে। হ্যাশ প্যারেন্টের ওপর নির্ভর করে, তাই একটি পুরোনো কমিট বদলালে পরের সব কমিটের হ্যাশ বদলে যায়; সেটি সরাসরি সম্ভব নয়।

৫. ব্রাঞ্চ ও HEAD কী?

ব্রাঞ্চ শুধু একটি চলমান পয়েন্টার: .git/refs/heads/-এর ভেতরে একটি ফাইল, যেখানে একটি কমিট-হ্যাশ লেখা। তাই Git-এ ব্রাঞ্চ বানানো তাৎক্ষণিক এবং কিছু নকল করে না। নতুন কমিট হলে বর্তমান ব্রাঞ্চের পয়েন্টার তাতে সরে যায়।

HEAD হলো আপনি এখন কোথায় আছেন তার পয়েন্টার; সাধারণত সেটি একটি ব্রাঞ্চকে নির্দেশ করে (ref: refs/heads/main)। কোনো নির্দিষ্ট কমিট বা ট্যাগে সরাসরি গেলে HEAD সেই কমিটকেই নির্দেশ করে — এটি detached HEAD অবস্থা।

৬. detached HEAD কী, এবং কেন বিপজ্জনক?

এই অবস্থায় HEAD একটি ব্রাঞ্চের বদলে সরাসরি একটি কমিটকে নির্দেশ করে, যেমন git switch --detach v1.0 বা git checkout a1b2c3d-এর পর। কোড দেখা ও কমিট করা যায়, কিন্তু নতুন কমিট কোনো ব্রাঞ্চের অংশ হয় না।

এরপর অন্য ব্রাঞ্চে গেলে সেই কমিটগুলো অপ্রাপ্য হয়ে যায় এবং সময়ের সঙ্গে আবর্জনা সংগ্রাহক মুছে দেয়। কাজ বাঁচাতে একটি ব্রাঞ্চ বানান: git switch -c fix-from-detached। ইতিমধ্যে চলে গিয়ে থাকলে হ্যাশটি git reflog-এ পাওয়া যাবে।

৭. git fetch আর git pull-এর পার্থক্য কী?

git fetch নতুন কমিট নামায় এবং origin/main-এর মতো রিমোট-ট্র্যাকিং ব্রাঞ্চ আপডেট করে, কিন্তু আপনার লোকাল ব্রাঞ্চ বা ফাইলে হাত দেয় না। git pull হলো fetch + সংযুক্তি: ডিফল্টে merge, আর --rebase ফ্ল্যাগ বা pull.rebase=true সেটিংয়ে rebase।

অভিজ্ঞ ডেভেলপাররা প্রায়ই আলাদাভাবে fetch করেন, git log HEAD..origin/main দেখেন, তারপর ঠিক করেন কীভাবে পরিবর্তন মেলাবেন।

৮. .gitignore কীভাবে কাজ করে, এবং ফাইল যোগ করার পরও কেন ট্র্যাক হয়?

.gitignore এমন প্যাটার্ন দেয়, যেগুলো Git-কে যোগ করার প্রস্তাব দেয় না: ডিপেন্ডেন্সি, বিল্ড, লগ, সিক্রেটসহ লোকাল কনফিগ। নিয়মগুলো শুধু ট্র্যাক-না-করা ফাইলে কাজ করে।

ফাইল আগে থেকে কমিট হয়ে থাকলে ignore তাতে প্রভাব ফেলে না। সেটি ইনডেক্স থেকে সরাতে হবে, ডিস্কে রেখে: git rm --cached config.local.php, তারপর এই মোছাটি কমিট করুন। কোন নিয়ম কাজ করছে তা দেখতে git check-ignore -v পথ।

ব্রাঞ্চ, merge ও কনফ্লিক্ট

৯. fast-forward merge কী?

লক্ষ্য ব্রাঞ্চ ভাগ হওয়ার পর থেকে না এগোলে Git merge-এর সময় তার পয়েন্টারকে শুধু নতুন ব্রাঞ্চের শেষ কমিটে সরিয়ে দেয় — নতুন কমিট ছাড়াই। ইতিহাস সরল থাকে।

--no-ff ফ্ল্যাগ এমন ক্ষেত্রেও merge-কমিট বানাতে বাধ্য করে: ইতিহাসে দেখা যায় কমিটের একটি গোষ্ঠী আলাদা ফিচার ছিল। --ff-only উল্টো, শুধু fast-forward অনুমোদন করে এবং প্রকৃত merge দরকার হলে থেমে যায়।

১০. merge-কনফ্লিক্ট কীভাবে ওঠে, এবং কীভাবে মেটাবেন?

কনফ্লিক্ট ওঠে যখন দুটি ব্রাঞ্চেই একই লাইন বদলানো হয়েছে (অথবা একটিতে ফাইল মোছা, অন্যটিতে বদলানো), আর Git নিজে সিদ্ধান্ত নিতে পারে না। সে merge থামায় এবং জায়গাগুলো <<<<<<<, =======, >>>>>>> চিহ্ন দিয়ে দেখায়।

git status                 # কনফ্লিক্টযুক্ত ফাইলের তালিকা
# ফাইল ঠিক করুন, সঠিক রূপটি রেখে
git add app.js
git commit                 # merge-এর জন্য; rebase-এ git rebase --continue

ভালো উত্তরে প্রতিরোধও থাকে: ছোট ব্রাঞ্চ, মূল ব্রাঞ্চ থেকে ঘনঘন pull, এবং ফরম্যাটিং নিয়ে দলের চুক্তি। আর পিছিয়ে আসতে চাইলে git merge --abort।

১১. merge ও rebase-এর পার্থক্য কী?

merge দুটি ব্রাঞ্চ জোড়া লাগায়, দুই প্যারেন্ট-সহ একটি merge-কমিট বানিয়ে; বিদ্যমান কমিট বদলায় না, তাই ইতিহাস সমান্তরাল কাজের সত্যিকার চিত্র দেয়। rebase আপনার ব্রাঞ্চের কমিটগুলো অন্য ব্রাঞ্চের ওপর সরিয়ে নতুন হ্যাশসহ কপি বানায়; ফলে ইতিহাস সরল হয়।

সাধারণ নিয়ম: rebase — প্রকাশের আগে নিজের লোকাল ব্রাঞ্চ গোছাতে, merge — শেয়ার্ড ব্রাঞ্চে একত্র করতে। যে প্রকাশিত কমিটের ওপর অন্যরা কাজ করছে, তার rebase করলে নকল কমিট ও বিভ্রান্তি তৈরি হয়।

১২. ইন্টারঅ্যাক্টিভ rebase কী, এবং এর কাজ কী?

git rebase -i HEAD~5 শেষ পাঁচটি কমিটের তালিকা খোলে, যেখানে প্রতিটির জন্য কাজ বাছা যায়: pick — রাখা, reword — বার্তা বদলানো, edit — থেমে সম্পাদনা, squash ও fixup — আগেরটির সঙ্গে মেশানো, drop — মোছা। লাইনের ক্রমও বদলানো যায়।

সাধারণ ব্যবহার: pull request-এর আগে "wip", "fix typo", "আরও ফিক্স"-এর মতো কমিটগুলোকে দুই-তিনটি অর্থবহ কমিটে রূপ দেওয়া। সুবিধাজনক জুটি: git commit --fixup=<hash> এবং তারপর git rebase -i --autosquash।

১৩. squash merge কী, এবং কখন বেছে নেওয়া হয়?

squash merge-এ ব্রাঞ্চের সব কমিট লক্ষ্য ব্রাঞ্চে একটি কমিটে সংকুচিত হয় (git merge --squash, অথবা GitHub/GitLab-এর বোতাম)। মূল ব্রাঞ্চে প্রতিটি ফিচারের জন্য একটি করে কমিট যায়।

সুবিধা — main-এর পরিষ্কার ইতিহাস। অসুবিধা — ফিচারের ভেতরের বিস্তারিত ইতিহাস হারায়, আর Git উৎস ব্রাঞ্চকে merge-করা মনে করে না, তাই -D ছাড়া git branch -d সেটি মুছতে অস্বীকার করে।

১৪. cherry-pick কী, এবং কখন উপযুক্ত?

git cherry-pick <hash> একটি কমিটের পরিবর্তন বর্তমান ব্রাঞ্চে প্রয়োগ করে: একই বিষয়বস্তুর নতুন কমিট, তবে ভিন্ন হ্যাশসহ। চিরাচরিত ব্যবহার — develop থেকে বাগ-ফিক্স রিলিজ বা হটফিক্স ব্রাঞ্চে নেওয়া।

বেশি ব্যবহার ঠিক নয়: একই ফিক্স দুটি কমিটে থাকে, এবং পরে ব্রাঞ্চ মেশালে কনফ্লিক্ট হতে পারে। -x ফ্ল্যাগ বার্তায় মূল কমিটের উল্লেখ যোগ করে।

বাতিল ও পুনরুদ্ধার

১৫. git reset-এর --soft, --mixed ও --hard-এর পার্থক্য কী?

মোড	ব্রাঞ্চ পয়েন্টার	ইনডেক্স	কাজের ফোল্ডার
--soft	সরে	বদলায় না	বদলায় না
--mixed (ডিফল্ট)	সরে	রিসেট হয়	বদলায় না
--hard	সরে	রিসেট হয়	রিসেট হয়, সম্পাদনা হারায়

git reset --soft HEAD~3 শেষ তিনটি কমিটকে একটিতে নতুন করে সাজাতে কাজে আসে। --hard কমিট-না-করা সম্পাদনার জন্য বিপজ্জনক: সেগুলো reflog-ও ফেরাতে পারে না।

১৬. git revert আর git reset-এর পার্থক্য কী?

reset ব্রাঞ্চ পয়েন্টারকে পেছনে সরায়, কার্যত ইতিহাস পুনর্লিখন করে। revert একটি নতুন কমিট বানায়, যা নির্দিষ্ট কমিটের পরিবর্তন উল্টে দেয়, এবং কিছু পুনর্লিখন করে না।

তাই শেয়ার্ড ব্রাঞ্চের প্রকাশিত কমিটের জন্য সঠিক উত্তর — revert: সহকর্মীদের ইতিহাস ভাঙে না, এবং বাতিলটি লগে দৃশ্যমান থাকে। merge-কমিটের জন্য মূল প্যারেন্ট বলে দিতে হয়: git revert -m 1 <hash>।

১৭. ভুলবশত git reset --hard দিলে কমিট কীভাবে ফেরাবেন?

git reflog দিয়ে: এটি HEAD ও ব্রাঞ্চের স্থানান্তরের ইতিহাস স্থানীয়ভাবে রাখে (ডিফল্টে এন্ট্রি প্রায় ৯০ দিন থাকে)। ভুল কমান্ডের আগের এন্ট্রি খুঁজে সেখানে ফিরুন:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: পেমেন্ট যোগ
git reset --hard 9f8e7d6

গুরুত্বপূর্ণ সীমা: reflog শুধু কমিট-করা জিনিস বাঁচায়। যা কখনো কমিট বা অন্তত stash-এ যায়নি, তা Git দিয়ে ফেরানো যায় না।

১৮. ফাইলের সম্পাদনা বাতিল এবং ইনডেক্স থেকে সরানো কীভাবে?

আধুনিক কমান্ড: git restore app.js (ফাইলকে ইনডেক্সের অবস্থায় ফেরায়) এবং git restore --staged app.js (ইনডেক্স থেকে সরায়, সম্পাদনা রেখে)। আগে এর জন্য git checkout -- app.js ও git reset HEAD app.js ব্যবহার হতো; সেগুলো এখনো চলে।

১৯. git stash কী, এবং এর ফাঁদগুলো কী?

git stash কমিট-না-করা পরিবর্তন সাময়িকভাবে সরিয়ে কাজের ফোল্ডার খালি করে — যেমন জরুরি হটফিক্সে যাওয়ার জন্য। git stash pop বা apply দিয়ে ফেরানো যায়।

ফাঁদ: ডিফল্টে ট্র্যাক-না-করা ফাইল যায় না (-u লাগে); pop-এ কনফ্লিক্ট হলে এন্ট্রি তালিকা থেকে মোছে না; আর stash সহজেই ভুলে যাওয়া যায়। দীর্ঘ কাজের জন্য আলাদা ব্রাঞ্চে কমিট করা ভালো।

উন্নত প্রশ্ন ও দলগত কাজ

২০. যে কমিট কোনো কার্যকারিতা ভেঙেছে, সেটি কীভাবে খুঁজবেন?

git bisect দিয়ে — ইতিহাসে দ্বিভাজন অনুসন্ধান। নিশ্চিতভাবে খারাপ ও ভালো কমিট বলে দিলে Git পরিসরের মাঝখানে নিয়ে যায়, এবং log2(N) ধাপে দোষী কমিট খুঁজে বের করে।

git bisect start
git bisect bad                 # বর্তমান সংস্করণ ভাঙা
git bisect good v2.3.0         # এখানে সবকিছু চলত
# যাচাই করে good/bad উত্তর দিন, যতক্ষণ না Git কমিট চিহ্নিত করে
git bisect reset

পরীক্ষার একটি স্ক্রিপ্ট থাকলে প্রক্রিয়াটি স্বয়ংক্রিয় হয়: git bisect run npm test।

২১. git push --force কেন বিপজ্জনক, এবং এর বদলে কী?

--force রিমোট ব্রাঞ্চকে আপনার সংস্করণ দিয়ে ওভাররাইট করে, ফলে সহকর্মীদের পাঠানো কমিট সার্ভার থেকে মুছে যায়। নিরাপদ বিকল্প git push --force-with-lease: এটি শুধু তখনই ওভাররাইট করে যখন রিমোট ব্রাঞ্চ আপনার শেষ fetch-এ দেখা অবস্থায় আছে।

rebase-এর পর নিজের ফিচার ব্রাঞ্চে জোর push স্বাভাবিক; main ও অন্য শেয়ার্ড ব্রাঞ্চে সাধারণত সার্ভারের ব্রাঞ্চ-সুরক্ষায় তা বন্ধ রাখা হয়।

২২. কোন Git workflow-গুলো আপনি জানেন?

GitHub Flow: একটি মূল ব্রাঞ্চ, যা সবসময় ডেপ্লয়ের জন্য প্রস্তুত, এবং ছোট ফিচার ব্রাঞ্চ, যেগুলো রিভিউ ও CI-র পর pull request দিয়ে মেশে। Git Flow: main ও develop ব্রাঞ্চ, পাশে feature/*, release/* ও hotfix/*; ভার্সনভিত্তিক রিলিজের পণ্যের জন্য উপযোগী। Trunk-based development: সবাই খুব ঘন ঘন মূল ট্রাঙ্কে মেশায়, অসমাপ্ত কাজ feature flag-এর আড়ালে থাকে।

ভালো উত্তর পছন্দের কারণ ব্যাখ্যা করে: ক্রমাগত ডেপ্লয়ের ওয়েব সার্ভিসের জন্য Git Flow সাধারণত অতিরিক্ত, আর একাধিক ভার্সন সমর্থনকারী লাইব্রেরির জন্য তা যুক্তিসংগত।

২৩. pull request কী, এবং সেখানে কী যাচাই করা হয়?

Pull request (GitLab-এ merge request) হলো ব্রাঞ্চ মেশানোর অনুরোধ, যা মেশার আগে কোড রিভিউ ও স্বয়ংক্রিয় CI-পরীক্ষার মধ্য দিয়ে যায়। এটি প্ল্যাটফর্মের বৈশিষ্ট্য (GitHub, GitLab, Bitbucket), Git-এর নিজের নয়।

ভালো PR ছোট, একটি কাজ সমাধান করে, পরিষ্কার বর্ণনা থাকে এবং ট্র্যাকারের কাজের সঙ্গে যুক্ত। রিভিউয়ার দেখেন সঠিকতা, পাঠযোগ্যতা, টেস্ট, এবং PR-এ অপ্রয়োজনীয় ফাইল বা সিক্রেট ঢুকেছে কি না।

২৪. আপনি কোন নিয়মে কমিট বার্তা লেখেন?

ছোট শিরোনাম (৫০–৭২ অক্ষরের মধ্যে), আদেশসূচক ক্রিয়াপদে — "ইমেইল যাচাই যোগ করা", তারপর একটি ফাঁকা লাইন এবং বিস্তারিত অংশ, যেখানে লেখা থাকে "কেন" — "কী" নয়, কারণ কী বদলেছে তা ডিফেই দেখা যায়। অনেক দল Conventional Commits অনুসরণ করে: feat:, fix:, docs:, refactor:।

এমন বার্তা থেকে স্বয়ংক্রিয়ভাবে changelog বানানো যায়, git log --grep দিয়ে দ্রুত খোঁজা যায়, এবং বছর পরেও বদলের কারণ বোঝা যায়।

২৫. ভুলে পাসওয়ার্ড রিপোজিটরিতে push হয়ে গেলে কী করবেন?

প্রথমে সিক্রেট বাতিল করে নতুন তৈরি করুন: সেটি আপস হয়ে গেছে, এক মিনিট পরে মুছলেও (ক্লোন, ফর্ক, ক্যাশ)। তারপর ফাইলটিকে ট্র্যাক থেকে সরান, .gitignore-এ যোগ করুন, এবং প্রয়োজনে git filter-repo-র মতো টুল দিয়ে ইতিহাস পরিষ্কার করুন — এরপর force push ও দলকে সতর্কবার্তা।

ইন্টারভিউয়ার এখানে অগ্রাধিকার যাচাই করেন: যে প্রার্থী ইতিহাস পুনর্লিখন দিয়ে শুরু করেন এবং কী বাতিলের কথা ভোলেন, তাঁর উত্তর ভুল।

কীভাবে প্রস্তুতি নেবেন

সবচেয়ে নির্ভরযোগ্য উপায় — উত্তর মুখস্থ না করে প্রতিটি পরিস্থিতি একটি পরীক্ষামূলক রিপোজিটরিতে হাতে চালানো: কনফ্লিক্ট বানিয়ে মেটানো, reset --hard করে reflog দিয়ে ফেরা, ইন্টারঅ্যাক্টিভ rebase দিয়ে কমিট সংকোচন। Git-এর ইন্টারভিউয়ে প্রায়ই একটি ব্যবহারিক কাজ দেওয়া হয় বা কমান্ডের আগে-পরে কমিট-গ্রাফ আঁকতে বলা হয় — নিজে করে থাকলে উত্তর সহজে আসে।

নিজেকে যাচাই করতে একটি ছোট Git-কুইজও কাজে লাগে: কোনো সাহায্য ছাড়া ভাবুন git rebase main বা git revert HEAD-এর পর ইতিহাসে কী বদলায়। তিনটি অংশে কী বদলায়, এই প্রশ্নে যদি আত্মবিশ্বাসের সঙ্গে উত্তর আসে, তবে ভিত্তি আছে।

সারসংক্ষেপ

Git-এর ইন্টারভিউ প্রায় সবসময় তিন বিষয়ে ঘোরে: ডেটা মডেল (কমিট, ব্রাঞ্চ, HEAD, ইনডেক্স), পরিবর্তন মেলানো (merge, rebase, কনফ্লিক্ট, fetch ও pull) এবং নিরাপদ বাতিল (reset, revert, reflog)। এর সঙ্গে দলগত workflow ও pull request-এর ধারণা যোগ করলে বেশিরভাগ প্রশ্নের উত্তর আপনার হাতে থাকবে। এই সব পরিস্থিতি, দলগত কাজ ও উন্নত সরঞ্জামসহ, কোর্সে হাতেকলমে অনুশীলন করা হয়।