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

Git ঠিক এই জায়গাটাতেই কাজ করে। এটি আপনার প্রতিটি বদলের একটি সময়রেখা তৈরি করে রাখে, ফলে যেকোনো দিনের অবস্থায় ফিরে যাওয়া যায়। আর GitHub সেই সময়রেখাটিকে অনলাইনে রেখে টিমের সবার জন্য খুলে দেয়।

এই টিউনে আমি একটি বাস্তব ওপেন সোর্স প্রজেক্টের আসল স্ক্রিনশট দিয়ে দেখাবো ব্রাঞ্চ, Pull Request আর Merge Conflict জিনিসগুলো আসলে কেমন দেখতে হয়, আর কমান্ড লাইনে কী লিখে সেগুলো সামলাতে হয়। প্রতিটি ধাপ আপনি নিজের কম্পিউটারে করে দেখতে পারবেন।

➡ Git কেন ফোল্ডার কপি করার চেয়ে ভালো

ফোল্ডার কপি করলে আপনি শুধু একটি মুহূর্তের ছবি রেখে দেন। কিন্তু আপনি জানতে পারেন না কে কী বদলেছে, কেন বদলেছে, আর দুই জনের বদল একসাথে মেলাতে হলে কী করতে হবে। Git এই তিনটি প্রশ্নেরই উত্তর রাখে।

• প্রতিটি বদলের সাথে কে করেছে এবং কেন করেছে তা লেখা থাকে।
• যেকোনো পুরোনো অবস্থায় এক কমান্ডেই ফিরে যাওয়া যায়।
• একই ফাইলে দুই জনের কাজ আলাদা রেখে পরে মিলিয়ে নেওয়া যায়।
• কোন লাইনটি কে কখন যোগ করেছিল তা লাইন ধরে ধরে বের করা যায়।
• নতুন কোনো পরীক্ষা করতে গিয়ে মূল কাজ নষ্ট হওয়ার ভয় থাকে না।

➡ ধাপ ১: Git ইনস্টল করে প্রথম কনফিগ ঠিক করা

Git ইনস্টল করার পর সবার আগে নিজের নাম আর ইমেইল বসিয়ে দিতে হয়। কারণ প্রতিটি কমিটের গায়ে এই দুইটি তথ্য সিল হিসেবে বসে যায়। একবার ঠিক করে দিলে পরে আর ভাবতে হয় না।

git --version
git config --global user.name "Nasirul Hoque"
git config --global user.email "nasirul.hoque@example.com"
git config --global init.defaultBranch main
git config --list

শেষ কমান্ডটি দিলে এখন পর্যন্ত সেট করা সব মান একসাথে দেখা যায়। এখানে ইমেইলটি এমন দিন যেটি আপনার GitHub হিসাবেও যুক্ত আছে, তাহলে কমিটগুলো আপনার নামের সাথে মিলে যাবে।

➡ ধাপ ২: রিপোজিটরি, স্টেজিং এরিয়া ও কমিটের সম্পর্ক

একটি ফোল্ডারকে Git এর নজরে আনার নাম রিপোজিটরি তৈরি করা। এরপর কাজ চলে তিনটি ধাপে। আপনি ফাইল বদলান, তারপর কোন কোন বদল এবার সংরক্ষণ করতে চান সেগুলো আলাদা করে রাখেন, তারপর সেই দলটিকে একটি নামসহ ইতিহাসে বসিয়ে দেন।

git init
git status
git add index.html style.css
git commit -m "প্রথম পাতার কাঠামো যোগ করা হলো"
git status

স্টেজিং এরিয়া আসলে কেন দরকার

