Git-এ Feature Branch: এটি কী, কীভাবে তৈরি করবেন এবং শাখাগুলির সাথে কাজ করবেন

Git-এ Feature Branch কী

Feature Branch (বৈশিষ্ট্য শাখা) হল Git-এ একটি অস্থায়ী শাখা যা একটি নির্দিষ্ট কার্যকারিতা উন্নয়নের জন্য develop থেকে তৈরি করা হয়। দীর্ঘস্থায়ী main এবং develop শাখার বিপরীতে, feature শাখাগুলি সীমিত সময়ের জন্য — কয়েক ঘন্টা থেকে কয়েক সপ্তাহ পর্যন্ত — বিদ্যমান থাকে।

feature branch-এর মূল লক্ষ্য হল একটি কাজের সাথে সম্পর্কিত পরিবর্তনগুলিকে বাকি কোড থেকে আলাদা করা। ডেভেলপার তার নিজের শাখায় পরীক্ষা-নিরীক্ষা করতে পারে, অনেকগুলি commit করতে পারে এবং এমনকি কোড ভাঙতে পারে, দলের অন্যান্য সদস্যদের কাজকে প্রভাবিত না করে।

উন্নয়ন সম্পূর্ণ হওয়ার পর, feature branch-টি বাধ্যতামূলক কোড পর্যালোচনা সহ Pull Request-এর মাধ্যমে develop-এ ফিরে একীভূত করা হয়। একীভূত করার পর, রিপোজিটরি পরিষ্কার রাখতে শাখাটি সাধারণত মুছে ফেলা হয়।

Vincent Driessen, 2010-এর মতে, feature শাখার সাথে Git Flow মডেল বিভিন্ন ধরণের শাখার মধ্যে দায়িত্বের স্পষ্ট বিভাজনের কারণে শিল্পের মান হয়ে উঠেছে।

Feature Branch-এর সাথে কর্মপ্রবাহ

কর্মপ্রবাহ feature branch-এর সাথে সেই ধাপগুলির একটি ক্রম নিয়ে গঠিত যা ডেভেলপার প্রতিটি নতুন বৈশিষ্ট্যের জন্য সম্পাদন করে। এই প্রক্রিয়াটি একীভূতকরণের দ্বন্দ্ব কমিয়ে দেয় এবং কোডের গুণমান নিয়ন্ত্রণ নিশ্চিত করে।

1. শাখা তৈরি করা develop-এর সর্বশেষ commit থেকে। ডেভেলপার develop-এ স্যুইচ করে, এটি আপডেট করে এবং একটি নতুন feature শাখা তৈরি করে।
2. উন্নয়ন এবং commits feature শাখায়। ডেভেলপার পরিবর্তন করে, স্পষ্ট বিবরণ সহ commit করে এবং পর্যায়ক্রমে শাখাটি রিমোট রিপোজিটরিতে push করে।
3. develop-এর সাথে সিঙ্ক্রোনাইজেশন — উন্নয়নের সময়, প্রধান শাখা এগিয়ে যেতে পারে। ডেভেলপার তার feature শাখায় develop-এর rebase বা merge করে।
4. Pull Request তৈরি করা — যখন বৈশিষ্ট্যটি প্রস্তুত, ডেভেলপার কোড পর্যালোচনার জন্য একটি PR খোলে। দল কোড পর্যালোচনা করে এবং মন্তব্য রাখে।
5. একীভূতকরণ এবং মুছে ফেলা — PR অনুমোদনের পর, শাখাটি develop-এ একীভূত হয় এবং স্থানীয় ও রিমোট উভয় জায়গা থেকে মুছে ফেলা হয়।

develop-এর সাথে পর্যায়ক্রমিক সিঙ্ক্রোনাইজেশন অত্যন্ত গুরুত্বপূর্ণ। feature শাখা যত বেশি সময় develop থেকে পরিবর্তন একীভূত না করে বেঁচে থাকে, চূড়ান্ত একীভূতকরণে দ্বন্দ্বের সম্ভাবনা তত বেশি।

Feature শাখা সিঙ্ক্রোনাইজেশনের ফ্রিকোয়েন্সি

Feature শাখার নামকরণের নিয়ম

