Git branching strategy: trunk-based, GitHub Flow ও Git Flow

Branching strategy হলো দলের চুক্তি: কাজ কীভাবে ধারণা থেকে মূল কোডে যাবে, branch কোথায় বানানো হবে, কত দিন থাকবে এবং কীভাবে ফিরবে। একটিমাত্র সেরা উত্তর নেই, তবে ভালো ডিফল্ট আছে। এই লেখা তিনটি প্রচলিত মডেল তুলনা করে এবং একটি ছোট পরীক্ষার repository-র আসল git log --graph আউটপুট দিয়ে দেখায় merge, rebase ও squash merge কী করে। ধরে নেওয়া হচ্ছে আপনি Git-এর গোড়া জানেন (আমাদের Git ও GitHub নতুনদের লেখা দেখুন)।

এক মিনিটে branch-এর গোড়া

Branch হলো commit-এর ওপর সরানো যায় এমন লেবেল। বানানো প্রায় বিনামূল্যে। git switch -c feature/login দিয়ে বানিয়ে সেখানে যান, স্বাভাবিকভাবে commit করুন, তারপর merge করে main-এ ফিরিয়ে আনুন।

Strategy ১: GitHub Flow (সহজ ও জনপ্রিয়)

১. main সবসময় deploy করার মতো। ২. প্রতিটি পরিবর্তনে main থেকে ছোট branch বানান (feature/login, fix/typo)। ৩. pull request খুলে review ও পাস করা test নিন। ৪. main-এ merge করে deploy করুন ও branch মুছুন।

ভালো: ঘন ঘন deploy করা ওয়েব অ্যাপ ও সেবা, ছোট ও মাঝারি দল। দুর্বলতা: একসঙ্গে একাধিক প্রকাশিত সংস্করণ চালানো বর্ণনা করে না।

Strategy ২: Trunk-based development

সবাই main-এ ("trunk") সরাসরি commit করে, বা এমন খুব ছোট branch দিয়ে যা কয়েক ঘণ্টা থেকে এক-দুই দিন বাঁচে। অসমাপ্ত কাজ feature flag-এর (বৈশিষ্ট্য চালু বা বন্ধ করার সেটিং) পেছনে লুকানো থাকে, যাতে ব্যবহারকারীর কাছে দৃশ্যমান না হয়েও নিরাপদে merge করা যায়। এটি শক্তিশালী স্বয়ংক্রিয় test ও দ্রুত CI-র ওপর নির্ভর করে।

ভালো: যে দল দিনে অনেকবার deploy করে ও যাদের ভালো test আছে। কিছু বড় engineering দল এটি ব্যবহার করে। দুর্বলতা: শৃঙ্খলা, test ও feature flag লাগে, যা নতুন দলের এখনো নাও থাকতে পারে।

Strategy ৩: Git Flow (ভারী)