ধরুন আপনি একই সময়ে একটি বাগ ঠিক করেছেন আর একটি নতুন ফিচারও শুরু করেছেন। দুইটি এক কমিটে ঢুকে গেলে পরে শুধু বাগ ঠিক করা অংশটুকু আলাদা করে ফেরত নেওয়া কঠিন হয়ে যায়। স্টেজিং এরিয়া আপনাকে বেছে নেওয়ার সুযোগ দেয়, ফলে প্রতিটি কমিট একটি করে কাজ বোঝায়।

• কমিট মেসেজে কী করেছেন তা লিখুন, কেন করেছেন সেটিও এক লাইনে যোগ করুন।
• একটি কমিটে একটি কাজ রাখুন, দশটি বিষয় একসাথে ঢোকাবেন না।
• আপডেট বা ফাইনাল ধরনের অর্থহীন মেসেজ লেখা বাদ দিন।

➡ ধাপ ৩: কমিট ইতিহাস পড়তে শেখা

ইতিহাস পড়তে না জানলে Git এর আসল শক্তি কাজে লাগে না। নিচের ছবিটি একটি বাস্তব প্রজেক্টের কমিট তালিকা, যেখানে প্রতিটি কমিটের সাথে লেখা আছে সেটি কোন Pull Request থেকে এসেছে এবং তার ছোট হ্যাশ কী।

কমান্ড লাইনে একই ইতিহাস আরও ছোট করে দেখা যায়। নিচের কমান্ডগুলো মুখস্থ করার দরকার নেই, কাজ করতে করতে হাতে বসে যাবে।

git log --oneline --graph --decorate -n 15
git show 6177d5f
git diff HEAD~1 HEAD
git blame index.html

• প্রথম কমান্ডটি ইতিহাসকে এক লাইনের তালিকা হিসেবে ছবি আকারে দেখায়।
• দ্বিতীয়টি নির্দিষ্ট একটি কমিটে ঠিক কী বদলেছিল তা খুলে দেখায়।
• তৃতীয়টি আগের কমিট আর এখনকার কমিটের পার্থক্য দেখায়।
• চতুর্থটি বলে দেয় ফাইলের প্রতিটি লাইন কে কখন লিখেছিল।

➡ ধাপ ৪: ব্রাঞ্চ আসলে কীভাবে কাজ করে

ব্রাঞ্চ শুনতে জটিল লাগে, কিন্তু ব্যাপারটি খুব সহজ। ব্রাঞ্চ হলো ইতিহাসের একটি নির্দিষ্ট কমিটকে দেখিয়ে রাখা একটি নাম মাত্র। নতুন ব্রাঞ্চ তৈরি করলে কোনো ফাইল কপি হয় না, শুধু একটি নতুন নাম তৈরি হয়। তাই এটি প্রায় সাথে সাথেই হয়ে যায়।

ছবিতে খেয়াল করুন Behind ও Ahead নামে দুইটি ঘর আছে। Ahead মানে ওই ব্রাঞ্চে মূল ব্রাঞ্চের চেয়ে কত কমিট বেশি আছে, আর Behind মানে মূল ব্রাঞ্চে এমন কত কমিট আছে যেগুলো ওই ব্রাঞ্চ এখনো পায়নি। Behind সংখ্যাটি বড় হয়ে গেলেই কনফ্লিক্টের ঝুঁকি বাড়তে থাকে।

git switch -c feature/login
git branch
git switch main
git merge feature/login
git branch -d feature/login

ব্রাঞ্চের নাম দেওয়ার সহজ নিয়ম

• নতুন ফিচারের জন্য feature দিয়ে শুরু করুন, যেমন feature/login।
• বাগ ঠিক করার জন্য fix দিয়ে শুরু করুন, যেমন fix/cart-total।
• নামের মধ্যে ফাঁকা জায়গা বা বাংলা অক্ষর রাখবেন না।
• একটি ব্রাঞ্চে একটি কাজ রাখুন, কাজ শেষ হলে ব্রাঞ্চটি মুছে দিন।

➡ ধাপ ৫: GitHub এ রিমোট যোগ করে ব্রাঞ্চ পুশ করা

