Git এবং Version Control

😅 অংশ ১: সমস্যা - Manual Versioning এর যন্ত্রণা

Shamim-এর ফোল্ডার দেখুন

Shamim একজন Junior Developer।

গত ৬ মাসে তার laptop-এ একটি project folder এত বড় হয়েছে যে এটা একটি archaeological site-এর মতো দেখাচ্ছে।

Shamim-এর project folder structure:
project/
project-final/
project-final-v2/
project-final-v2-REAL/
project-final-v2-REAL-FINAL/
project-final-v2-REAL-FINAL-working/
project-backup-2024-01-15/
project-before-refactor/

Shamim একদিন Tamim-এর কাছে গেছে:

"ভাই, কোনটা আসল latest version? কোনটা আমি production-এ দিয়েছিলাম? গত সপ্তাহে যা কাজ করেছিলাম সেটা কোথায়? সব তো গুলিয়ে গেছে!" 😭

Tamim হেসে বলল:
"Shamim, এটা version control নাকি একটা digital garbage dump?" 😄

Manual Versioning এর সমস্যা

সমস্যা ১: Confusion
কোন folder-টি latest? কোনটি production-এ গেছে? কোনটি broken?

সমস্যা ২: Collaboration Nightmare
Team member-দের কাছে code কীভাবে পাঠাবেন? Email দিয়ে 100MB zip file? তারপর তারা যখন পাঠায় তখন merge কীভাবে করবেন?

সমস্যা ৩: History শুধু ফোল্ডার নাম-এ
কে কখন কী change করেছে? কেন করেছে? এটা জানার কোনো উপায় নেই।

সমস্যা ৪: Accidental Deletion
একটা ভুলে কোনো folder delete করলে? সব ঠিক করার উপায় নেই। File corrupt হয়ে গেলে? Backup করা আছে কি?

সমস্যা ৫: Multiple People Same File
Shamim এবং Tamim একই file edit করছে। কার version রাখবে? দুটোই merge করতে হবে manually?

সমস্যা ৬: No Rollback Plan
Production-এ কিছু ভেঙে গেলে? আগের version এ ফিরে যেতে পারবেন তো?

Real-World Impact

সবচেয়ে বড় বিপদ: একটি ছোট mistake পুরো project ধ্বংস করতে পারে। আর তখন কোনো recovery plan থাকে না।

এবং সবচেয়ে খারাপ অংশ: কোনো team এ কাজ করা almost অসম্ভব হয়ে যায়।

তাহলে সমাধান?

এখানে আসে Version Control System (VCS)।

একটি টুল যা:
✓ প্রতিটি change track করে
✓ Who, What, When, Why জানায়
✓ যেকোনো সময় পুরোনো version-এ ফিরে যেতে পারে
✓ Team collaboration সহজ করে
✓ Branch দিয়ে parallel কাজ সম্ভব করে
✓ Merge করা সহজ হয়

এবং সব-চেয়ে জনপ্রিয় VCS হলো Git।

📚 অংশ ২: Version Control - মূল ধারণা

Version Control কী?

Tamim Shamim-কে বসিয়ে একটা সহজ উদাহরণ দিল:

"ভাই, একটা লাইব্রেরি ভাবো। যেখানে প্রতিটি বই-এর একটি ledger আছে। যখন কেউ বই নেয়, লেখা হয় - কে নিল, কখন নিল, কখন ফেরত দেবে। যখন বই ফেরত আসে, সেটাও লেখা হয়।"

"Code-এর ক্ষেত্রেও এমনটাই। প্রতিটি change-এর একটি record থাকে - কে করেছে, কখন করেছে, কী করেছে, কেন করেছে।"

Shamim: "তাহলে Version Control একটি History Tracker?"

Tamim: "ঠিক! কিন্তু শুধু tracker নয়। এটা আপনাকে যেকোনো পুরোনো version-এ ফিরে যেতে সাহায্য করে, branch দিয়ে parallel কাজ করতে দেয়, এবং conflict resolve করতে সাহায্য করে।"