কয়েকটি দীর্ঘস্থায়ী branch ব্যবহার করে: release-এর জন্য main, একীকরণের জন্য develop, সঙ্গে feature/*, release/* ও hotfix/*। কাজ develop-এ merge হয়, একটি release branch কেটে স্থিতিশীল করা হয়, তারপর main-এ merge করে tag দেওয়া হয়।

ভালো: নির্ধারিত release ও একাধিক সমর্থিত সংস্করণের পণ্য, যেমন desktop software, mobile অ্যাপ বা library। দুর্বলতা: বেশি branch, বেশি merge ও ধীর feedback। এর আদি লেখক পরে বলেছেন যে এটি ক্রমাগত delivery-র ওয়েব অ্যাপের জন্য আদর্শ নয়।

তুলনা

	GitHub Flow	Trunk-based	Git Flow
দীর্ঘস্থায়ী branch	শুধু main	শুধু main	main + develop
Branch-এর আয়ু	কয়েক দিন	ঘণ্টা থেকে ১-২ দিন	দিন থেকে সপ্তাহ
Feature flag লাগে	কখনো কখনো	সাধারণত	কদাচিৎ
Release-এর ধরন	main থেকে deploy	main থেকে deploy	পরিকল্পিত release
জটিলতা	কম	কম, কিন্তু শক্ত test লাগে	বেশি

বেশিরভাগ ছোট দলের যুক্তিসংগত ডিফল্ট: GitHub Flow, branch ছোট রেখে। test ও deploy উন্নত হলে trunk-based-এর দিকে যান। সত্যিই সংস্করণ-ভিত্তিক release পাঠালেই Git Flow ব্যবহার করুন।

Merge, rebase ও squash: ইতিহাসের কী হয়

তিনটিই branch-এর কাজ main-এ আনে। আমি প্রতিটি একটি পরীক্ষার repository-তে চালিয়েছি যেখানে feature branch বানানোর সময় main এগিয়ে গিয়েছিল।

Merge commit (git merge --no-ff)

*   f8aadb2 Merge feature/login
|\
| * e8beb18 Add login form
* | c9c29a9 Fix typo on home page
|/
* b508c31 Start the app

ইতিহাস যেমন ঘটেছিল ঠিক তেমন সংরক্ষিত, দুই রেখা জোড়া একটি merge commit সহ। এটি নিরাপদ, কখনো commit নতুন করে লেখে না। বড় প্রজেক্টে গ্রাফ জটিল হতে পারে।

Rebase, তারপর fast-forward

* d4ab35e Add login form
* 903c05e Fix typo on home page
* b508c31 Start the app

git rebase main আপনার branch-এর commit-গুলো সর্বশেষ main-এর ওপর আবার চালায়, ফলে নতুন commit id হয়, তারপর git merge --ff-only main-কে সোজা রেখায় এগিয়ে নেয়। ইতিহাস পরিষ্কার ও রৈখিক। খরচ: rebase commit নতুন করে লেখে।

সোনালি নিয়ম: অন্যরা যে commit ব্যবহার করছে (shared branch বা main) তা কখনো rebase করবেন না। শুধু নিজের স্থানীয় বা ব্যক্তিগত branch rebase করুন। আগে push করা rebase-করা branch আবার push করতে হলে git push --force-with-lease ব্যবহার করুন, যা না-দেখা কাজ overwrite করতে অস্বীকার করে।

Squash merge

9cfe613 Add profile page
d4ab35e Add login form
903c05e Fix typo on home page
b508c31 Start the app

git merge --squash দুটি "wip" commit-কে main-এ একটি পরিষ্কার commit "Add profile page"-এ বদলাল। পরিপাটি ইতিহাস ও পুরো feature সহজে revert করার জন্য দারুণ। খরচ: branch-এর আলাদা commit main-এ থাকে না, এবং পরে branch মুছতে হয় (Git জানে না এটি merge হয়েছে)।

GitHub-এ pull request-এর merge বোতামে এই তিনটির একটি বেছে নেওয়া যায়। দল একটি বেছে তাতে লেগে থাকে।

যে strategy-ই নিন, ভালো অভ্যাস

• Branch ছোট ও সংক্ষিপ্ত রাখুন। দীর্ঘস্থায়ী branch যন্ত্রণাদায়ক conflict আনে। main আপনার branch-এ ঘন ঘন merge (বা rebase) করুন।
• Branch-এর নাম স্পষ্ট দিন: feature/login, fix/null-error, docs/readme, চাইলে ticket নম্বরসহ।
• main সুরক্ষিত রাখুন: pull request, review ও পাস করা check বাধ্যতামূলক করুন, এবং force-push আটকান (GitHub branch protection)।
• অর্থপূর্ণ commit বার্তা লিখুন: আদেশসূচক ছোট সারাংশ লাইন দিয়ে শুরু করুন ("Add login form")।
• Merge হওয়া branch মুছুন জঞ্জাল এড়াতে।
• Release tag দিন (git tag v1.2.0) যাতে ঠিক কী পাঠানো হয়েছে খুঁজে পান।
• Secret commit করবেন না। ফাইল মুছলেও ফাঁস হওয়া key ইতিহাসে থেকে যায়।
• Conflict শান্তভাবে মেটান: দুই সংস্করণ পড়ুন, সঠিকটি রাখুন, test চালান, তারপর commit করুন।

Hotfix: production দ্রুত ঠিক করা

GitHub Flow বা trunk-based-এ hotfix শুধু main থেকে সাধারণ ছোট branch, দ্রুত review ও deploy করা। Git Flow-তে main থেকে hotfix/* কেটে main ও develop দুটিতেই merge করা হয়। যা-ই বেছে নিন, রাত ২টায় দরকার পড়ার আগেই hotfix-এর পদ্ধতি লিখে রাখুন।

কীভাবে বাছবেন

১. ক্রমাগত deploy করেন (ওয়েব অ্যাপ, একটি চালু সংস্করণ)? GitHub Flow বা trunk-based নিন। ২. একাধিক প্রকাশিত সংস্করণ সমর্থন বা নির্ধারিত সময়ে পাঠান? Git Flow বা release branch ভাবুন। ৩. দল Git-এ নতুন? GitHub Flow দিয়ে শুরু করুন, main সুরক্ষিত রাখুন এবং pull request ছোট রাখুন।

মূল কথা: আপনার release-এর ধরনে মানায় এমন সবচেয়ে সহজ strategy বাছুন, branch ছোট রাখুন, main সুরক্ষিত রাখুন, এবং পুরো দলের জন্য একটি merge-শৈলী ঠিক করুন। শুধু নিজের branch rebase করুন, আর shared ইতিহাস কখনো নতুন করে লিখবেন না।

---

Linux ও DevOps সিরিজ, পর্ব ৩ (প্রতিদিনের পরিচালনা): 4 নম্বর (মোট 5)। আগের লেখা: Bash scripting-এর গোড়া: চমকে না দেওয়া নিরাপদ script লিখুন.