শাখার নামকরণ দলের শৃঙ্খলার একটি গুরুত্বপূর্ণ অংশ। একটি অভিন্ন নামকরণের মান দ্রুত সনাক্ত করতে দেয় যে কোন কাজে কাজ চলছে এবং কে এটি করছে।

• feature/নাম — ক্লাসিক Git Flow-এ feature/ উপসর্গ ব্যবহৃত হয়। উদাহরণ: feature/added-auth-module।
• feature/JIRA-123-বিবরণ — ট্র্যাকিং সিস্টেমে কাজের সংখ্যার সাথে লিঙ্ক। উদাহরণ: feature/PROJ-42-add-login।
• feature/ধরন/নাম — কাজের ধরন নির্দেশ সহ বর্ধিত বিন্যাস। উদাহরণ: feature/feat/analytics-dashboard।

JIRA, Trello বা অন্য সিস্টেম থেকে কাজের ID ব্যবহার করা একটি সেরা অনুশীলন। এটি স্বয়ংক্রিয়ভাবে কোডকে কাজের সাথে সংযুক্ত করে এবং git log-এর মাধ্যমে শাখা অনুসন্ধান সহজ করে।

Pull Request প্রক্রিয়া

Pull Request (বা GitLab-এ Merge Request) হল feature শাখাটিকে develop-এ একীভূত করার অনুরোধ। PR শুধুমাত্র একটি প্রযুক্তিগত অপারেশন নয়, বরং একটি দলগত কোড পর্যালোচনা প্রক্রিয়া যা কোডের গুণমান উন্নত করে এবং দলের মধ্যে জ্ঞান ছড়িয়ে দেয়।

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

দল PR-এ কোড পর্যালোচনা করে, মন্তব্য রাখে, পরিবর্তনের অনুরোধ করে (change requests) এবং একীভূতকরণ অনুমোদন করে (approve)। অনুমোদনের পর, merge বা squash merge সম্পাদন করা হয়।

মোবাইল ডেভেলপমেন্টে PR পর্যালোচনার গড় সময় 4 থেকে 24 ঘন্টা। Danger লাইব্রেরি সরাসরি PR-এ linters এবং পরীক্ষা চালিয়ে কিছু পরীক্ষা স্বয়ংক্রিয় করে।

একটি ভাল PR তৈরি করার জন্য টিপস

• আকার — 300-400 লাইনের বেশি পরিবর্তন নয়। বড় PR পর্যালোচনা করা কঠিন, পর্যালোচনার মান কমে যায়।
• একটি PR — একটি কাজ — একটি অনুরোধে সম্পর্কহীন পরিবর্তন মেশানো এড়িয়ে চলুন।
• স্ক্রিনশট — UI পরিবর্তনের জন্য আগে এবং পরে স্ক্রিনশট সংযুক্ত করুন।
• পরীক্ষা — নতুন কার্যকারিতার জন্য ইউনিট পরীক্ষা লিখুন এবং PR-এ অন্তর্ভুক্ত করুন।

Feature শাখা একীভূতকরণের কৌশল

PR অনুমোদনের পর, feature শাখাটি বিভিন্ন উপায়ে develop-এ একীভূত করা যেতে পারে। একীভূতকরণ কৌশল পছন্দ commit ইতিহাস এবং পরিবর্তনগুলি ফিরিয়ে আনার ক্ষমতাকে প্রভাবিত করে।

• Merge commit — একটি একীভূতকরণ commit তৈরি করে, feature শাখার সম্পূর্ণ commit ইতিহাস সংরক্ষণ করে। ইতিহাস সম্পূর্ণ থাকে, কিন্তু শাখাকরণ গ্রাফ আরও জটিল হয়ে যায়।
• Squash merge — feature শাখার সমস্ত commit একটি একক commit-এ একত্রিত করে এবং develop-এর উপরে যোগ করে। ইতিহাস পরিষ্কার হয়, কিন্তু মধ্যবর্তী commit সম্পর্কে তথ্য হারিয়ে যায়।
• Rebase and merge — feature শাখার commit-গুলিকে develop-এর সর্বশেষ commit-এর উপরে পুনরায় লেখে এবং অতিরিক্ত commit ছাড়াই একীভূত করে। ইতিহাস রৈখিক থাকে।