VCS এর প্রধান সুবিধা

১. Complete History
প্রতিটি file-এর complete history থাকে। কোন date-এ কী ছিল তা জানা যায়।

২. Blame/Attribution
প্রতিটি line-এর জন্য জানা যায় কে লিখেছে, কখন লিখেছে।

৩. Rollback
কিছু ভেঙে গেলে আগের version-এ ফিরে যেতে পারে।

৪. Branching
একই সাথে একাধিক feature নিয়ে কাজ করা যায়।

৫. Merging
দুটো branch-এর পরিবর্তন একসাথে করা যায়।

৬. Collaboration
একই project নিয়ে একাধিক মানুষ কাজ করতে পারে conflict ছাড়াই।

VCS এর প্রকার

📍 Centralized VCS

একটি central server আছে। সব developer সেখানে commit করে।

উদাহরণ: SVN, Perforce

সমস্যা: Server down হলে কাজ করা যায় না।

🌐 Distributed VCS

প্রতিটি developer-এর কাছে complete copy থাকে। Server থাকা optional।

উদাহরণ: Git, Mercurial

সুবিধা: Server down হলেও কাজ চলে। Backup automatic।

Git একটি Distributed VCS। এর মানে প্রতিটি developer-এর laptop-এ complete project history থাকে। এটি Git-কে খুবই powerful করে তোলে।

🐙 অংশ ৩: Git এবং GitHub - পার্থক্য বুঝি

Shamim-এর বড় সারপ্রাইজ

Shamim জিজ্ঞাসা করল: "Tamim ভাই, Git এবং GitHub একই জিনিস না?"

Tamim গুরুত্ব সহকারে উত্তর দিল:
"না ভাই। এটা খুবই গুরুত্বপূর্ণ বুঝা যাতে পরে confusion না হয়।"

Tamim একটি অঙ্গভঙ্গি করল:
"ভাবো Git একটি ক্যামেরা। GitHub একটি photo storage service।
ক্যামেরা ছাড়া photo তুলতে পারবে না। কিন্তু ক্যামেরা থাকলে GitHub ছাড়াও photo রাখতে পারবে।
আবার GitHub ছাড়া ক্যামেরা দিয়েই ছবি রাখতে পারবে, কিন্তু অনেকের সাথে share করা হবে কঠিন।"

Git কী?

Git একটি Version Control Software।

এটি:
• আপনার computer-এ install করা একটি tool
• Code-এর change track করে
• History সংরক্ষণ করে
• আপনার local machine-এ সব কাজ করে
• File system-এর সাথে কাজ করে
• Network connection ছাড়াই কাজ করতে পারে

Git এর মূল কাজ: Code এর history manage করা।

GitHub কী?

GitHub একটি hosting service + collaboration platform।

এটি:
• Git repository-কে internet-এ রাখে
• Team collaboration সহজ করে
• Pull Request নামে একটি code review system আছে
• Issue tracking আছে
• Wiki এবং documentation hosting করে
• GitHub Actions দিয়ে automation করা যায়

GitHub এর মূল কাজ: Collaboration এবং repository hosting।

গুরুত্বপূর্ণ পার্থক্য

১. Git ছাড়া GitHub হয় না
GitHub সবকিছু Git-এর উপর built।

২. GitHub ছাড়া Git-এর কাজ করা যায়
আপনি শুধু Git দিয়ে local machine-এ কাজ করতে পারেন। GitHub লাগে না।

৩. Git = Tool, GitHub = Service
Git একটি software, GitHub একটি web-based service।

৪. এখানে local repository থাকে
Git আপনার laptop-এ repository তৈরি করে। GitHub server-এ repository রাখে।

Git

✓ Software
✓ Local
✓ Free
✓ Command-line based
✓ History tracking

GitHub

✓ Web platform
✓ Remote (cloud)
✓ Free + Paid plans
✓ Web interface
✓ Collaboration tools

