Git Flow: এটি কি, ব্রান্চিং মডেল এবং প্রজেক্টে ব্যবহার

Git Flow কি?

Git Flow হল একটি Git ব্রান্চিং মডেল যা ডেভেলপমেন্ট, রিলিজ এবং সংশোধন পরিচালনার জন্য শাখা এবং ফুসিন নিয়মের একটি কঠোর গঠন সংজ্ঞায়িত করে। Vincent Driessen জানুয়ারী 2010-এ “A successful Git branching model” প্রবন্ধ প্রকাশ করেন, এবং তার পর থেকে Git Flow কর্পোরেট Java এবং .NET ডেভেলপমেন্টে ডি ফ্যাক্টো মান হয়ে উঠেছে। মূল ধারণা হল কোডকে পাঁচ ধরনের শাখায় বিভক্ত করা বিভিন্ন স্থিরতা স্তর সহ।

Atlassian Git Tutorials, 2024 অনুযায়ী, Git Flow দুটি স্থায়ী শাখার উপর ভিত্তি করে: main (পূর্বে master) এবং develop। অন্য সকল শাখা অস্থায়ী: feature, release, hotfix। প্রত্যেক শাখার ধরনের একটি পরিষ্কার সংজ্ঞায়িত জীবনচক্র এবং ফুসিন নিয়ম রয়েছে। মোবাইল ডেভেলপমেন্টে, Git Flow ব্যবহার করা হয় নিয়মিত রিলিজ চক্র (2–4 সপ্তাহ) এবং একাধিক সংস্করণ সমর্থন সহ প্রজেক্টে।

Git Flow সহজ মডেল (GitHub Flow) থেকে আলাদা কারণ এটির ইন্টিগ্রেশনের জন্য একটি পৃথক develop শাখা প্রয়োজন। এটি ফুসিন প্রক্রিয়ায় একটি পদক্ষেপ যোগ করে, কিন্তু অসম্পূর্ণ ফিচারগুলিকে রিলিজ-প্রস্তুত কোড থেকে অতিরিক্ত বিচ্ছিন্নতা প্রদান করে।

Vincent Driessen এবং Git Flow-এর ইতিহাস

2010 সালে, Vincent Driessen “A successful Git branching model” পোস্টটি প্রকাশ করেন, যা Git ইতিহাসে সবচেয়ে উদ্ধৃত হয়ে উঠেছে। মডেলটি নির্দিষ্ট রিলিজ এবং সমানান্তর সংস্করণ সমর্থন সহ একটি প্রজেক্টের জন্য তৈরি হয়েছিল। 2020 সালে, Driessen স্বীকার করেন যে Git Flow আধুনিক CI/CD অভ্যাসের জন্য অপ্রচলিত, কিন্তু মডেলটি দীর্ঘ রিলিজ চক্র এবং পুরনো সংস্করণ সমর্থনের প্রয়োজন হলে এখনও প্রাসঙ্গিক রয়েছে।

# Git Flow আরম্ভ করুন
git flow init

# একটি ফিচার শাখা তৈরি করুন
git flow feature start "add-auth"

# ফিচার শাখা শেষ করুন (develop-এ ফুসিন করুন)
git flow feature finish "add-auth"

# একটি release তৈরি করুন
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main শাখা: রিলিজ কোড এবং ট্যাগিং

Main (পূর্বে master) প্রাথমিক শাখা যাতে কেবল ডিপ্লটমেন্টের জন্য প্রস্তুত রিলিজ কোড থাকে। main-এ প্রতিটি কমিট একটি নির্দিষ্ট পণ্য সংস্করণের সাথে মিলিয়ে দেখাউয়া উচিত, সেমান্টিক ভার্সনিং ফরম্যার্টে ট্যাগ করা, যেমন v1.0.0, v1.1.0। main-এ কোন সরাসরি ডেভেলপমেন্ট করা হয় না — পরিবর্তন কেবল release বা hotfix শাখার মাধ্যমে এখানে পৌঁছে।

