Git-এ Release Branch — এটি কী, উদ্দেশ্য এবং কাজের পদ্ধতি

Git-এ Release Branch কী

Release Branch (রিলিজ ব্রাঞ্চ) হল Git Flow-এ একটি অস্থায়ী ব্রাঞ্চ, যা develop থেকে তৈরি করা হয় যখন টিম সিদ্ধান্ত নেয় যে ফিচারগুলির বর্তমান সেট রিলিজের জন্য প্রস্তুত। এটি ঠিক ততক্ষণ বিদ্যমান থাকে যতক্ষণ চূড়ান্ত রিলিজ প্রস্তুতি নেয় — কয়েক ঘন্টা থেকে কয়েক দিন পর্যন্ত।

রিলিজ ব্রাঞ্চের মূল উদ্দেশ্য হল পরবর্তী ভার্সনগুলির উন্নয়ন না থামিয়ে রিলিজের জন্য ফিচারগুলির একটি নির্দিষ্ট সেট ফ্রিজ করা। যখন রিলিজ ব্রাঞ্চ ডিপ্লয়মেন্টের জন্য প্রস্তুত করা হচ্ছে, অন্যান্য ডেভেলপাররা পরবর্তী রিলিজের জন্য develop-এ ফিচার ব্রাঞ্চ মার্জ করা চালিয়ে যেতে পারেন।

রিলিজ ব্রাঞ্চে কোনও নতুন ফিচার তৈরি করা হয় না — শুধুমাত্র বাগ ফিক্স, অ্যাপ ভার্সন আপডেট, লোকালাইজেশন এবং ডকুমেন্টেশন। সমস্ত কাজ শেষ হওয়ার পর, রিলিজ ব্রাঞ্চ main-এ (রিলিজ হিসাবে চিহ্নিত) এবং develop-এ (যাতে বাগফিক্স ভবিষ্যতের ভার্সনে পৌঁছায়) মার্জ করা হয়।

Atlassian, 2024-এর মতে, নিয়মিত রিলিজ চক্রের প্রকল্পগুলির জন্য রিলিজ ব্রাঞ্চ অত্যন্ত গুরুত্বপূর্ণ — এগুলি রিলিজ প্রক্রিয়ার পূর্বাভাসযোগ্যতা এবং স্থিতিশীলতা নিশ্চিত করে।

রিলিজ ব্রাঞ্চের জীবনচক্র

রিলিজ ব্রাঞ্চের জীবনচক্র তৈরি থেকে মুছে ফেলা পর্যন্ত বেশ কয়েকটি ধাপ অন্তর্ভুক্ত করে। প্রতিটি ধাপ বোঝা টিমকে কর্ম সমন্বয় করতে এবং ভুল এড়াতে সাহায্য করে।

1. তৈরি — develop-এর শেষ commit থেকে release/2.5.0 নামে একটি ব্রাঞ্চ তৈরি করা হয়। develop পরবর্তী ভার্সনের জন্য ফিচার ব্রাঞ্চ গ্রহণ করতে থাকে।
2. প্রস্তুতি — রিলিজ ব্রাঞ্চে build.gradle, Info.plist এবং অন্যান্য কনফিগারেশন ফাইলে অ্যাপ ভার্সন আপডেট করা হয়।
3. বাগফিক্সিং — চূড়ান্ত পরীক্ষার সময় পাওয়া গুরুতর ত্রুটিগুলি ঠিক করা হয়। শুধুমাত্র বাগ — কোনও নতুন ফিচার নয়।
4. চূড়ান্ত পরীক্ষা — QA টিম রিলিজ ব্রাঞ্চে রিগ্রেশন পরীক্ষা করে। নতুন বাগ একই ব্রাঞ্চে সংশোধনের জন্য পাঠানো হয়।
5. main-এ মার্জ — রিলিজ ব্রাঞ্চ --no-ff ফ্ল্যাগ সহ main-এ মার্জ করা হয়। রিলিজ ট্যাগ তৈরি হয়: v2.5.0।
6. develop-এ মার্জ — রিলিজ ব্রাঞ্চ develop-এ ফিরিয়ে আনা হয় যাতে রিলিজের বাগফিক্স বর্তমান উন্নয়নে পৌঁছায়।
7. মুছে ফেলা — রিলিজ ব্রাঞ্চ স্থানীয় এবং দূরবর্তীভাবে মুছে ফেলা হয়, কারণ এর কাজ শেষ।

ধাপ ৬ — develop-এ ফিরতি মার্জ — প্রায়ই ভুলে যাওয়া হয়, কিন্তু এটি অত্যন্ত গুরুত্বপূর্ণ। এটি ছাড়া, রিলিজে করা বাগফিক্স develop-এ পৌঁছাবে না, এবং পরবর্তী রিলিজে একই ত্রুটিগুলি আবার দেখা দিতে পারে।

রিলিজ ব্রাঞ্চ ধাপগুলির সাধারণ সময়কাল