🧠 অংশ ৪: Git এর মানসিক মডেল - সবচেয়ে গুরুত্বপূর্ণ

Shamim খুবই confused ছিল।

"Tamim ভাই, আমি file edit করলাম। তারপর git add দিলাম। তারপর git commit দিলাম। তারপর git push দিলাম। এত ধাপ কেন? সব এক সাথে হয় না?"

Tamim দীর্ঘশ্বাস ফেলে বলল:
"এটাই Git-এর সবচেয়ে গুরুত্বপূর্ণ ধারণা। এটি বুঝে গেলে সব clear হয়ে যাবে।"

Git এর চার স্তর

Working Directory ↓ (git add) ↓ Staging Area ↓ (git commit) ↓ Local Repository ↓ (git push) ↓ Remote Repository ↓ GitHub

স্তর ১: Working Directory

Working Directory হলো আপনার project folder।

এখানেই আপনি সারাদিন কোড লিখছেন, file edit করছেন, delete করছেন।

যখন আপনি একটা file edit করেন, Git বুঝে যায় "আরে, এই file-টা change হয়েছে!"

কিন্তু এখনও GitHub-এ কিছু যায়নি। শুধু আপনার laptop-এ change হয়েছে।

উদাহরণ:
আপনি app.py file-এ একটা function যোগ করলেন। এটা শুধু আপনার Working Directory-তে।

স্তর ২: Staging Area

Staging Area হলো একটি "draft" এলাকা।

যখন আপনি git add কমান্ড দেন, file-টা Working Directory থেকে Staging Area-তে যায়।

এর মানে "এই changes আমি commit করার জন্য প্রস্তুত করছি"।

কিন্তু এখনও commit হয়নি। এটা শুধু প্রস্তুতি।

গুরুত্বপূর্ণ: আপনি যে সব files add করেছেন, শুধু সেগুলোই commit হবে।

উদাহরণ:
আপনি git add app.py দিলেন। এখন app.py Staging Area-তে আছে, কিন্তু অন্য যেসব file edit করেছেন সেগুলো এখনো staging-এ নেই।

স্তর ৩: Local Repository

Local Repository হলো আপনার notebook।

যখন আপনি git commit কমান্ড দেন, Staging Area থেকে সব changes Local Repository-তে চলে যায়।

এখানে একটি "snapshot" তৈরি হয়। এই snapshot-টা Git database-এ সংরক্ষিত থাকে।

এটা permanent। এর মানে আপনি এই version-এ যেকোনো সময় ফিরতে পারবেন।

কিন্তু গুরুত্বপূর্ণ: এটা এখনও আপনার laptop-এ। GitHub-এ গেছে না।

উদাহরণ:
আপনি git commit -m "Add login function" দিলেন। এখন এই snapshot Local Repository-তে সংরক্ষিত আছে, কিন্তু GitHub জানে না।

স্তর ৪: Remote Repository (GitHub)

Remote Repository হলো GitHub এ আপনার repository।

যখন আপনি git push কমান্ড দেন, Local Repository থেকে সব commits GitHub-এ চলে যায়।

এখন সবাই আপনার code দেখতে পারে (যদি public repository হয়)। Team member-রা এটা pull করতে পারে।

এই জায়গায় এসে code truly "uploaded" হয়েছে।

উদাহরণ:
আপনি git push origin main দিলেন। এখন GitHub-এ আপনার সব commits চলে গেছে। Team member-রা দেখতে পাবে।

Shamim এখন বুঝলো

Shamim: "তাহলে:

Working Directory = আমার desk
Staging Area = আমার draft folder
Local Repository = আমার personal notebook
Remote Repository = Public library

মানে, আমি desk-এ লিখছি, তারপর draft folder-এ নিছি, তারপর personal notebook-এ সংরক্ষণ করছি, তারপর library-তে শেয়ার করছি?"

Tamim: "ঠিক! এখন আপনি Git এর মূল ধারণা বুঝে গেছেন।"