নিজের কম্পিউটারের রিপোজিটরিকে GitHub এর রিপোজিটরির সাথে যুক্ত করার নাম রিমোট যোগ করা। সাধারণত এই রিমোটের নাম রাখা হয় origin। একবার যুক্ত করলে পরে শুধু পুশ আর পুল করলেই চলে।

git remote add origin https://github.com/username/project.git
git remote -v
git push -u origin main
git switch -c feature/login
git push -u origin feature/login

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

➡ Clone, Fork ও Pull এর পার্থক্য এক নজরে

নতুনদের সবচেয়ে বেশি গোলমাল হয় এই তিনটি শব্দ নিয়ে। তিনটিই কোড আনার কাজ করে, কিন্তু উদ্দেশ্য আলাদা।

• Clone মানে অনলাইনের রিপোজিটরিটি পুরোটা নিজের কম্পিউটারে নামিয়ে আনা।
• Fork মানে অন্যের রিপোজিটরির একটি নিজের কপি নিজের হিসাবের নিচে বানিয়ে নেওয়া।
• Pull মানে অনলাইনে যে নতুন কমিট এসেছে সেগুলো নিজের কপিতে টেনে আনা।
• অন্যের প্রজেক্টে কাজ করতে চাইলে আগে Fork করুন, তারপর নিজের কপি Clone করুন।
• নিজের টিমের প্রজেক্টে সাধারণত Fork লাগে না, সরাসরি Clone করলেই হয়।

git clone https://github.com/username/project.git
cd project
git pull origin main
git fetch origin
git log origin/main --oneline -n 5

এখানে fetch আর pull এর তফাতটিও মনে রাখার মতো। fetch শুধু খবর নিয়ে আসে, আপনার ফাইলে হাত দেয় না। pull খবর নিয়ে এসে সাথে সাথে আপনার ব্রাঞ্চে মিলিয়েও দেয়।

➡ ধাপ ৬: Pull Request খুলে রিভিউ করানো

ব্রাঞ্চ পুশ করার পরের কাজ হলো Pull Request খোলা। এটি মূলত একটি অনুরোধ, যেখানে আপনি বলছেন আমার ব্রাঞ্চের কাজ মূল ব্রাঞ্চে নিয়ে নিন। এই পাতাটিতেই আলোচনা হয়, কোড দেখা হয় এবং অটোমেটেড পরীক্ষা চলে।

• Conversation ট্যাবে রিভিউয়ারের মতামত আর আপনার উত্তর জমা থাকে।
• Commits ট্যাবে এই অনুরোধের ভেতরে কতগুলো কমিট আছে তা দেখা যায়।
• Checks ট্যাবে অটোমেটেড পরীক্ষার ফল আসে।
• Files changed ট্যাবে ঠিক কোন লাইন বদলেছে তা লাইন ধরে দেখা যায়।
• ডান পাশে সবুজ ও লাল সংখ্যা দেখায় কত লাইন যোগ হলো আর কত লাইন বাদ গেল।

➡ ধাপ ৭: Files changed ট্যাবে ডিফ পড়ার নিয়ম

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

• প্রথমে ছোট ফাইলগুলো দেখুন, তারপর বড় ফাইলে যান।
• একই কাজের জন্য একশো লাইনের বদলে দশ লাইনে কাজ হচ্ছে কি না ভাবুন।
• পাসওয়ার্ড, টোকেন বা ব্যক্তিগত তথ্য ভুল করে ঢুকে গেছে কি না খুঁজে দেখুন।
• মন্তব্য লেখার সময় ব্যক্তি নয়, কোড নিয়ে কথা বলুন।

➡ ধাপ ৮: অটোমেটেড চেক ফেল করলে কী করবেন

