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

Git-এ Develop Branch কী

Develop Branch (ডেভেলপমেন্ট ব্রাঞ্চ) হল Git Flow-এ একটি দীর্ঘস্থায়ী ব্রাঞ্চ যা সমস্ত ডেভেলপারদের থেকে কোড ইন্টিগ্রেশনের জন্য কেন্দ্রীয় হাব হিসাবে কাজ করে। ডেভেলপমেন্ট সম্পূর্ণ হওয়ার এবং কোড রিভিউর পরে feature branches এতে মার্জ করা হয়।

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

main-এর বিপরীতে, যেখানে প্রতিটি কোড সংস্করণ একটি রিলিজ, develop-এ পরিবর্তনের একটি ধারাবাহিক ধারা থাকে। feature branches মার্জ হওয়ার সাথে সাথে develop-এ commits দেখা যায়, যা দিনে বেশ কয়েকবার ঘটতে পারে।

Vincent Driessen, 2010-এর মতে, develop একটি সফল ব্রাঞ্চিং মডেলের একটি মূল উপাদান, কারণ এটি খসড়া কাজকে রিলিজের জন্য প্রস্তুত সংস্করণ থেকে আলাদা করে।

develop এবং main branch-এর মধ্যে পার্থক্য

develop এবং main-এর মধ্যে পার্থক্য বোঝা সঠিক Git Flow ওয়ার্কফ্লোর জন্য গুরুত্বপূর্ণ। এই ব্রাঞ্চগুলি ভিন্ন ভিন্ন কাজ করে এবং স্থিতিশীলতার ভিন্ন ভিন্ন প্রয়োজনীয়তা রাখে।

develop এবং main-এ বিভাজন টিমকে প্রোডাকশন সংস্করণের স্থিতিশীলতা ঝুঁকির মধ্যে না ফেলে ক্রমাগত নতুন কোড একীভূত করতে দেয়। ডেভেলপাররা অফিসিয়াল রিলিজের আগেও, PR অনুমোদনের সাথে সাথেই develop-এ তাদের কোড দেখতে পারেন।

Git Flow-এ develop-এর ভূমিকা

Git Flow মডেলে, develop feature branches (পরিবর্তনের উৎস) এবং release branches (রিলিজের প্রস্তুতি) এর মধ্যে একটি কেন্দ্রীয় স্থান দখল করে। এই শ্রেণিবিন্যাস বোঝা কার্যকর ব্রাঞ্চিং-এর ভিত্তি।

• Feature → Develop — প্রতিটি সম্পূর্ণ ফিচার কোড রিভিউ সহ Pull Request-এর মাধ্যমে develop-এ মার্জ করা হয়।
• Develop → Release — যখন রিলিজের জন্য যথেষ্ট পরিবর্তন জমা হয়, develop থেকে release branch তৈরি করা হয়।
• Release → Main + Develop — চূড়ান্ত প্রস্তুতির পরে, release branch main (রিলিজ) এবং develop-এ (বাগ ফিক্স) মার্জ করা হয়।
• Hotfix → Main + Develop — গুরুত্বপূর্ণ ফিক্স main থেকে তৈরি হয় এবং উভয় ব্রাঞ্চে মার্জ করা হয়।

এই কাঠামো নিশ্চিত করে যে develop-এ সর্বদা সমস্ত নতুন ফিচার সহ সর্বশেষ কোড থাকে, যখন main-এ শুধুমাত্র যাচাইকৃত প্রোডাকশন কোড থাকে। এটি App Store এবং Google Play-তে দীর্ঘ রিভিউ চক্রযুক্ত মোবাইল প্রজেক্টের জন্য বিশেষভাবে গুরুত্বপূর্ণ।

অন্যান্য Git Flow ব্রাঞ্চের সাথে develop-এর সম্পর্ক

Develop feature, release এবং hotfix branches-এর মধ্যে কেন্দ্রীয় লিঙ্ক হিসাবে কাজ করে। মার্জ দিকনির্দেশনা বোঝা দ্বন্দ্ব এবং commit হারানো রোধ করার জন্য অপরিহার্য।