প্রতিটি স্তরে সম্ভাব্য অপারেশন

স্তর	কমান্ড	কাজ
Working → Staging	`git add`	File add করা
Staging → Local	`git commit`	Snapshot তৈরি করা
Local → Remote	`git push`	GitHub-এ পাঠানো
Remote → Local	`git pull`	GitHub থেকে আনা
Working দেখা	`git status`	কী change হয়েছে দেখা

💻 অংশ ৫: Working Directory - কোথায় শুরু

Working Directory এর ভূমিকা

Working Directory হলো আপনার project folder।

এখানেই আপনি সারাদিন:
• নতুন file তৈরি করেন
• existing file edit করেন
• file delete করেন
• নতুন folder তৈরি করেন

Git এর দৃষ্টিকোণ থেকে: এটি "untouched" স্থান। এখানে কিছু change হলে Git সেটা track করে, কিন্তু এটা permanent করা হয় না।

Git Status - সব কিছু জানার উপায়

Shamim কমান্ড লিখল:
git status

Git output দিল:
On branch main
Changes not staged for commit:
modified: app.py
deleted: config.old

Untracked files:
new_feature.py

এর মানে:
• app.py - একটি tracked file change হয়েছে, কিন্তু stage করা হয়নি
• config.old - একটি tracked file delete হয়েছে
• new_feature.py - একটি নতুন file, Git এটা এখনো জানে না

Git Diff - পরিবর্তন দেখা

git diff কমান্ড দিয়ে কী কী change হয়েছে দেখতে পারেন।

git diff → Working Directory-র changes দেখায় যা staged করা হয়নি
git diff --staged → Staging Area-র changes দেখায় যা commit করার জন্য প্রস্তুত

File এর অবস্থা

Untracked File (নতুন, Git-এ নেই) ↓ Modified File (এটা change হয়েছে) ↓ Deleted File (remove করা হয়েছে) ↓ Staged File (add করা হয়েছে) ↓ Committed File (snapshot-এ রাখা হয়েছে)

📋 অংশ ৬: Staging Area - প্রস্তুতির জায়গা

Staging Area এর গুরুত্ব

Shamim জিজ্ঞাসা করল: "Tamim ভাই, কেন শুধু git commit করতে পারি না? কেন

git
            add

আগে করতে হয়?"

Tamim: "ভালো প্রশ্ন। কারণ আপনি যখন কাজ করছেন তখন অনেক file change করেন। কিন্তু সব change একসাথে commit করা ঠিক নয়। এক commit-এ এক feature থাকা উচিত।"

"Staging Area আপনাকে এটা control দেয়। আপনি বলতে পারেন - এই file-গুলো এক commit-এ, ওই file-গুলো অন্য commit-এ।"

কেন Staging Area দরকার

পরিস্থিতি:
আপনি একটা feature কাজ করছেন, একই সাথে একটা bug fix করছেন, এবং documentation update করছেন। এখন আপনার কাছে ৫টি file change হয়েছে।

Staging Area ছাড়া:
সব ৫টি file একসাথে commit হয়ে যাবে। একটা commit-এ feature + bug fix + docs সব মিশে থাকবে। এটা bad practice।

Staging Area সহ:
আপনি feature-র files add করেন, commit করেন। তারপর bug fix এর files add করেন, commit করেন। তারপর docs update commit করেন।

ফলে, history এত clean থাকে যে কেউ পড়লে বুঝে যায় "এই commit feature যোগ করেছে", "ওই commit bug fix করেছে"।

Selective Staging

# সব file add করা git add . # নির্দিষ্ট file add করা git add app.py utils.py # একটি নির্দিষ্ট file এর নির্দিষ্ট part add করা git add -p app.py

Unstaging - পরিবর্তন করা

যদি ভুল করে একটা file stage করেছেন, unstage করা যায়:

git restore --staged filename

এবার সেই file আবার Working Directory-র status পাবে।

📦 অংশ ৭: Local Repository - আপনার নোটবুক

Commit - Snapshot তৈরি করা

