Git কী এবং ডেভেলপারের কেন এটি দরকার

Git একটি ভার্সন কন্ট্রোল সিস্টেম

Git এমন একটি প্রোগ্রাম, যা প্রকল্পের ফাইলের পরিবর্তনের ইতিহাস মনে রাখে। আপনি যখনই কোডের একটি অবস্থা সংরক্ষণ করেন, Git লেখক, তারিখ ও বিবরণসহ একটি স্ন্যাপশট (কমিট) রাখে। যেকোনো স্ন্যাপশটে ফেরা যায়, বর্তমানের সঙ্গে তুলনা করা যায়, এবং কোনো লাইন কে ও কেন বদলেছে তা খুঁজে বের করা যায়।

আপনি যদি কখনো "প্রজেক্ট_v2", "প্রজেক্ট_ফাইনাল" আর "প্রজেক্ট_ফাইনাল_সত্যিই_ফাইনাল" নামে ফোল্ডার রেখে থাকেন, তাহলে ভার্সন কন্ট্রোল আপনি আগেই হাতে হাতে করেছেন। Git একই কাজ স্বয়ংক্রিয়ভাবে, কম জায়গায় এবং কিছু হারানোর ভয় ছাড়াই করে। তাই ডেভেলপারদের কথায় "git কী" প্রশ্নের উত্তর শুধু একটি প্রোগ্রাম নয়, বরং একটি মৌলিক কাজের সরঞ্জাম, যা কোড এডিটরের মতোই অপরিহার্য।

ফোল্ডারে কপি বা ক্লাউড ড্রাইভ থেকে Git-এর পার্থক্য

ক্লাউড ড্রাইভ ফাইলের সর্বশেষ সংস্করণ রাখে এবং সর্বোচ্চ কিছু স্বয়ংক্রিয় কপি। Git একটি অর্থবহ ইতিহাস রাখে: কখন পরিবর্তন সংরক্ষণ করবেন তা আপনি ঠিক করেন, এবং কী করেছেন তা লিখে রাখেন। এ ছাড়া Git এমন কিছু পারে, যা কোনো ড্রাইভ পারে না:

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

Git নামের অর্থ এবং অনুবাদ

Git-এর কোনো সরকারি পূর্ণরূপ নেই, এটি কোনো সংক্ষিপ্ত রূপ (abbreviation) নয়। Linus Torvalds প্রোগ্রামটির নাম দিয়েছিলেন নিজের স্টাইলে: ব্রিটিশ স্ল্যাংয়ে git মানে "বিরক্তিকর, একগুঁয়ে লোক"। Torvalds নিজেই মজা করে বলেছেন, তিনি সব প্রকল্পের নাম নিজের নামে রাখেন। শব্দটির আক্ষরিক অর্থ প্রায় "বদমাশ", "বোকা লোক"।

প্রকল্পের প্রথম README-তে লেখক কয়েকটি মজার ব্যাখ্যা দিয়েছিলেন: যেমন "global information tracker" যখন সবকিছু ঠিকভাবে চলে, আর একটি গালিগালাজসূচক ব্যাখ্যা যখন কিছু ভাঙে। তাই ইন্টারভিউয়ে কেউ "git-এর পূর্ণরূপ কী" জিজ্ঞেস করলে সঠিক উত্তর: কোনো পূর্ণরূপ নেই, এটি একটি শব্দ, সংক্ষিপ্ত রূপ নয়।

বাংলায় লেখা হয় "Git" বা "গিট", দুটিই বোঝা যায়। উচ্চারণ এক অক্ষরে, "গিট", "জিট" নয়।

Git-এর উৎপত্তি