রিলিজ ব্রাঞ্চের জীবনকাল রিলিজের জটিলতা এবং develop-এ কোডের গুণমানের উপর নির্ভর করে। গড়ে, একটি মাঝারি আকারের মোবাইল অ্যাপ্লিকেশনের জন্য প্রস্তুতিতে ২ থেকে ৫ কার্যদিবস লাগে।

রিলিজ ব্রাঞ্চে কী করা হয়

রিলিজ ব্রাঞ্চে কঠোরভাবে সীমিত কাজের সেট সম্পাদিত হয়। এই তালিকা থেকে কোনও বিচ্যুতি Git Flow মডেল লঙ্ঘন করে এবং রিলিজ স্থিতিশীলতার জন্য ঝুঁকি তৈরি করে।

নতুন ফিচার নিষিদ্ধ নিয়মটি রিলিজ ব্রাঞ্চে সবচেয়ে গুরুত্বপূর্ণ। যদি কোনও ফিচার রিলিজের জন্য সময়মতো না তৈরি হয়, তবে এটি পরবর্তী চক্রের জন্য অপেক্ষা করে। রিলিজ ব্রাঞ্চে অসম্পূর্ণ ফিচার ঠেলে দেওয়ার চেষ্টা সময়সীমা মিস এবং প্রোডাকশনে বাগের প্রধান কারণ।

মোবাইল প্রকল্পে ভার্সন আপডেট

রিলিজ ব্রাঞ্চে অ্যাপ্লিকেশন ভার্সন নম্বর বাধ্যতামূলকভাবে আপডেট করা হয়। Android-এর জন্য, এগুলি হল build.gradle-এ versionCode এবং versionName ফিল্ড; iOS-এর জন্য — Info.plist-এ CFBundleShortVersionString।

// build.gradle (অ্যাপ-লেভেল) — রিলিজ ব্রাঞ্চে ভার্সন আপডেট
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS-এর জন্য — Info.plist আপডেট
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release এবং hotfix-এর পার্থক্য

নতুন ডেভেলপাররা প্রায়ই release এবং hotfix ব্রাঞ্চকে গুলিয়ে ফেলেন, যদিও তাদের উদ্দেশ্য মৌলিকভাবে আলাদা। ভুল ব্রাঞ্চ ধরন নির্বাচন করা একটি গুরুতর সংশোধন বিলম্বিত করতে পারে বা রিলিজ প্রক্রিয়া ব্যাহত করতে পারে।

• উৎস — release develop থেকে তৈরি হয়, hotfix main থেকে। এটি প্রধান পার্থক্য যা বাকি সবকিছু নির্ধারণ করে।
• জরুরীতা — release পরিকল্পিত: টিম সিদ্ধান্ত নেয় কখন প্রস্তুতি শুরু করবে। Hotfix জরুরি: প্রোডাকশনে সমস্যার তাত্ক্ষণিক সংশোধন প্রয়োজন।
• সামগ্রী — release একাধিক সংশোধন এবং ভার্সন আপডেট অন্তর্ভুক্ত করতে পারে। Hotfix শুধুমাত্র একটি গুরুতর সংশোধন ধারণ করে।
• মার্জ — release main এবং develop-এ মার্জ হয়। Hotfix-ও main এবং develop-এ মার্জ হয়, তবে অগ্রাধিকার সহ।
• জীবনকাল — release ১ থেকে ৭ দিন বেঁচে থাকে। Hotfix ৩০ মিনিট থেকে ১ দিন বেঁচে থাকে।

যদি রিলিজ প্রস্তুতির সময় (রিলিজ ব্রাঞ্চে) বাগ পাওয়া যায় — এটি সাধারণ বাগফিক্স। যদি প্রোডাকশনে (main-এ) বাগ পাওয়া যায় — এটি hotfix, এবং এটি main থেকে তৈরি হয়, এমনকি যদি রিলিজ ব্রাঞ্চ ইতিমধ্যে বিদ্যমান থাকে।

রিলিজ ব্রাঞ্চ নামকরণের নিয়ম

একীভূত রিলিজ ব্রাঞ্চ নামকরণ মান রিপোজিটরি নেভিগেশন সহজ করে এবং CI/CD সিস্টেমকে স্বয়ংক্রিয়ভাবে সনাক্ত করতে দেয় যে একটি ব্রাঞ্চ রিলিজ প্রক্রিয়ার সাথে সম্পর্কিত।

• release/X.Y.Z — স্ট্যান্ডার্ড Git Flow ফরম্যাট, যেখানে X.Y.Z রিলিজ ভার্সন। উদাহরণ: release/2.5.0।
• release/নাম — রিলিজ কোডনেম সহ বিকল্প ফরম্যাট। উদাহরণ: release/merlin।
• release/তারিখ — রিলিজ তারিখ সহ ফরম্যাট। খুব কমই ব্যবহৃত হয়, কারণ ভার্সন তারিখের চেয়ে বেশি গুরুত্বপূর্ণ। উদাহরণ: release/2024-12-01।