Shamim: "Commit মানে কী? একটা save point?"

Tamim: "হ্যাঁ, কিন্তু শুধু save point নয়। এটা একটা complete snapshot সাথে metadata সহ।"

Tamim এক্সপ্লেইন করল:
"প্রতিটি commit একটি package যার মধ্যে আছে:
• সব file-এর নির্দিষ্ট সময়ের version
• কে করেছে (author)
• কখন করেছে (timestamp)
• কেন করেছে (message)
• একটি unique identifier (SHA hash)"

Commit করার উপায়

# সাধারণ commit
git commit -m "Add user authentication"

# বিস্তারিত message সহ
git commit -m "Add user authentication" -m "- Implement login function
- Add password hashing
- Create user model"

Commit Message লেখা

ভাল commit message:
"Add user authentication module"

খারাপ commit message:
"fixed stuff"
"asdf"
"work in progress"

কেন ভাল message গুরুত্বপূর্ণ:
কয়েক মাস পরে যখন এটা দেখবেন বা team member দেখবে, তারা সাথে সাথে বুঝে যাবে এই commit কী করেছে।

Commit History দেখা

# সব commits দেখা
git log

# সংক্ষিপ্ত version দেখা
git log --oneline

# একটি নির্দিষ্ট file-এর history
git log app.py

মনে রাখুন: প্রতিটি commit এর একটি unique hash থাকে। এই hash দিয়ে যেকোনো সময় সেই commit-এ ফিরতে পারবেন।

☁️ অংশ ৮: Remote Repository - GitHub সংযোগ

Remote কী?

Remote হলো একটি দূরবর্তী repository।

সাধারণত এটি GitHub-এ থাকে। এটি internet-এ accessible।

আপনার Local Repository-র সাথে Remote Repository-র সংযোগ থাকে।

সবচেয়ে common remote:
origin - যেখান থেকে আপনি project clone করেছিলেন

Git Remote Commands

# সব remotes দেখা
git remote -v

# নতুন remote যোগ করা
git remote add origin https://github.com/username/repo.git

# remote information দেখা
git remote show origin

Push - Local থেকে Remote-এ

Shamim এখন ready করেছে তার commits।
এগুলো Local Repository-তে আছে, কিন্তু GitHub-এ এখনো নেই।

এখন সে করবে:
git push origin main

এটা মানে:
"আমার main branch-এর সব commits send করো origin (GitHub) এ।"

এর পর GitHub-এ যেয়ে তার commits দেখা যাবে।

Push করা

# branch push করা
git push origin main

# সব branches push করা
git push origin --all

# tags push করা
git push origin --tags

Pull - Remote থেকে Local-এ

git pull মানে GitHub থেকে নতুন commits নিয়ে আসা।

Team-এ যখন অন্যরা কাজ করছে, তারা তাদের commits push করে। আপনি git pull করে তাদের কাজ নিয়ে আসেন।

git pull origin main

Fetch বনাম Pull

git fetch

Remote থেকে commits এনে রাখে local branch-এ, কিন্তু আপনার current branch merge করে না।

আপনি পর্যালোচনা করতে পারেন পরে।

git pull

Remote থেকে commits এনে সাথে সাথে current branch-এ merge করে।

একটি shortcut: fetch + merge

🔀 অংশ ৯: Clone এবং Basic Commands

Clone - সম্পূর্ণ Repository নিয়ে আসা

Shamim একটি নতুন project-এ join করেছে।

তার টিম লিড তাকে বলল:
"এই GitHub link-টা clone করো এবং শুরু করে দাও।"

Shamim বুঝতে পারল, clone মানে GitHub থেকে পুরো project নিয়ে আসা - history সহ।

সে command লিখল:
git clone https://github.com/team/project.git

এখন তার laptop-এ একটি project folder তৈরি হয়েছে, যাতে সব code, history, branches সবকিছু আছে।

Clone করা

# repository clone করা
git clone https://github.com/username/repo.git