২০০৫ সালের আগে Linux কার্নেলের ডেভেলপাররা মালিকানাধীন সিস্টেম BitKeeper ব্যবহার করতেন। কমিউনিটির জন্য বিনামূল্যের লাইসেন্স প্রত্যাহার হলে Torvalds কয়েক সপ্তাহের মধ্যে নিজের সিস্টেম লেখেন। শর্ত ছিল কঠোর: বিশাল প্রকল্পে দ্রুত গতি, সম্পূর্ণ ডিস্ট্রিবিউটেড কাজ, ইতিহাসকে নষ্ট হওয়া থেকে নিরাপদ রাখা, এবং হাজার হাজার সমান্তরাল ব্রাঞ্চের সহজ ব্যবহার।

শীঘ্রই প্রকল্পের দায়িত্ব নেন Junio Hamano, যিনি এখনো Git-এর মেইনটেইনার। আজ Git একটি GPLv2 লাইসেন্সের উন্মুক্ত সিস্টেম, এবং এর ওপর ভিত্তি করে চলে GitHub, GitLab, Bitbucket, Gitea এবং বহু কর্পোরেট প্ল্যাটফর্ম।

Git কীভাবে কাজ করে

Git-কে জাদুকরী কমান্ডের তালিকা মনে না হওয়ার জন্য তিনটি ধারণা বোঝা দরকার। এগুলো Git-এর প্রায় সব আচরণ ব্যাখ্যা করে।

১. স্ন্যাপশট, পার্থক্য নয়

অনেক পুরনো সিস্টেম পরিবর্তনগুলো ফাইলের সম্পাদনার সেট হিসেবে রাখত। Git স্ন্যাপশটের মাধ্যমে চিন্তা করে: প্রতিটি কমিট হলো কমিটের সময়কার পুরো প্রকল্পের অবস্থা। জায়গা বাঁচাতে যেসব ফাইল বদলায়নি, সেগুলো কপি হয় না; কমিট কেবল আগে সংরক্ষিত অবজেক্টের দিকে ইশারা করে। রিপোজিটরি প্যাক করার সময় Git আরও মিল থাকা অবজেক্ট সংকুচিত করে, তাই বড় প্রকল্পের ইতিহাসও অল্প জায়গা নেয়।

২. সবকিছু হ্যাশ দিয়ে চিহ্নিত

Git-এর প্রতিটি অবজেক্ট, অর্থাৎ ফাইলের বিষয়বস্তু (blob), ফোল্ডারের গঠন (tree) এবং কমিট (commit), তার বিষয়বস্তু থেকে হিসাব করা একটি শনাক্তকারী পায়। ঐতিহাসিকভাবে এটি SHA-1 (৪০টি হেক্সাডেসিমাল অক্ষর), নতুন সংস্করণে SHA-256 দিয়েও রিপোজিটরি বানানো যায়। পুরনো কমিট কেউ গোপনে বদলাতে পারে না: তার হ্যাশ বদলে যায়, এবং পরের সব কমিটের হ্যাশও বদলে যায়।

$ git log --oneline -3
a3f9c21 লগইন ফর্ম যোগ করা
7b02e4d ইমেইল যাচাই ঠিক করা
1c8d5f0 প্রথম কমিট

বাঁদিকের ছোট স্ট্রিংগুলো কমিটের সংক্ষিপ্ত হ্যাশ। এগুলো দিয়ে যেকোনো সংস্করণে যাওয়া যায়: git show 7b02e4d।

৩. ফাইলের তিনটি অবস্থা

এটি Git-এর মূল ভিত্তি, যা প্রায় প্রতিটি ইন্টারভিউয়ে জিজ্ঞেস করা হয়। প্রকল্পের ফাইল তিনটি অঞ্চলের একটিতে থাকতে পারে:

ইনডেক্সই Git-কে অনেক সিস্টেম থেকে আলাদা করে। এটি দিয়ে পরিবর্তনের একটি অংশ কমিটে তোলা যায়: যেমন একটি বাগ ঠিক করা আলাদাভাবে, আর ভ্যারিয়েবলের নাম বদলানো আলাদাভাবে। এতে ইতিহাস পড়তে সহজ হয়।

ডিস্ট্রিবিউটেড: কেন প্রত্যেকের হাতে পূর্ণ কপি থাকে