বড় প্রজেক্টে Pull Request খোলার সাথে সাথেই কিছু পরীক্ষা নিজে নিজে চলতে শুরু করে। এগুলো কোডের গঠন দেখে, পরীক্ষা চালায়, কখনো সাইটটি তৈরি করে দেখে। কোনো একটি ফেল করলে সবুজ টিকের বদলে লাল ক্রস আসে।

• প্রথমে দেখুন কোন চেকটি ফেল করেছে, সব চেক ফেল করেনি।
• ওই চেকের নামের উপর গিয়ে লগ খুলুন, লগের শেষ দিকে আসল কারণ থাকে।
• কারণটি নিজের কম্পিউটারে আবার তৈরি করে দেখুন, তারপর ঠিক করুন।
• ঠিক করে নতুন কমিট পুশ করলে চেকগুলো আবার নিজে নিজে চলবে।

➡ ধাপ ৯: Merge Conflict কেন হয় এবং কীভাবে সামলাবেন

দুই জন যদি একই ফাইলের একই লাইনে আলাদা বদল করে, তখন Git নিজে সিদ্ধান্ত নিতে পারে না কোনটি রাখা উচিত। এই অবস্থাটিরই নাম Merge Conflict। নিচের ছবিতে দুইটি বাস্তব ব্রাঞ্চের তুলনা করা হয়েছে, আর GitHub স্পষ্ট করে বলে দিয়েছে সে নিজে মার্জ করতে পারছে না।

কনফ্লিক্ট হলে Git ওই ফাইলটির ভেতরে বিশেষ চিহ্ন বসিয়ে দেয়, যাতে আপনি দুই পক্ষের লেখা পাশাপাশি দেখতে পান। উপরের অংশটি আপনার বর্তমান ব্রাঞ্চের, আর নিচের অংশটি যে ব্রাঞ্চ মেলাতে চাইছেন তার।

<<<<<<< HEAD
const shopName = "আমাদের দোকান"
=======
const shopName = "আমাদের অনলাইন দোকান"
>>>>>>> feature/login

কাজটি এখন সহজ। চিহ্নসহ লাইনগুলো মুছে দিয়ে যেটি রাখতে চান সেটি রাখুন, দরকার হলে দুইটি মিলিয়ে নতুন একটি লাইন লিখুন। তারপর ফাইলটি স্টেজে দিয়ে মার্জ শেষ করুন।

git merge feature/login
git status
git add index.html
git commit -m "login ব্রাঞ্চের সাথে শিরোনামের কনফ্লিক্ট মেলানো হলো"
git merge --abort

কনফ্লিক্ট কমানোর কার্যকর অভ্যাস

• প্রতিদিন কাজ শুরুর আগে মূল ব্রাঞ্চ থেকে নতুন কমিট টেনে নিন।
• ব্রাঞ্চ বেশি দিন খোলা রাখবেন না, ছোট ছোট Pull Request খুলুন।
• টিমে আগেই ঠিক করে নিন কে কোন ফাইলে কাজ করছে।
• শেষ কমান্ডটি মনে রাখুন, এটি মার্জ থামিয়ে আগের অবস্থায় ফিরিয়ে দেয়।

➡ ধাপ ১০: ভুল কমিট ঠিক করার নিরাপদ উপায়

ভুল হবেই, তাই ঠিক করার উপায় জানা থাকলে সাহস বাড়ে। এখানে নিরাপদ আর ঝুঁকিপূর্ণ উপায় আলাদা করে বুঝে নেওয়া দরকার।

git restore index.html
git restore --staged index.html
git commit --amend -m "ঠিক করা মেসেজ"
git revert 6177d5f
git reset --hard HEAD~1

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

➡ কোন ফাইলগুলো কখনো কমিট করবেন না

রিপোজিটরিতে সব ফাইল রাখতে হয় না। যেগুলো নিজে নিজেই তৈরি হয় বা যেগুলোতে গোপন তথ্য থাকে সেগুলো বাদ দিতে হয়। এর জন্য প্রজেক্টের গোড়ায় .gitignore নামের একটি ছোট ফাইল বানাতে হয়।