# একটি নির্দিষ্ট branch clone করা
git clone -b branch-name https://github.com/username/repo.git

# shallow clone (শুধু recent history)
git clone --depth 1 https://github.com/username/repo.git

Git এর প্রয়োজনীয় সব কমান্ড

কমান্ড	কাজ
`git init`	নতুন repository তৈরি করা
`git clone`	Repository copy করা
`git status`	বর্তমান অবস্থা দেখা
`git add`	Files staging area-তে রাখা
`git commit`	Snapshot তৈরি করা
`git push`	Local commits GitHub-এ পাঠানো
`git pull`	GitHub থেকে commits নিয়ে আসা
`git log`	Commit history দেখা
`git diff`	পরিবর্তন দেখা

🌿 অংশ ১০: Branch - দলীয় কাজের শিল্প

Branch কেন দরকার

পরিস্থিতি:
Shamim একটা নতুন feature কাজ করছে। একই সময়ে Tamim একটা bug fix করছে। আর একজন documentation update করছে।

যদি সবাই main branch-এ কাজ করে তাহলে সব কিছু গুলিয়ে যাবে।

সমাধান: Branch
প্রতিটি feature এর জন্য একটি আলাদা branch। কাজ শেষ হলে merge করা হয়।

Branch কী?

Branch হলো commit history-র একটি pointer।

এটি commit-এর একটি sequence track করে।

main branch হলো primary branch, যেখানে production-ready code থাকে।

Feature branch-এ আপনি experiment করতে পারেন, কোনো ভয় ছাড়াই। যদি কাজ করে তাহলে main-এ merge করা হয়।

Branch তৈরি এবং Switch করা

# নতুন branch তৈরি করা
git branch feature/login

# branch-এ switch করা
git switch feature/login

# এক লাইনে: তৈরি করা এবং switch করা
git switch -c feature/login

# সব branches দেখা
git branch

# দূরবর্তী branches দেখা
git branch -r

Branch এর নামকরণ Convention

ভাল naming:
feature/user-authentication
bugfix/login-validation
docs/readme-update
refactor/auth-service

খারাপ naming:
branch1
wip
my-changes

Branch এর Lifecycle

main branch (production) ↓ Create feature branch ↓ Work on feature ↓ Make commits ↓ Push branch ↓ Create Pull Request ↓ Code Review ↓ Merge to main ↓ Delete branch

🔗 অংশ ১১: Merge এবং Conflict Resolution

Merge কী?

Shamim এর feature তৈরি শেষ হয়েছে। এখন তার feature/login branch এর সব commits main branch-এ যোগ করতে চায়।br>
এটাকে বলে "merge করা"।

সে switch করবে main-এ, তারপর:
git merge feature/login

এখন feature/login branch-এর সব commits main branch-এ চলে আসবে।

Merge প্রক্রিয়া

# main branch-এ switch করা
git switch main

# feature branch merge করা
git merge feature/login

# Merge এর পরে old branch delete করা
git branch -d feature/login

Merge এর ধরন

Fast-Forward Merge

যখন feature branch এগিয়ে গেছে, কিন্তু main স্থির থেকেছে।

এক্ষেত্রে git শুধু pointer সরিয়ে দেয়।

Three-Way Merge

যখন main এবং feature দুটোই এগিয়ে গেছে।

Git একটি merge commit তৈরি করে।

Merge Conflict

সমস্যা দেখা দিল।

Shamim এবং Tamim দুজনেই একই file-এর একই line edit করেছে।
এখন merge করতে গিয়ে Git সিদ্ধান্ত নিতে পারছে না - কোনটা রাখবে?

Git output দিয়েছে:
CONFLICT (content conflict)

এখন manual resolve করতে হবে।

Conflict Resolution

যখন conflict হয়, file-এ এমন markers আসে:

<<<<<<< HEAD (main branch-এর version)
প্রকৃত content
=======
feature branch-এর version
>>>>>> feature/login

আপনি manually decide করেন কোনটা রাখবেন বা দুটো merge করবেন।

