মোবাইল ডেভেলপমেন্টে Git এবং সংস্করণ নিয়ন্ত্রণ: এটি কী, মৌলিক কমান্ড এবং এটি কীভাবে কাজ করে

সংস্করণ নিয়ন্ত্রণ এবং Git: এটি কী?

Git হল একটি বিতরণকৃত সংস্করণ নিয়ন্ত্রণ ব্যবস্থা (VCS) যা লিনাস টরভাল্ডস 2005 সালে লিনাক্স কার্নেল ডেভেলপমেন্টের জন্য তৈরি করেছিলেন। কেন্দ্রীভূত সিস্টেমের (SVN, CVS) বিপরীতে, Git প্রতিটি ডেভেলপারের কম্পিউটারে প্রকল্পের ইতিহাসের একটি সম্পূর্ণ অনুলিপি সংরক্ষণ করে। এর মানে হল যে আপনি ইন্টারনেট সংযোগ ছাড়াই কমিট করতে পারেন, ইতিহাস ব্রাউজ করতে পারেন এবং শাখা তৈরি করতে পারেন।

Git স্ন্যাপশট নিয়ে কাজ করে — প্রতিটি কমিট সংরক্ষণের সময় সমস্ত প্রকল্প ফাইলের অবস্থা সংরক্ষণ করে। যদি একটি ফাইল পরিবর্তন না হয়, Git পূর্ববর্তী সংস্করণের একটি রেফারেন্স তৈরি করে, স্থান বাঁচায়। GitHub বিশ্লেষণ (2025) অনুসারে, গড় রিপোজিটরিতে 1,200টি কমিট এবং 15টি শাখা থাকে।

IT Sectr-এ, আমরা 2017 সাল থেকে সমস্ত প্রকল্পে Git ব্যবহার করছি। আমাদের অভিজ্ঞতা দেখায় যে প্রথম দিন থেকে সঠিক Git কনফিগারেশন টিমকে মার্জ এবং দ্বন্দ্ব সমাধানে 30% পর্যন্ত সময় বাঁচায়। Git ডি-ফ্যাক্টো মানদণ্ডে পরিণত হয়েছে — এটি সমস্ত আধুনিক IDE (Android Studio, Xcode, VS Code) এবং CI/CD সিস্টেম দ্বারা সমর্থিত।

# মৌলিক Git সেটআপ
git config --global user.name "আপনার নাম"
git config --global user.email "your@email.com"

# নতুন রিপোজিটরি তৈরি
git init my-project
cd my-project

# ফাইল যোগ করা এবং কমিট করা
git add README.md
git commit -m "Initial commit"

# দূরবর্তী রিপোজিটরির সাথে কাজ করা
git remote add origin https://github.com/user/my-project.git
git push -u origin main

উপরের কোডটি মৌলিক ক্রম দেখায়: রিপোজিটরি আরম্ভ করা, প্রথম কমিট এবং দূরবর্তী সার্ভারে প্রকাশনা। git init কমান্ডটি একটি লুকানো .git ফোল্ডার তৈরি করে যা সম্পূর্ণ প্রকল্প ইতিহাস সংরক্ষণ করবে। প্রতিটি git commit একটি পুনরুদ্ধার পয়েন্ট তৈরি করে যেখানে আপনি যেকোনো সময় ফিরে যেতে পারেন।

মৌলিক ধারণা: Repository, Branch, Commit

তিনটি মৌলিক ধারণা — Repository, Branch এবং Commit — বোঝা যেকোনো সংস্করণ নিয়ন্ত্রণ ব্যবস্থার সাথে কাজ করার জন্য অপরিহার্য। রিপোজিটরি হল পুরো প্রকল্পের জন্য একটি পাত্র। Commit হল ফাইলের সংরক্ষিত অবস্থা। Branch হল উন্নয়নের একটি পৃথক লাইন।

Repository (রিপোজিটরি) স্থানীয় (আপনার কম্পিউটারে) বা দূরবর্তী (GitHub, GitLab সার্ভারে) হতে পারে। প্রতিটি ডেভেলপার দূরবর্তী রিপোজিটরি তাদের মেশিনে ক্লোন করে এবং স্থানীয় কপি নিয়ে কাজ করে। পরিবর্তনগুলি push (পাঠানো) এবং pull (আনা) এর মাধ্যমে সিঙ্ক্রোনাইজ করা হয়। বিতরণকৃত সংস্করণ নিয়ন্ত্রণে, প্রতিটি ডেভেলপার ইতিহাসের একটি সম্পূর্ণ অনুলিপি সংরক্ষণ করে।