semver.org, 2024 অনুযায়ী, main-এ ট্যাগ MAJOR.MINOR.PATCH ফরম্যার্ট ব্যবহার করে। MAJOR বাড়ে অসংগত API পরিবর্তনের জন্য, MINOR পিছনের সংগতিতা সহ কার্যক্ষমতা যোগের জন্য, PATCH বাগ ফিক্সের জন্য। Git Flow-এ, প্রতিটি ফিনিশ release সংস্করণ ট্যাগ সহ main-এ স্বচালিতভাবে একটি কমিট তৈরি করে।

Main শাখাটি একমাত্র যা প্রডাক্শনে ডিপ্লট করা হয়। মোবাইল প্রজেক্টের জন্য, এর অর্থ হল main-এ push করার মাধ্যমে App Bundle বা IPA বিল্ড পাইপলাইন এবং Google Play / App Store-এ প্রকাশ শুরু হয়। GitLab CI/CD সেটিংয়ে, main ফর্স-পুশ এবং মুছে ফেলা থেকে সংরক্ষিত।

সেমান্টিক ভার্সনিং এবং ট্যাগ

main-এ প্রতিটি কমিটের সাথে একটি ট্যাগ থাকে SemVer ফরম্যার্টে: vMAJOR.MINOR.PATCH। MAJOR — অসংগত API পরিবর্তনের জন্য, MINOR — পিছনের সংগতিতা সহ নতুন কার্যক্ষমতার জন্য, PATCH — বাগ ফিক্সের জন্য। উদাহরণ: v2.1.0 মানে বাগফিক্স ছাড়া নতুন ফিচার সহ দ্বিতীয় প্রধান রিলিজ। Git Flow-এ, git flow release finish কমান্ডের মাধ্যমে release বা hotfix শেষ করার সময় ট্যাগ স্বচালিতভাবে তৈরি হয়।

Develop শাখা: ডেভেলপমেন্টের ইন্টিগ্রেশন লাইন

Develop Git Flow-এ দ্বিতীয় স্থায়ী শাখা, যা সকল সম্পূর্ণ ফিচার একীবৃত করার জন্য ডিজাইন করা হয়েছে। ডেভেলপররা কোড রিভিউ এবং CI/CD চেক পার করার পর ফিচার শাখা develop-এ ফুসিন করে। Develop-এ কোডের সর্বশেষ স্থির সংস্করণ থাকে, যাতে বর্তমান স্প্রিন্টের সকল বাস্তবায়ন করা ফিচার অন্তর্ভুক্ত থাকে।

DataSift Git Flow Guide, 2024 অনুযায়ী, develop চলমান ইন্টিগ্রেশনের কারণে অস্থায়ীভাবে অস্থির হতে পারে। সমস্যা প্রতিরোধের জন্য, দলগুলি কন্টিনিউয়াস ইন্টিগ্রেশন (CI) অভ্যাস করে: develop-এ ফুসিনের পূর্বে প্রতিটি ফিচারকে একটি পূর্ণ পরীক্ষণ সূট পার করতে হবে। যদি CI ব্যর্থ হয়, ডেভেলপর পরবর্তী ফুসিনের পূর্বে কোড ঠিক করে। Develop সবসময় main-এর বর্তমান সংস্করণের সাথে সংযুক্ত: রিলিজের অবিলম্বে পরে, develop ফুসিনের মাধ্যমে main-এর সাথে সিংক করা হয়।

Feature শাখাগুলি: নতুন কার্যক্ষমতা ডেভেলপ করা