develop-এ কোড মানের প্রয়োজনীয়তা

develop-এ কোডের মান উচ্চ হতে হবে, কিন্তু পরম নয়। main-এর বিপরীতে, যেখানে প্রতিটি ত্রুটির অর্থ জরুরি hotfix, develop-এ ছোটখাট ত্রুটি গ্রহণযোগ্য যা রিলিজের আগে ঠিক করা হবে।

develop-এ মার্জ করার আগে কোডের জন্য ন্যূনতম প্রয়োজনীয়তা:

• কম্পাইলেশন — কোড ত্রুটিমুক্তভাবে কম্পাইল হতে হবে। develop-এ ভাঙ্গা build পুরো টিমের কাজ বন্ধ করে দেয়।
• ইউনিট টেস্ট — সমস্ত বিদ্যমান টেস্ট পাস করতে হবে। নতুন কোড কমপক্ষে ৭০% টেস্ট দ্বারা কভার করা উচিত।
• কোড স্টাইল — কোড টিমের গৃহীত ফর্ম্যাটিং এবং নামকরণ মান মেনে চলতে হবে।
• কোনো deprecated API নেই — নতুন কোডে পুরনো পদ্ধতি ব্যবহারের অনুমতি নেই।

CI/CD পাইপলাইনে স্বয়ংক্রিয় পরীক্ষা develop-এ প্রতিটি push-এ চালানো উচিত। যদি build ভেঙে যায়, দায়িত্বশীল ডেভেলপারকে এক ঘন্টার মধ্যে সমস্যা সমাধান করতে হবে বা তাদের commit ফিরিয়ে নিতে হবে।

develop-এর জন্য CI/CD পরীক্ষা

develop-এর জন্য GitHub Actions সেটআপ করা নিশ্চিত করে যে প্রতিটি PR মার্জ করার আগে স্বয়ংক্রিয় পরীক্ষার মধ্য দিয়ে যায়। একটি সাধারণ পাইপলাইনে build, টেস্ট এবং লিন্টিং অন্তর্ভুক্ত।

# GitHub Actions — মার্জের পর develop পরীক্ষা
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

develop-এ মার্জের নিয়ম

develop-এ মার্জ করা ইন্টিগ্রেশন ব্রাঞ্চের স্থিতিশীলতা বজায় রাখতে কঠোর নিয়ম অনুসরণ করতে হবে। এই নিয়ম লঙ্ঘন করলে দ্বন্দ্ব, ভাঙ্গা builds এবং টিমের সময় নষ্ট হয়।

• শুধুমাত্র Pull Request-এর মাধ্যমে — develop-এ সরাসরি push নিষিদ্ধ। সমস্ত পরিবর্তন কোড রিভিউর মধ্য দিয়ে যায়।
• কমপক্ষে একটি অনুমোদন — PR টাস্কে জড়িত নয় এমন কমপক্ষে একজন ডেভেলপার দ্বারা অনুমোদিত হতে হবে।
• Squash merge — পরিষ্কার ইতিহাসের জন্য develop-এ মার্জ করার সময় সমস্ত feature branch commits একত্রিত করার সুপারিশ করা হয়।
• PR হালনাগাদ হতে হবে — মার্জ করার আগে, PR সর্বশেষ develop commit (rebase বা merge) এর সাপেক্ষে হালনাগাদ হতে হবে।

PR হালনাগাদ নিয়ম বিশেষভাবে গুরুত্বপূর্ণ। যদি একটি feature branch এক সপ্তাহ আগে তৈরি করা হয় এবং develop 50 commits এগিয়ে যায়, সরাসরি মার্জ দ্বন্দ্ব সৃষ্টি করতে পারে যা develop-এর পরিবর্তে PR-এর প্রসঙ্গে সমাধান করা ভাল।

ভুল মার্জ থেকে develop রক্ষা করা