Branch (শাখা) হল একটি কমিটের দিকে নির্দেশক। শাখাগুলি সমান্তরাল উন্নয়নের অনুমতি দেয়: একজন ডেভেলপার নতুন বৈশিষ্ট্যে কাজ করে (feature branch), অন্যজন বাগ ঠিক করে (hotfix branch), তৃতীয়জন রিলিজ প্রস্তুত করে (release branch)। GitLab Flow (2025) অনুসারে, গড় প্রকল্পে একসাথে 3–5টি সক্রিয় শাখা থাকে।

Commit (কমিট) হল পরিবর্তনের একটি একক। প্রতিটি কমিটে একটি অনন্য হ্যাশ (SHA-1), বার্তা, লেখক এবং সময় স্ট্যাম্প থাকে। ভালো অভ্যাস হল বর্ণনামূলক বার্তা সহ ছোট অর্থপূর্ণ কমিট করা — এটি কোড রিভিউ এবং পরিবর্তন প্রত্যাবর্তনকে সহজ করে। কমিটের মাধ্যমে সংস্করণ নিয়ন্ত্রণ আপনাকে সম্পূর্ণ প্রকল্প ইতিহাস দেয়।

Feature Branch

Feature Branch (বৈশিষ্ট্য শাখা) হল একটি অস্থায়ী শাখা যা একটি নির্দিষ্ট কাজের উন্নয়নের জন্য develop বা main থেকে তৈরি করা হয়। কাজ শেষ হওয়ার পর, শাখাটি Pull Request-এর মাধ্যমে ফিরিয়ে আনা হয় এবং মুছে ফেলা হয়। এই অভ্যাসটি মূল কোডবেসের স্থিতিশীলতা ব্যাহত না করে পরিবর্তনগুলিকে আলাদা করার অনুমতি দেয়।

সাধারণ ওয়ার্কফ্লো: শাখা তৈরি করুন feature/add-login → কয়েকটি কমিট করুন → Pull Request তৈরি করুন → কোড রিভিউ করুন → develop-এ মার্জ করুন। IT Sectr-এ আমরা ঠিক এই পদ্ধতি ব্যবহার করি: প্রতিটি Jira টাস্ক একটি পৃথক feature শাখার সাথে মিলে যায়। এটি পরিবর্তন ট্র্যাকিং এবং প্রয়োজনে প্রত্যাবর্তনকে সহজ করে।

Rebase বনাম Merge

Merge একটি মার্জ কমিট তৈরি করে যা দুটি শাখাকে একত্রিত করে। এটি সমান্তরাল উন্নয়ন লাইন সহ সম্পূর্ণ ইতিহাস সংরক্ষণ করে। Rebase ইতিহাস পুনর্লিখন করে: এটি একটি শাখা থেকে কমিট নেয় এবং অন্যটির উপরে "পুনরায় প্রয়োগ" করে, একটি রৈখিক ইতিহাস তৈরি করে।

Merge পাবলিক শাখা এবং বড় টিমের জন্য বেশি উপযুক্ত যেখানে কালানুক্রম গুরুত্বপূর্ণ। Rebase PR তৈরি করার আগে ব্যক্তিগত বৈশিষ্ট্য শাখার জন্য সুবিধাজনক — এটি ইতিহাসকে পরিষ্কার এবং আরও বোধগম্য করে তোলে। তবে, rebase কখনই সেই শাখাগুলিতে প্রয়োগ করা উচিত নয় যেখানে অন্য ডেভেলপাররা কাজ করছে, কারণ এটি ইতিহাস পুনর্লিখন করে।

# একটি ফিচার শাখা তৈরি এবং স্যুইচ করা
git checkout -b feature/add-login main

# শাখায় কাজ করা
git add login-screen/
git commit -m "Add login screen layout"

# PR-এর আগে সাম্প্রতিক main-এ Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# দূরবর্তী রিপোজিটরিতে Push
git push origin feature/add-login