node_modules/
dist/
.env
*.log
Thumbs.db

• নির্ভরশীল প্যাকেজের ফোল্ডার কমিট করলে রিপোজিটরি অকারণে ভারী হয়।
• তৈরি হওয়া ফাইল আবার তৈরি করা যায়, তাই ইতিহাসে রাখার দরকার নেই।
• গোপন চাবি বা টোকেন একবার ঢুকে গেলে ইতিহাস থেকে সরানো কঠিন।
• এই ফাইলটি প্রথম কমিটেই যোগ করে নিলে পরে ঝামেলা কমে।

➡ টিমে কাজ করার দৈনিক রুটিন যা সময় বাঁচায়

কমান্ড জানা এক জিনিস, আর সেগুলো কোন ক্রমে চালাতে হয় সেটি আরেক জিনিস। নিচের ছোট রুটিনটি ধরে চললে দিনের শেষে ঝামেলা অনেক কমে যায়।

git switch main
git pull origin main
git switch -c fix/cart-total
git add -A
git commit -m "কার্টের যোগফলের হিসাব ঠিক করা হলো"
git push -u origin fix/cart-total

• দিন শুরু করুন মূল ব্রাঞ্চে গিয়ে নতুন কমিট টেনে নিয়ে।
• তারপর আজকের কাজের জন্য একটি নতুন ব্রাঞ্চ খুলুন।
• কাজের মাঝে অন্তত দুই তিন বার কমিট করুন, একদম শেষে একবার নয়।
• দিন শেষে ব্রাঞ্চটি পুশ করে রাখুন, কম্পিউটার নষ্ট হলেও কাজ থাকবে।
• কাজ শেষ হলে Pull Request খুলে রিভিউ চান, নিজেই মার্জ করে দেবেন না।

➡ যে ভুল গুলো একদম করবেন না

• মূল ব্রাঞ্চে সরাসরি কাজ করে ফেলা, ফলে ভাঙলে সবার কাজ থেমে যায়।
• একটি কমিটে বিশটি আলাদা কাজ ঢুকিয়ে দেওয়া।
• কনফ্লিক্ট দেখে ভয় পেয়ে পুরো ফোল্ডার মুছে আবার ক্লোন করা।
• ইতিহাস জোর করে বদলে দিয়ে সহকর্মীর কমিট হারিয়ে ফেলা।
• গোপন টোকেন বা পাসওয়ার্ড কোডের ভেতরে রেখে পুশ করে দেওয়া।
• Pull Request এর মন্তব্য না পড়ে সরাসরি মার্জ করে দেওয়া।

➡ শেষ কথা

Git শেখার আসল উপায় হলো একটি ছোট প্রজেক্ট নিয়ে ইচ্ছে করে ঝামেলা তৈরি করা। নিজেই দুইটি ব্রাঞ্চে একই লাইন বদলে কনফ্লিক্ট বানান, তারপর সেটি মিলিয়ে দেখুন। একবার নিজের হাতে সমাধান করলে ভয়টা একেবারে চলে যাবে।

উপরের প্রতিটি ছবি বাস্তব একটি ওপেন সোর্স প্রজেক্টের পাতা থেকে নেওয়া আসল স্ক্রিনশট, শুধু বোঝার সুবিধার জন্য আমি লাল ঘর আর বাংলা নাম বসিয়ে দিয়েছি। আপনিও যেকোনো বড় প্রজেক্টের পাতা খুলে একই জিনিসগুলো নিজের চোখে দেখতে পারেন।

আপনার কোন ধাপে আটকে যাচ্ছে তা টিউমেন্টে লিখে জানাতে পারেন। পরের টিউনে Rebase আর Cherry Pick নিয়ে হাতে কলমে আলোচনা করার ইচ্ছা আছে।