তারপর:
git add resolved-file
git commit -m "Resolve merge conflict"

Conflict এড়ানো

✓ একই file-এর same area একই সাথে edit করবেন না
✓ ঘন ঘন pull করুন যাতে out of sync না হন
✓ feature branches ছোট এবং focused রাখুন
✓ frequently merge করুন main-এ

👥 অংশ ১২: Real Workflow - দলে কাজ করা

একটি সম্পূর্ণ Real-World Workflow

নতুন feature: User Profile Page

Step 1: Ticket পাওয়া
Project Manager Shamim-কে বলল: "User Profile Page তৈরি করো।"

Step 2: Branch তৈরি
Shamim করল:
git switch -c feature/user-profile

Step 3: কাজ শুরু
Shamim profile page-এর HTML, CSS, JavaScript লিখলো।

Step 4: Commits করা
git add .
git commit -m "Add user profile component"
git commit -m "Add profile styling"

Step 5: Push করা
git push origin feature/user-profile

Step 6: Pull Request
GitHub-এ গিয়ে একটি Pull Request খুলল। Team lead দেখতে বলল।

Step 7: Code Review
Team lead: "আচ্ছা, এখানে একটা bug আছে। Error handling নেই।"
Shamim fix করল এবং নতুন commit করল।

Step 8: Approval
"এখন ঠিক আছে। Merge করতে পারো।"

Step 9: Merge
git switch main
git pull origin main
git merge feature/user-profile
git push origin main

Step 10: Cleanup
git branch -d feature/user-profile

Pull Request - কোড রিভিউ এর মাধ্যম

Pull Request (PR) হলো একটি collaboration mechanism।

এটি GitHub-এ থাকে। এটি Git এর নিজস্ব feature নয়।

PR দিয়ে:
• Code review করা যায়
• Discussion করা যায়
• Merge করার আগে CI/CD run করা যায়
• Approval নেওয়া যায়

✍️ অংশ ১৩: Commit Convention - পেশাদার মান

Conventional Commits

ইন্ডাস্ট্রিতে একটি standard আছে: Conventional Commits

Format:
type(scope): subject

Type:
• feat: নতুন feature
• fix: bug fix
• docs: documentation change
• style: formatting, styling
• refactor: code restructure
• test: test addition
• chore: maintenance tasks

উদাহরণ:
feat(auth): add user login functionality
fix(profile): resolve null pointer in display
docs(readme): update installation steps

Atomic Commits

Bad:
একটি বিশাল commit যাতে feature + bug fix + documentation আছে।

Good:
Feature এর জন্য একটি commit
Bug fix এর জন্য আরেকটি commit
Documentation এর জন্য তৃতীয় commit

এর ফলে history পরিষ্কার থাকে। যদি একটা commit revert করতে হয়, শুধু সেটাই revert হয়, অন্যগুলো নয়।

↩️ অংশ ১৪: Undo Operations - সাবধানে!

পাঁচটি পর্যায়ে Undo

যদি ভুল file edit করেছেন (Working Directory-তে):
git restore filename

যদি ভুল stage করেছেন (Staging Area থেকে):
git restore --staged filename

যদি ভুল commit করেছেন এবং locally এটা ঠিক করতে চান:
git reset --soft HEAD~1 (commit undo, changes staging-এ থাকে)
git reset --mixed HEAD~1 (commit undo, changes working-এ থাকে)

যদি ভুল commit remote-এ push করে দিয়েছেন (DANGEROUS):
git revert commit-hash (নতুন commit যা undo করে)

⚠️ বিপদজনক কমান্ড

NEVER: Shared branch-এ git reset --hard করবেন না
NEVER: Shared branch-এ git push --force করবেন না
NEVER: History rewrite করবেন না যেটা অন্যরা already pull করেছে

INSTEAD: git revert ব্যবহার করুন। এটা একটা নতুন commit তৈরি করে যা পুরোনো commit undo করে।