Feature শাখাগুলি হল পৃথক ফিচার, বাগ ফিক্স বা পরীক্ষণ ডেভেলপের জন্য অস্থায়ী শাখা। প্রতিটি ফিচার শাখা develop থেকে তৈরি হয় এবং সম্পূর্ণ হলে develop-এ ফিরে ফুসিন হয়। ফিচার শাখার নামে সাধারণত কাজের নম্বর বা সংক্ষিপ্ত বর্ণনা থাকে: feature/APP-123-add-oauth, feature/redesign-profile। Git Flow-এ, ফিচার শাখা অসীমিত সময় ধরে বর্তমান থাকতে পারে।

Pro Git Book, 2024 অনুযায়ী, ফিচার শাখাগুলি একটি পৃথক্কৃত ডেভেলপমেন্ট পরিবেশ: এক শাখায় পরিবর্তন ফুসিন না হয়া পর্যন্ত অন্যগুলিকে প্রভাবিত করে না। মোবাইল প্রজেক্টে, শেষ করার সময় বড় দ্বন্দ্ব এড়াতে ফিচার শাখা rebase বা merge-এর মাধ্যমে develop-এর সাথে সিংক করা হয়। MR তৈরির পূর্বে ফিচার শাখা develop-এ rebase করার পরামর্শ দেওয়া হয়।

# ম্যানুয়াল ফিচার শাখা তৈরি (git flow ছাড়া)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# CLI-এর মাধ্যমে GitLab-এ MR তৈরি করুন
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release শাখাগুলি: একটি রিলিজ প্রস্তুত করা

Release শাখাগুলি রিলিজ প্রস্তুত করার জন্য develop থেকে তৈরি অস্থায়ী শাখা। যখন develop-এ একটি নতুন সংস্করণের জন্য পর্যাপ্ত ফিচার থাকে, দলটি release/X.Y.Z (যেমন release/2.1.0) শাখা তৈরি করে। এই শাখায় কেবল চুড়ান্ত পরিবর্তন করা হয়: সংস্করণ বৃদ্ধি, লোকালাইজেশন হালনাগাদ, চুড়ান্ত পরীক্ষা, জরুরি বাগ ফিক্স।

Atlassian Git Tutorials, 2024 অনুযায়ী, release শাখা একটি মূল সমস্যা সমাধান করে: চুড়ান্ত পরিবর্তনগুলিকে সমানান্তর ডেভেলপমেন্ট থেকে পৃথক করা। রিলিজ প্রস্তুত হওয়ার সময়, পরবর্তী রিলিজের জন্য নতুন ফিচার develop-এ ফুসিন হতে থাকে। শেষ হলে, release শাখা main (ট্যাগ সহ) এবং develop (সংস্করণ বৃদ্ধি সিংক করার জন্য) এ ফুসিন হয়।

Hotfix শাখাগুলি: প্রডাক্শনে জরুরি সংশোধন

Hotfix শাখাগুলি প্রডাক্শনে জরুরি ক্রান্টিক্যাল বাগ ফিক্সের জন্য অস্থায়ী শাখা। Git Flow-এ একমাত্র শাখা ধরন যা develop-এর পরিবর্তে main থেকে তৈরি হয়। নামের ফরম্যাট: hotfix/X.Y.Z+1 (যেমন hotfix/2.1.1)। শেষ হলে, hotfix শাখা একটি সাথে সাথে main (একটি নতুন প্যাচ রিলিজ হিসাবে) এবং develop (যাতে ফিক্সটি ভবিষ্যত রিলিজে হারায় না যায়) এ ফুসিন হয়।

DataSift Git Flow Guide, 2024 অনুযায়ী, hotfix শাখাগুলি যথাসম্ভব সামান্য হওয়া উচিত — কেবল ফিক্স এবং পরীক্ষা। hotfix-এ নতুন ফিচার বা রিফ্যাক্টরিং অন্তর্ভুক্ত হওয়া উচিত নয়। মোবাইল ডেভেলপমেন্টে, hotfix ব্যবহার করা হয় গুরুতর ক্র্যাশ (crash rate > 0.1%), নিরাপত্তা দুর্বলতা বা App Store-এ অবরোধক বাগের জন্য।