এই উদাহরণটি একটি সাধারণ ওয়ার্কফ্লো দেখায়: main থেকে ফিচার শাখা তৈরি, কয়েকটি কমিট এবং রিভিউতে পাঠানোর আগে পরিষ্কার রৈখিক ইতিহাস পেতে rebase। এই পদ্ধতি মার্জ দ্বন্দ্ব কমিয়ে দেয়।

Git Flow বনাম Trunk-Based Development

Git Flow এবং Trunk-Based Development হল দুটি প্রধান সংস্করণ নিয়ন্ত্রণ কৌশল যা নির্ধারণ করে কিভাবে একটি টিম Git-এর সাথে কাজ সংগঠিত করে। পছন্দ টিমের আকার, রিলিজ ফ্রিকোয়েন্সি এবং স্থিতিশীলতার প্রয়োজনীয়তার উপর নির্ভর করে।

Git Flow হল একাধিক স্থায়ী শাখা সহ একটি কঠোর মডেল: main (রিলিজ কোড), develop (বর্তমান উন্নয়ন), feature/* (নতুন বৈশিষ্ট্য), release/* (রিলিজ প্রস্তুতি) এবং hotfix/* (জরুরি ফিক্স)। এই মডেলটি স্পষ্ট রিলিজ চক্র সহ প্রকল্পের জন্য ভাল (যেমন, সংস্করণ 1.0, 2.0 সহ মোবাইল অ্যাপ)।

Trunk-Based Development হল একটি একক প্রধান শাখা (trunk/main) সহ পদ্ধতি যেখানে সমস্ত ডেভেলপার দিনে কয়েকবার পরিবর্তন মার্জ করে। অসম্পূর্ণ বৈশিষ্ট্য লুকানোর জন্য ফিচার ফ্ল্যাগ ব্যবহার করা হয়। এই পদ্ধতি ওয়েব ডেভেলপমেন্ট এবং স্টার্টআপে জনপ্রিয় যেখানে ডেলিভারির গতি গুরুত্বপূর্ণ।

Git Flow

Git Flow, যা ভিনসেন্ট ড্রিসেন 2010 সালে প্রস্তাব করেছিলেন, সবচেয়ে জনপ্রিয় মডেলগুলির মধ্যে একটি। এর প্রধান সুবিধা হল জীবনচক্র পর্যায় অনুসারে কোডের কঠোর পৃথকীকরণ। main শাখায় শুধুমাত্র রিলিজ কোড থাকে, develop-এ বর্তমান উন্নয়ন থাকে এবং ফিচার শাখাগুলি নতুন বৈশিষ্ট্যগুলিকে একে অপরের থেকে আলাদা করে।

Hotfix শাখাগুলি জরুরি ফিক্সের জন্য main থেকে তৈরি করা হয় এবং মার্জ করার পর main এবং develop উভয়েই ফিরিয়ে আনা হয়। Release শাখাগুলি develop থেকে তৈরি করা হয় যখন টিম রিলিজের জন্য প্রস্তুত হয়। এগুলিতে শুধুমাত্র বাগ ফিক্স এবং মেটাডেটা (সংস্করণ, বিল্ড) যোগ করা হয়। রিলিজের পর, release শাখাটি main এবং develop-এ মার্জ করা হয়। JetBrains জরিপ (2024) অনুসারে, 37% টিম Git Flow ব্যবহার করে। এই সংস্করণ নিয়ন্ত্রণ মডেল নির্দিষ্ট রিলিজ সহ প্রকল্পের জন্য মানদণ্ড হিসাবে রয়ে গেছে।

# Git Flow উদাহরণ: রিলিজে কাজ শুরু
git checkout -b release/1.2.0 develop

# release শাখায় বাগ ফিক্স করা
git commit -m "Fix login button crash"

# রিলিজ সম্পূর্ণ করা — main এবং develop-এ মার্জ
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release শাখা মুছে ফেলা
git branch -d release/1.2.0

কোডটি release শাখা তৈরি, স্থিতিশীলকরণ এবং প্রধান শাখাগুলিতে মার্জ করার চিত্র তুলে ধরে। --no-ff ফ্ল্যাগ একটি মার্জ কমিট নিশ্চিত করে, তথ্য সংরক্ষণ করে যে পরিবর্তনগুলি release শাখা থেকে এসেছে।

Pull Request এবং কোড রিভিউ

Pull Request (PR) হল একটি প্রক্রিয়া যার মাধ্যমে একজন ডেভেলপার তার শাখা থেকে প্রধান শাখায় পরিবর্তন প্রস্তাব করে। PR টিম ওয়ার্কে সংস্করণ নিয়ন্ত্রণের একটি মূল উপাদান — এটি শুধু কোড মার্জ করার উপায় নয়, বরং আলোচনা, রিভিউ এবং মান পরীক্ষার একটি প্রক্রিয়া। GitLab-এ, অনুরূপ প্রক্রিয়াটিকে Merge Request (MR) বলা হয়, কিন্তু সারমর্ম একই: টিমকে পরিবর্তন সম্পর্কে জানানো এবং অনুমোদন পাওয়া।

একটি ভাল PR ছোট (300 লাইন কোড পর্যন্ত), একটি একক কাজের উপর কেন্দ্রীভূত এবং কী করা হয়েছে এবং কেন করা হয়েছে তার বিবরণ থাকা উচিত। Google গবেষণা (2025) অনুসারে, 400 লাইনের বেশি PR রিভিউ করতে দ্বিগুণ সময় লাগে এবং বাগ শনাক্ত করার সম্ভাবনা 30% কমে যায়। কোড রিভিউ (Code Review) হল মার্জ করার আগে অন্য ডেভেলপার দ্বারা কোড পরীক্ষা করা।

IT Sectr-এ, আমরা প্রতিটি PR-এর জন্য বাধ্যতামূলক কোড রিভিউ অনুশীলন করি। এটি শুধু কোডের মান উন্নত করে না বরং টিমের মধ্যে জ্ঞান ছড়িয়ে দিতেও সাহায্য করে। কোড রিভিউ পরীক্ষা করে: কোড কি আর্কিটেকচার নীতি অনুসরণ করে, বাগ আছে কিনা, যথেষ্ট পরীক্ষা আছে কিনা, ভেরিয়েবল সঠিকভাবে নামকরণ করা হয়েছে কিনা। সমস্ত মন্তব্য মার্জ না হওয়া পর্যন্ত PR-এ আলোচনা করা হয়।

প্ল্যাটফর্ম: GitHub, GitLab, Bitbucket

Git একটি প্রোটোকল, কিন্তু সহযোগিতার জন্য একটি সংস্করণ নিয়ন্ত্রণ প্ল্যাটফর্ম প্রয়োজন যা ওয়েব ইন্টারফেস, অ্যাক্সেস ব্যবস্থাপনা, CI/CD এবং রিভিউ টুল সরবরাহ করে। বাজারে তিনটি প্ল্যাটফর্ম প্রভাবশালী: GitHub, GitLab এবং Bitbucket।

GitHub হল সবচেয়ে বড় প্ল্যাটফর্ম যা 56 মিলিয়নেরও বেশি ডেভেলপার নিয়ে। Microsoft-এর মালিকানাধীন, এটি Actions (CI/CD), Pages (হোস্টিং), Discussions এবং Copilot অফার করে। বিনামূল্যের পরিকল্পনায় 3 জন পর্যন্ত টিমের জন্য সীমাহীন প্রাইভেট রিপোজিটরি অন্তর্ভুক্ত। GitHub ওপেন-সোর্স সম্প্রদায়ে জনপ্রিয়।

GitLab হল একটি সম্পূর্ণ DevOps প্ল্যাটফর্ম যা সমন্বিত CI/CD, কন্টেইনার রেজিস্ট্রি এবং অবকাঠামো ব্যবস্থাপনা সহ। GitHub-এর বিপরীতে, GitLab আপনার নিজের সার্ভারে (Self-Managed) ইনস্টল করা যেতে পারে। Atlassian-এর Bitbucket Jira এবং Confluence-এর সাথে দৃঢ়ভাবে সংহত, যা এটিকে টিমের জন্য পছন্দ করে তোলে যারা ইতিমধ্যেই Atlassian ইকোসিস্টেম ব্যবহার করছে।