🏢 অংশ ১৫: সম্পূর্ণ Company Workflow

একটি Production-Ready Workflow

Jira Ticket (Feature Request) ↓ Create Feature Branch (git switch -c) ↓ Local Development (edit, commit) ↓ Push Branch (git push origin) ↓ Create Pull Request (code review) ↓ Peer Review + Feedback ↓ Make Changes + New Commits ↓ Automated Tests (CI/CD) ↓ Approval from Team Lead ↓ Merge to main (git merge) ↓ Production Deployment ↓ Monitor and Debug if needed

Branch Strategy: Git Flow

সবচেয়ে popular branch strategy:

• main - Production code (stable)
• develop - Development branch
• feature/* - নতুন feature
• bugfix/* - Bug fixes
• release/* - Release preparation
• hotfix/* - Production bugs

এই strategy বড় projects-এ ব্যবহৃত হয়।

.gitignore - কী Upload করবেন না

# Dependencies
node_modules/
__pycache__/
*.pyc
env/

# Secrets
.env
.env.local
secrets.json

# IDE
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db

# Build output
dist/
build/
*.log

সবচেয়ে গুরুত্বপূর্ণ: Commit করার আগে Check করুন

✓ .env file commit হয়নি?
✓ Debug code বা console.log() আছে?
✓ Merge conflict markers (<<<, >>>) আছে?
✓ Working file আছে যা commit করতে চান না?
✓ Commit message clear এবং descriptive?

📖 অংশ ১৬: Quick Reference এবং সারসংক্ষেপ

Git এর সম্পূর্ণ Mental Model

সবচেয়ে ব্যবহৃত কমান্ড

কমান্ড	উদাহরণ	ব্যবহার
`git status`	`git status`	অবস্থা জানা
`git add`	`git add .` or `git add app.py`	Staging area-তে রাখা
`git commit`	`git commit -m "Add feature"`	Snapshot করা
`git push`	`git push origin main`	GitHub-এ পাঠানো
`git pull`	`git pull origin main`	GitHub থেকে আনা
`git branch`	`git branch feature/new`	Branch তৈরি
`git switch`	`git switch feature/new`	Branch change করা
`git merge`	`git merge feature/new`	Branches একসাথে করা
`git log`	`git log --oneline`	History দেখা
`git clone`	`git clone https://github.com/repo`	Project copy করা

Shamim এর Final Learning

Shamim এখন পুরো picture বুঝে গেছে।

সে জানে:
✓ কেন Version Control দরকার
✓ Git এবং GitHub পার্থক্য
✓ কীভাবে Local Repository কাজ করে
✓ কীভাবে Remote সংযোগ
✓ Branch দিয়ে parallel কাজ
✓ Merge conflict resolve
✓ Production ready workflow

সবচেয়ে গুরুত্বপূর্ণ, সে বুঝে গেছে কেন প্রতিটি ধাপ দরকার।

পরবর্তী পদক্ষেপ

এখন আপনি শুরু করতে পারেন:

১. একটি GitHub account তৈরি করুন
২. একটি repository create করুন
३. Local machine-এ clone করুন
४. নতুন feature branch তৈরি করুন
५. কিছু কোড লিখুন, commit করুন, push করুন
६. Pull request তৈরি করুন
७. পরে সব branches merge করুন

অনুশীলনের মাধ্যমে শিখুন। তত্ত্ব জরুরি, কিন্তু ব্যবহার আরও জরুরি।

Common Mistakes এবং সমাধান

সমস্যা	সমাধান
"কোন file commit হয়নি"	`git add .` দিয়ে সব file stage করুন
"Push করতে পারছি না"	আগে `git pull` করুন
".env file leak হয়েছে"	`git rm --cached .env` করুন (পরে)
"ভুল branch-এ commit করেছি"	`git reset --soft HEAD~1` দিয়ে undo করুন
"Merge conflict সমাধান করতে পারছি"	Manual edit করুন, add করুন, commit করুন

📑 বিষয়বস্তু