মোবাইল ডেভেলপমেন্টের জন্য Git Flow-এর সুবিধা এবং অসুবিধা

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

Martin Fowler, 2024 অনুযায়ী, Git Flow-এর মূল ত্রুটি হল দীর্ঘজীবী ফিচার শাখা। যদি develop-এর সাথে সিংক ছাড়া 2+ সপ্তাহ ধরে একটি ফিচার ডেভেলপ করা হয়, তবে ফুসিন দ্বন্দ্ব উল্লেখযোগ্য হয়ে উঠে। মোবাইল প্রজেক্টের জন্য, দৈনিক rebase-এর মাধ্যমে develop-এ ফিচার শাখা সিংক করার পরামর্শ দেওয়া হয়।

Git Flow সতত ডিপ্লটমেন্ট (প্রতিটি কমিট main-এ → প্রডাক্শন) সহ প্রজেক্টের জন্য সুপারিশ করা হয় না। এমন প্রজেক্টের জন্য, GitHub Flow বা Trunk-Based Development একটি সহজ এবং দ্রুত মডেল প্রদান করে। কিন্তু রিলিজ চক্র এবং পুরনো সংস্করণ সমর্থন সহ প্রজেক্টের জন্য, Git Flow এখনও সর্বোত্তম পছন্দ রয়েছে।

কদা Git Flow দলের জন্য ক্ষতিকর

Git Flow তিনটি ক্ষেত্রে সমস্যা হয়ে দাঁড়ায়: 5 এর কম সদস্যের দল (অনাবশ্যক জটিলতা), সতত ডিপ্লটমেন্ট (বিতরণে বিলম্ব), rebase শৃঙ্খলার অভাব (দীর্ঘজীবী ফিচার শাখা ফুসিন দ্বন্দ্ব তৈরি করে)। যদি একটি দল শাখা ফুসিন এবং দ্বন্দ্ব সমাধানে 20% এর বেশি সময় ব্যয় করে — তবে Git Flow সেই দলের জন্য উপযুক্ত নয়, যত বড় হলেও না কেন।

Git Flow-এর বিকল্প: GitHub Flow এবং Trunk-Based Development

Git Flow-এর বিকল্প CI/CD অভ্যাসকারী দলের জন্য একটি সহজ প্রক্রিয়া প্রদান করে। GitHub Flow কেবল একটি স্থায়ী শাখা (main) এবং ফিচার শাখা ব্যবহার করে। প্রতিটি ফিচার main থেকে তৈরি হয়, রিভিউ এবং CI এর পর main-এ ফিরে ফুসিন হয় এবং তাত্ক্ষণিক ডিপ্লট করা হয়। GitHub Flow সহজ কিন্তু এটি অসম্পূর্ণ ফিচারের পৃথক্করণ বা সমানান্তর রিলিজ প্রস্তুতি সমর্থন করে না।

GitHub Docs, 2024 অনুযায়ী, Trunk-Based Development (TBD) আরও এগিয়ে গিয়েছে: সকল ডেভেলপর একটি শাখায় (trunk) কাজ করে, 1–2 দিনের স্বল্পজীবী ফিচার শাখা ব্যবহার করে। Feature toggles অসম্পূর্ণ কোডের দৃশ্যমানতা নিয়ন্ত্রণ করে। TBD-এর জন্য উচ্চ CI/CD শৃঙ্খলা এবং পরীক্ষা স্বচালন প্রয়োজন।

• GitHub Flow — একটি main + ফিচার শাখা, CI/CD এবং ছোট দলের জন্য আদর্শ
• GitLab Flow — পরিবেশ শাখা (staging, production) সহ Git Flow বিস্তৃত করে
• Trunk-Based Development — একটি শাখা + feature toggles, সর্বাধিক CI/CD, সর্বনিম্ন ফুসিন
• One Flow — develop শাখা ছাড়া সরলীকৃত Git Flow, কেবল main + feature + release