release/X.Y.Z ফরম্যাটটি পছন্দের, কারণ এটি ব্রাঞ্চকে সরাসরি ভার্সন নম্বরের সাথে সংযুক্ত করে যা রিলিজকে বরাদ্দ করা হবে। এটি CI/CD স্ক্রিপ্ট দ্বারা অনুসন্ধান এবং স্বয়ংক্রিয় প্রক্রিয়াকরণ সহজ করে।

develop-এ ফিরতি মার্জের কৌশল

রিলিজ ব্রাঞ্চের develop-এ ফিরতি মার্জ (merge back) সবচেয়ে গুরুত্বপূর্ণ এবং একইসাথে সবচেয়ে বেশি উপেক্ষিত অপারেশনগুলির মধ্যে একটি। এটি ছাড়া, রিলিজে করা সমস্ত বাগফিক্স শুধুমাত্র রিলিজ ভার্সনে থেকে যায় এবং পরবর্তী রিলিজ চক্রে পৌঁছায় না।

ফিরতি মার্জ প্রক্রিয়া রিলিজ ব্রাঞ্চ main-এ মার্জ হওয়ার পরে সম্পাদিত হয়। প্রথমে release develop-এ মার্জ করা হয়, তারপর মুছে ফেলা হয়। এটি নিশ্চিত করে যে develop-এ রিলিজ প্রস্তুতির সময় করা সমস্ত সংশোধন অন্তর্ভুক্ত রয়েছে।

ফিরতি মার্জের পরে দ্বন্দ্ব সম্ভব — বিশেষত যদি develop-এ ইতিমধ্যে নতুন ফিচার ব্রাঞ্চ দেখা দেয় যা একই ফাইলগুলি পরিবর্তন করেছিল। রিলিজের জন্য দায়ী ডেভেলপার এই দ্বন্দ্বগুলি সমাধান করে এবং develop সার্ভারে push করে।

কিছু টিম ইতিহাস রৈখিক রাখতে মার্জের পরিবর্তে ফিরতি মার্জের জন্য rebase ব্যবহার করে। তবে, develop-এর জন্য মার্জ নিরাপদ, কারণ এটি কমিট ইতিহাস পুনর্লিখন করে না যা ইতিমধ্যে অন্যান্য ডেভেলপারদের দ্বারা ব্যবহৃত হচ্ছে।

রিলিজ নিয়ে কাজ করার কমান্ড উদাহরণ

আসুন মোবাইল অ্যাপ্লিকেশন ভার্সন 2.5.0-এর সফল রিলিজের পরে রিলিজ ব্রাঞ্চের সাথে কাজ করার সম্পূর্ণ চক্র দেখি: তৈরি থেকে মুছে ফেলা পর্যন্ত।

# 1. develop থেকে রিলিজ ব্রাঞ্চ তৈরি করুন
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. ভার্সন এবং বাগফিক্স আপডেট করুন
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. বাগ ঠিক করুন (শুধুমাত্র bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. রিলিজ ব্রাঞ্চ সার্ভারে পাঠান
git push origin release/2.5.0

# 5. release main-এ মার্জ করুন
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. develop-এ ফিরতি মার্জ করুন
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. রিলিজ ব্রাঞ্চ মুছুন
git branch -d release/2.5.0
git push origin --delete release/2.5.0

কমান্ড ৫ এবং ৬ — ডাবল মার্জ — অত্যন্ত গুরুত্বপূর্ণ। প্রথমে main রিলিজ কোড এবং ট্যাগ পায়, তারপর develop রিলিজের বাগফিক্সের সাথে সিঙ্ক্রোনাইজ হয়। যদি ধাপ ৬ বাদ দেওয়া হয়, রিলিজের সংশোধনগুলি পরবর্তী উন্নয়ন চক্রে পৌঁছাবে না।

রিলিজ প্রক্রিয়া স্বয়ংক্রিয়করণ

নিয়মিত রিলিজযুক্ত মোবাইল প্রকল্পগুলির জন্য, রিলিজ ব্রাঞ্চ তৈরি এবং ভার্সন আপডেটের প্রক্রিয়া CI/CD স্ক্রিপ্টের মাধ্যমে স্বয়ংক্রিয় করা যেতে পারে। GitHub Actions একটি ওয়ার্কফ্লো তৈরি করতে দেয় যা বাটন চাপলে স্বয়ংক্রিয় ভার্সন আপডেট সহ রিলিজ ব্রাঞ্চ তৈরি করে।

নিয়মিত রিলিজযুক্ত মোবাইল প্রকল্পগুলির জন্য, রিলিজ ব্রাঞ্চ তৈরি এবং ভার্সন আপডেটের প্রক্রিয়া CI/CD স্ক্রিপ্টের মাধ্যমে স্বয়ংক্রিয় করা যেতে পারে। GitHub Actions একটি ওয়ার্কফ্লো তৈরি করতে দেয় যা বাটন চাপলে স্বয়ংক্রিয় ভার্সন আপডেট সহ রিলিজ ব্রাঞ্চ তৈরি করে।

# GitHub Actions — রিলিজ ব্রাঞ্চ তৈরির স্বয়ংক্রিয়করণ
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}