Git একটি ডিস্ট্রিবিউটেড ভার্সন কন্ট্রোল সিস্টেম (DVCS)। ক্লোন করলে আপনি শুধু শেষ ফাইলগুলো নন, পুরো প্রকল্পের ইতিহাসও পান। বেশিরভাগ কাজ, যেমন কমিট, ইতিহাস দেখা, ব্রাঞ্চ বানানো, তুলনা করা, লোকালি এবং মুহূর্তে হয়, সার্ভার ছাড়াই।

এই মডেলে GitHub-এর মতো সার্ভার আসলে আরেকটি কপি, যাকে দল মূল হিসেবে মেনে নিয়েছে। সেটি বন্ধ থাকলেও কাজ থামে না: আপনি কমিট করে যেতে পারেন, এবং পরে git push দিয়ে পাঠাতে পারেন। সার্ভার পুরোপুরি হারিয়ে গেলেও যেকোনো ক্লোন থেকে ইতিহাস ফিরিয়ে আনা যায়।

Git এবং GitHub এক জিনিস নয়

নতুনদের মধ্যে এটি প্রায়ই বিভ্রান্তি সৃষ্টি করে। Git হলো আপনার কম্পিউটারে চলা প্রোগ্রাম। GitHub একটি ওয়েব সার্ভিস, যেখানে Git রিপোজিটরি রাখা হয় এবং দলগত কাজের সরঞ্জাম থাকে: pull request, কোড রিভিউ, টাস্ক, CI। GitLab ও Bitbucket একই ধরনের সার্ভিস।

GitHub ছাড়াও Git ব্যবহার করা যায়, যেমন ব্যক্তিগত নোটের বা লোকাল প্রকল্পের জন্য। কিন্তু Git ছাড়া GitHub-এর কোনো মানে হয় না, কারণ এটি তার রিপোজিটরিকে ঘিরেই তৈরি।

Git-এর মৌলিক কাজের চক্র

প্রতিদিনের কাজ এমন দেখায়। এই কয়েকটি কমান্ড ডেভেলপারের প্রতিদিনের কাজের বেশিরভাগ ঢেকে দেয়।

# বর্তমান ফোল্ডারে রিপোজিটরি তৈরি
git init

# কী বদলেছে দেখা
git status

# ফাইল ইনডেক্সে যোগ করা
git add index.html style.css

# স্ন্যাপশট রেকর্ড করা
git commit -m "হোমপেজের লেআউট তৈরি"

# ইতিহাস দেখা
git log --oneline

# নতুন ব্রাঞ্চ বানিয়ে তাতে যাওয়া
git switch -c feature/login

# ব্রাঞ্চটি মূল ব্রাঞ্চে merge করা
git switch main
git merge feature/login

# সার্ভারে পরিবর্তন পাঠানো
git push origin main

git switch Git 2.23-এ এসেছে, git checkout-এর কিছু কাজের আরও বোধগম্য বিকল্প হিসেবে। পুরনো নির্দেশনায় git checkout -b feature/login দেখবেন, সেটি একই কাজ করে।

git commit-এর সময় কী ঘটে

Git ইনডেক্সের বিষয়বস্তু নেয়, প্রতিটি ফাইল blob হিসেবে সংরক্ষণ করে, ফোল্ডারের জন্য tree অবজেক্ট বানায়, এবং একটি commit অবজেক্ট তৈরি করে। কমিটে লেখা থাকে: ট্রির রেফারেন্স, প্যারেন্ট কমিটের রেফারেন্স (merge-এর পর দুটি), লেখক, কমিটার এবং বার্তা। এরপর বর্তমান ব্রাঞ্চের পয়েন্টার নতুন কমিটে সরে যায়। Git-এ ব্রাঞ্চ মূলত শেষ কমিটের হ্যাশসহ একটি ফাইল, তাই ব্রাঞ্চ বানাতে মিলিসেকেন্ড লাগে।

Git ডেভেলপারের জন্য কেন দরকার: ব্যবহারিক কারণ