ঘন ঘন রিলিজ সহ মোবাইল প্রকল্পগুলির জন্য, সাধারণত squash merge ব্যবহৃত হয়: এটি develop-এ একটি পরিষ্কার ইতিহাস দেয়, যখন উন্নয়নের বিশদ PR বিবরণ এবং tracker কাজে থাকে।

Feature Branch নিয়ে কাজ করার সময় সাধারণ ভুল

অভিজ্ঞ ডেভেলপাররাও feature শাখা নিয়ে কাজ করার সময় ভুল করে। সাধারণ সমস্যাগুলি জানা সময় এবং ডেটা ক্ষতি এড়াতে সহায়তা করে।

• শাখার খুব দীর্ঘ জীবন — একটি feature শাখা develop-এর সাথে সিঙ্ক্রোনাইজেশন ছাড়াই 2-3 সপ্তাহের বেশি বেঁচে থাকে, যা ব্যাপক একীভূতকরণ দ্বন্দ্বের দিকে নিয়ে যায়।
• অস্পষ্ট বিবরণ সহ Commits — “fix” বা “update”-এর মতো বার্তা কী পরিবর্তন করা হয়েছে এবং কেন তা বোঝায় না।
• কাজের মিশ্রণ — একই feature শাখায় দুটি সম্পর্কহীন বৈশিষ্ট্য উন্নয়ন করা হয়, যা নির্বাচনী প্রত্যাবর্তন অসম্ভব করে তোলে।
• সিঙ্ক্রোনাইজেশনের অভাব — ডেভেলপার git fetch করে না এবং develop আপডেট করে না, যার ফলে চূড়ান্ত একীভূতকরণে দ্বন্দ্ব দেখা দেয়।

এই সমস্যাগুলি এড়ানোর সর্বোত্তম উপায় হল প্রকল্পের শুরুতে কাজের নিয়মগুলিতে সম্মত হওয়া এবং CI/CD পাইপলাইনে স্বয়ংক্রিয় পরীক্ষা ব্যবহার করা।

Feature Branch-এর সাথে কাজ করার জন্য কমান্ডের উদাহরণ

একটি বাস্তবিক দৃশ্যকল্প বিবেচনা করুন: একজন ডেভেলপার একটি মোবাইল অ্যাপে একটি নতুন প্রমাণীকরণ বৈশিষ্ট্য শুরু করে। তিনি একটি feature শাখা তৈরি করেন, কোড নিয়ে কাজ করেন এবং Pull Request-এর মাধ্যমে কাজটি সম্পূর্ণ করেন।

# develop আপডেট করুন এবং feature শাখা তৈরি করুন
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# বৈশিষ্ট্যে কাজ: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# সার্ভারে feature শাখা push করুন
git push origin feature/add-login-screen

# develop-এর সাথে সিঙ্ক্রোনাইজ করুন (rebase)
git fetch origin develop
git rebase origin/develop

# PR অনুমোদনের পর: স্থানীয় develop আপডেট করুন এবং শাখা মুছুন
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

কমান্ড git branch -d শাখাটিকে কেবল তখনই মুছে ফেলে যখন এর পরিবর্তনগুলি সম্পূর্ণরূপে একীভূত হয়েছে। যদি শাখাটি একীভূত না হয়, Git জোর করে মুছে ফেলার জন্য git branch -D ব্যবহার করার পরামর্শ দেবে — এই ফ্ল্যাগটি সাবধানতার সাথে ব্যবহার করুন।

Feature শাখায় পরীক্ষা স্বয়ংক্রিয়করণ

PR তৈরি করার আগে প্রতিটি feature শাখার জন্য CI/CD পাইপলাইন চালানো উচিত। এটি কোড অন্যান্য ডেভেলপারদের পর্যালোচনায় যাওয়ার আগে প্রাথমিক পর্যায়ে সমস্যা সনাক্ত করতে সহায়তা করে।

# feature শাখা পরীক্ষার জন্য GitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

পাইপলাইন যাচাই করে যে কোড কম্পাইল হয়, পরীক্ষা পাস হয় এবং কোড শৈলী দলের মান পূরণ করে। সমস্ত পরীক্ষা পাস করার পরই একটি Pull Request তৈরি করা যেতে পারে।