Branch protection rules হল GitHub, GitLab বা Bitbucket স্তরের সেটিংস যা develop-এ ভুল পরিবর্তনগুলি প্রতিরোধ করে। তারা নিশ্চিত করে যে এমনকি একটি আকস্মিক pushও ইন্টিগ্রেশন ব্রাঞ্চ ভাঙ্গবে না।

develop-এর জন্য প্রস্তাবিত সুরক্ষা নিয়ম:

• Pull request প্রয়োজন — develop-এ সরাসরি push নিষিদ্ধ করুন। সমস্ত পরিবর্তন শুধুমাত্র PR-এর মাধ্যমে।
• অনুমোদন প্রয়োজন — PR মার্জ করার আগে কমপক্ষে 1-2টি অনুমোদন।
• স্থিতি পরীক্ষা প্রয়োজন — যদি CI/CD পাইপলাইন পাস না করে তবে মার্জ ব্লক করুন।
• হালনাগাদ থাকা প্রয়োজন — মার্জ করার আগে PR ব্রাঞ্চ develop-এর সাপেক্ষে হালনাগাদ হতে হবে।
• Push অ্যাক্সেস সীমাবদ্ধ করুন — develop-এ push অধিকার শুধুমাত্র সিনিয়র ডেভেলপারদের মধ্যে সীমাবদ্ধ করুন।

develop সুরক্ষা সেটআপ করতে 10 মিনিট সময় লাগে কিন্তু ভাঙ্গা ইন্টিগ্রেশন ব্রাঞ্চ সম্পর্কিত সপ্তাহের ডাউনটাইম প্রতিরোধ করে। মাল্টি-প্ল্যাটফর্ম টিমযুক্ত মোবাইল প্রজেক্টের জন্য, এটি বিশেষভাবে প্রাসঙ্গিক।

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

একটি সাধারণ ডেভেলপারের দিন বিবেচনা করুন: সকালে তারা develop আপডেট করে, একটি নতুন feature branch তৈরি করে এবং কাজ শেষ করার পরে পরিবর্তনগুলি develop-এ ফিরিয়ে আনে।

# সকালের develop সিঙ্ক
git checkout develop
git pull origin develop

# develop থেকে নতুন feature branch তৈরি করা
git checkout -b feature/add-push-notifications

# ফিচারে কাজ...
git add . && git commit -m "Add FCM integration"

# ডেভেলপমেন্টের সময় develop আপডেট করা
git fetch origin develop
git rebase origin/develop

# PR অনুমোদনের পরে — স্থানীয় develop আপডেট করুন
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

develop-এ git pull কমান্ড একসাথে দুটি অপারেশন করে: git fetch (সার্ভার থেকে নতুন commits আনে) এবং git merge (সেগুলিকে স্থানীয় ব্রাঞ্চের সাথে মার্জ করে)। develop-এর জন্য, এটি মানক সিঙ্ক্রোনাইজেশন পদ্ধতি।

ভাঙ্গা মার্জের পরে develop পুনরুদ্ধার করা

যদি build ভাঙ্গা কোড develop-এ আসে, তবে দ্রুত কাজ করতে হবে। develop-এর ডাউনটাইমের প্রতিটি ঘন্টা পুরো ডেভেলপমেন্ট টিমের জন্য অবরুদ্ধ কাজ।

যদি build ভাঙ্গা কোড develop-এ আসে, সমস্যাযুক্ত পরিবর্তনগুলি পূর্বাবস্থায় ফেরাতে একটি নতুন commit তৈরি করতে git revert ব্যবহার করুন। develop-এ git reset ব্যবহার করবেন না — এটি ইতিহাস পুনরায় লেখে যা অন্যান্য টিম সদস্যদের কাছে ইতিমধ্যে রয়েছে।

# সমস্যাযুক্ত commit খুঁজে বের করা
git log --oneline develop

# revert-এর মাধ্যমে commit বাতিল (নিরাপদ)
git revert a1b2c3d

# রিমোট develop-এ ফিক্স পাঠানো
git push origin develop

# নির্দিষ্ট commit-এ পরিবর্তন দেখা
git show a1b2c3d --stat