পরীক্ষা নিয়ে ভয় থাকে না

প্রতিটি পরিবর্তন ফেরানো যায়। কোড ভেঙে ফেললে git restore ফাইল শেষ সংরক্ষিত সংস্করণ ফিরিয়ে দেয়। ইতিহাসে ঢুকে যাওয়া খারাপ কমিট git revert দিয়ে বাতিল করা যায়, এতে একটি উল্টো কমিট যোগ হয় এবং সবার ইতিহাস বদলায় না। এতে কাজের ধরন বদলে যায়: ফেরা সেকেন্ডের ব্যাপার, তাই আপনি সাহস করে চেষ্টা করেন।

দলগত কাজ, বিশৃঙ্খলা ছাড়া

প্রতিজন ডেভেলপার নিজের ব্রাঞ্চে কাজ করেন এবং অন্যদের বিঘ্ন ঘটান না। কাজ শেষ হলে পরিবর্তন রিভিউ হয় এবং মূল ব্রাঞ্চে merge হয়। দুজন একই জায়গায় বদলালে Git কনফ্লিক্ট দেখায় এবং ইচ্ছেমতো সমাধান করতে দেয়, অন্যের কাজ নীরবে মুছে দেয় না।

ইতিহাসই ডকুমেন্টেশন

ভালো কমিট বার্তা বলে দেয় "কোড কেন এমন"। git blame ফাইল দেখায় কে ও কোন কমিটে প্রতিটি লাইন শেষবার বদলেছে, আর git log -p ফাইল পুরো বিবর্তন দেখায়। এক বছর পর এটি ঘণ্টার পর ঘণ্টা অনুসন্ধান বাঁচায়।

নিয়োগকর্তাদের প্রত্যাশা

প্রায় প্রতিটি ডেভেলপার, টেস্টার, DevOps ইঞ্জিনিয়ার ও ডেটা বিশ্লেষকের চাকরির বিজ্ঞপ্তিতে Git-এর উল্লেখ থাকে। ইন্টারভিউয়ে মুখস্থ কমান্ড নয়, বোঝাপড়া যাচাই করা হয়: merge আর rebase-এর পার্থক্য, ইনডেক্স কী, কমিট কীভাবে বাতিল করতে হয়, কনফ্লিক্ট কীভাবে মেটাতে হয়। আর GitHub-এর পরিষ্কার কমিট ইতিহাসসহ প্রোফাইল একটি পোর্টফোলিওর কাজ করে।

আর কাদের Git দরকার

যেখানে টেক্সট ফাইল আছে এবং ইতিহাস গুরুত্বপূর্ণ, সেখানেই Git কাজে লাগে: টেকনিক্যাল রাইটারদের (Markdown-এ ডকুমেন্টেশন), ওয়েব ডিজাইনারদের, বিশ্লেষকদের (SQL স্ক্রিপ্ট, নোটবুক), অ্যাডমিনিস্ট্রেটরদের (সার্ভার কনফিগ, infrastructure as code)। বড় বাইনারি ফাইল, যেমন ভিডিও, PSD বা ডেটাসেটের জন্য ব্যবহার হয় Git LFS এক্সটেনশন, কারণ Git নিজে টেক্সটের জন্য অপ্টিমাইজড।

Pro Git: Git-এর সেরা বই

গভীরে যেতে চাইলে শুরু করুন Scott Chacon ও Ben Straub-এর লেখা "Pro Git" বই দিয়ে। এটি বিনামূল্যে, উন্মুক্ত লাইসেন্সে প্রকাশিত, এবং অফিসিয়াল সাইট git-scm.com-এর Book বিভাগে আছে, অনুবাদসহ। এটিই সেই "git pro", যা প্রায়ই খোঁজা হয়: মৌলিক থেকে অভ্যন্তরীণ কাঠামো পর্যন্ত একটি পূর্ণ পাঠ্যবই।

কার্যকরভাবে পড়তে:

• ১–৩ অধ্যায় (ভূমিকা, মৌলিক ধারণা, ব্রাঞ্চিং) — ন্যূনতম বাধ্যতামূলক, টার্মিনালে কমান্ডগুলো নিজে চালিয়ে দেখুন;
• রিমোট রিপোজিটরি ও GitHub-এর অধ্যায় — দলে কাজ শুরু করার সময়;
• "Git ভেতর থেকে" অধ্যায় — অবজেক্ট ও রেফারেন্স কীভাবে কাজ করে সত্যিই বুঝতে চাইলে।

দ্বিতীয় অফিসিয়াল ভরসা হলো বিল্ট-ইন সহায়তা: git help commit বা git commit --help কমান্ডের পূর্ণ ডকুমেন্টেশন খুলবে, আর git commit -h ফ্ল্যাগের সংক্ষিপ্ত সারাংশ দেখাবে।

নতুনদের সাধারণ ভুল ধারণা

• "Git ফাইল নিজে থেকে সংরক্ষণ করে।" না, কমিট না করা পর্যন্ত পরিবর্তন শুধু ওয়ার্কিং ডিরেক্টরিতে থাকে।
• "কমিট সঙ্গে সঙ্গে GitHub-এ চলে যায়।" কমিট লোকাল। git push করার পরই সার্ভারে যায়।
• "git add মানে নতুন ফাইল।" git add আগে থেকে ট্র্যাক হওয়া ফাইলের পরিবর্তনও ইনডেক্সে যোগ করে।
• "ইতিহাস থেকে মুছে গেলে আর ফেরানো যায় না।" প্রায় সবসময় যায়: git reflog পয়েন্টারের চলাচল রাখে, এবং "হারানো" কমিট হ্যাশ দিয়ে খুঁজে পাওয়া যায়।
• "ব্রাঞ্চ মানে প্রকল্পের কপি।" ব্রাঞ্চ একটি কমিটের হালকা পয়েন্টার, ফাইলের ডুপ্লিকেট নয়।

কোথা থেকে শুরু করবেন

1. Git ইনস্টল করুন এবং ভার্সন দেখুন: git --version।
2. নাম ও ইমেইল সেট করুন: git config --global user.name ও user.email।
3. একটি অনুশীলন রিপোজিটরি বানান, ৫–১০টি কমিট করুন, git log ও git diff দেখুন।
4. ব্রাঞ্চ নিয়ে কাজ করুন: বানান, merge করুন, ইচ্ছে করে একটি কনফ্লিক্ট তৈরি করে সমাধান করুন।
5. GitHub-এ অ্যাকাউন্ট খুলুন, রিপোজিটরি পাঠান, প্রথম pull request খুলুন।

এই ক্রম পড়ে-যাওয়া রেফারেন্সের চেয়ে দ্রুত ফল দেয়: প্রতিটি কমান্ড রিপোজিটরির অবস্থা কীভাবে বদলায়, তা সরাসরি দেখতে পাবেন।

সারসংক্ষেপ

Git একটি ডিস্ট্রিবিউটেড ভার্সন কন্ট্রোল সিস্টেম, যা প্রকল্পের ইতিহাস স্ন্যাপশটে রাখে, হ্যাশ দিয়ে সুরক্ষিত রাখে এবং দলকে ব্রাঞ্চে সমান্তরালে কাজ করতে দেয়। এর পূর্ণরূপ নেই, আর "git কী" প্রশ্নের বাস্তব উত্তর: ডেভেলপারের জন্য অপরিহার্য একটি সরঞ্জাম। add → commit → push চক্রটি আয়ত্ত করুন, ফাইলের তিন অবস্থা ও ব্রাঞ্চ বুঝুন, তারপর Pro Git বইয়ে গভীরে যান। প্রথম কমিট থেকে pull request পর্যন্ত পুরো পথটি Git কোর্সে ধাপে ধাপে বাস্তব অনুশীলনের মাধ্যমে শেখানো হয়।