Git Workflow-এর তুলনা: Git Flow, GitHub Flow, Trunk-Based

এতক্ষণ আমরা শিখেছি অস্ত্রগুলো — merge, rebase, cherry-pick, revert। Workflow হলো যুদ্ধনীতি: টিম হিসেবে এই অস্ত্রগুলো কোন নিয়মে চালাবেন। আর সিনিয়র/আর্কিটেক্ট-স্তরের মূল উপলব্ধিটা আগেই বলে দিই: workflow-এর পছন্দ আসলে Git-এর সিদ্ধান্ত নয় — deployment model, টিমের পরিপক্বতা আর test-automation-এর সিদ্ধান্ত। Git শুধু সেটার প্রতিফলন।

১. Git Flow — রাজকীয়, আনুষ্ঠানিক, ভারী

Vincent Driessen-এর ২০১০-এর বিখ্যাত মডেল। Branch-এর পুরো রাজপরিবার:

main        ──────────●────────────●──────   (শুধু release, tag করা)
                     /            /
release/2.4 ────────●───hotfix──▲
                   /
develop     ──●──●──●──●──●──●──●──────      (integration branch)
               \    /  \      /
feature/x       ●──●    ●────●               (develop থেকে, develop-এ)

• main = production-এ যা আছে, develop = পরের release-এর জমায়েত
• feature/* → develop-এ merge (--no-ff বাধ্যতামূলক — সেই আলোচনা মনে করুন: feature-সীমানা আর atomic revert)
• release/* branch-এ stabilization, তারপর main এবং develop দুটোতেই merge
• hotfix/* main থেকে বেরিয়ে দুটোতেই ফেরে — আর এখানেই cherry-pick/backport-এর সেই জগৎ

শক্তি:

• Versioned/scheduled release-এর জন্য নিখুঁত: mobile app, on-premise সফটওয়্যার, একাধিক supported version (2.3, 2.4 একসাথে বাঁচিয়ে রাখা), নিয়ন্ত্রিত/regulated রিলিজ-চক্র
• ভূমিকা স্পষ্ট — বড়, বিতরণকৃত, মিশ্র-অভিজ্ঞতার টিমে কাঠামো দেয়
• Release-stabilization আর নতুন কাজ সমান্তরালে চলতে পারে

দুর্বলতা:

• জটিলতা-কর: দুটো দীর্ঘজীবী branch, তিন জাতের সহায়ক branch, dual-merge-এর নিয়ম — ভুলে যাওয়া (hotfix develop-এ ফেরাতে ভুলে যাওয়া = পরের release-এ বাগ ফিরে আসা) নিয়মিত ঘটনা
• Merge-দূরত্ব: feature → develop → release → main — কোড production-এ পৌঁছাতে লম্বা পথ; আর আমাদের conflict-আলোচনার সমীকরণ মনে করুন — branch-এর আয়ু যত, conflict তত চক্রবৃদ্ধিতে
• Continuous deployment-এর সাথে মৌলিকভাবে বেমানান। এমনকি Driessen নিজেই ২০২০-এ নোট যোগ করেছেন: web-app হলে এটা না নিয়ে সরল কিছু নিন

আমার অভিজ্ঞতার ভাষায়: এটা কাজ করে যেখানে "release" একটা ঘটনা — কোয়ার্টারলি এন্টারপ্রাইজ রিলিজ, app-store review চক্র। Microservice-জগতে এটা প্রায় সবসময় over-engineering।

২. GitHub Flow — সরলতার মধ্যপন্থা

মডেলটা এক নিঃশ্বাসে বলা যায়:

main ──●─────●───●────●──   (সবসময় deployable)
        \   /     \  /
         ●─●       ●●        feature branch → PR → review+CI → merge → deploy

নিয়ম মোটে পাঁচটা: main পবিত্র ও সবসময় deployable → feature branch → PR → review + CI সবুজ → merge (squash বা --no-ff) → deploy। ব্যস। আমাদের আগের সব আলোচনা — PR-এর আগে rebase -i দিয়ে গোছানো, --force-with-lease নিজের PR branch-এ, main-এ branch protection — এই workflow-এরই দৈনন্দিন ব্যাকরণ।

শক্তি:

• শেখার খরচ প্রায় শূন্য; PR-কেন্দ্রিক টুলিং (GitHub/GitLab) এর জন্যই বানানো
• Review-gate স্বাভাবিকভাবে প্রক্রিয়ার ভেতরে
• Web-service/SaaS-এর জন্য চমৎকার ভারসাম্য — যেখানে একটাই production version

দুর্বলতা:

• PR-এর অপেক্ষাই bottleneck হতে পারে: review ২ দিন ঝুললে branch বুড়ো হয়, সেই conflict-সমীকরণ আবার
• একাধিক version/environment-এর গল্প নেই — "release branch" ধারণাই অনুপস্থিত; দরকার হলে লোকে Git Flow-এর টুকরো জোড়া দিয়ে "GitLab Flow" জাতীয় সংকর বানায়
• "main সবসময় deployable" কথাটা তখনই সত্য যখন CI সত্যিই শক্তিশালী — নয়তো এটা শুধু শুভকামনা

৩. Trunk-Based Development — চরম integration, চরম শৃঙ্খলা

দর্শন: branch-ই যেহেতু conflict আর দেরির উৎস, branch প্রায় রাখবোই না।

main ●─●─●─●─●─●─●─●─●─●─●   (সবাই এখানেই, দিনে একাধিকবার)
      \_/   \_/
      (ঘণ্টা-দৈর্ঘ্যের branch, বা সরাসরি commit)

• সবাই main-এ (trunk) commit করে — সরাসরি, বা সর্বোচ্চ ১-২ দিনের ক্ষুদ্র branch হয়ে
• অসম্পূর্ণ feature? Feature flag-এর পেছনে লুকিয়ে merge — conflict-আলোচনায় এটা ছুঁয়েছিলাম; এখানে সেটা কেন্দ্রীয় স্তম্ভ
• Release দরকার হলে trunk থেকে ক্ষণস্থায়ী release-branch কেটে tag, fix লাগলে trunk-এ করে cherry-pick — সেই hotfix-backport প্যাটার্ন

শক্তি:

• Merge conflict কার্যত বিলুপ্ত — সমীকরণের "সময়" পদটাই শূন্যের কাছে
• সত্যিকারের Continuous Integration — নামের আসল অর্থে; integration-ব্যথা প্রতিদিন ছোট ডোজে, কখনো merge-day-বিস্ফোরণ নয়
• DORA-গবেষণার ধারাবাহিক ফলাফল: elite-performing টিমগুলোর সাথে এই চর্চার জোরালো সম্পর্ক — deploy-frequency, lead-time সবচেয়ে ভালো

দুর্বলতা — এবং এগুলো সস্তা নয়:

• পূর্বশর্তের পাহাড়: নিখুঁত automated test-suite (main সবসময় সবুজ রাখার একমাত্র রক্ষী), দ্রুত CI, feature-flag অবকাঠামো, আর টিম-শৃঙ্খলা। যেকোনো একটা দুর্বল হলে trunk = সবাই-একসাথে-ভাঙা
• Feature flag নিজেই ঋণ: flag জমে জমে কোডে if-এর জঙ্গল, "flag cleanup" নামের নতুন কাজের জন্ম, flag-combination-এর টেস্ট-বিস্ফোরণ
• Review-এর জায়গা সংকুচিত — pair programming বা post-commit review লাগে, যেটা সব সংস্কৃতিতে চলে না; জুনিয়র-ভারী টিমে ঝুঁকিপূর্ণ

Trade-off-গুলো এক টেবিলে

সিদ্ধান্ত নেবেন কীভাবে — আর্কিটেক্টের চোখে

প্রশ্নটা "কোন workflow সেরা" নয় — "আমাদের release-বাস্তবতা কী":

1. কয়টা version একসাথে বাঁচাতে হয়? একাধিক → Git Flow-ঘেঁষা কিছু অনিবার্য
2. কত ঘন ঘন deploy করি/করতে চাই? দিনে বহুবার → trunk-based-এর দিকে; স্প্রিন্টে একবার → GitHub Flow যথেষ্ট
3. Test-automation-এ কতটা ভরসা? এটা সিলিং ঠিক করে দেয় — দুর্বল টেস্টে trunk-based আত্মঘাতী
4. টিমের গঠন? জুনিয়র-ভারী/বিতরণকৃত টিমে PR-gate-এর মূল্য বেশি

আর বাস্তবতা হলো, অধিকাংশ পরিণত টিম শেষমেশ সংকরে থিতু হয়: GitHub Flow-এর PR-শৃঙ্খলা + trunk-based-এর ছোট-branch-নীতি + প্রয়োজনমতো release-branch — অর্থাৎ লেবেলের চেয়ে নীতিগুলো জরুরি। আর নীতি সবগুলো workflow-এ একটাই দিকে ইঙ্গিত করে, যেটা আমাদের conflict-আলোচনা থেকেই চেনা: integration যত ঘন ঘন আর যত ছোট, ব্যথা তত কম। Workflow-গুলো আসলে এই একটা সত্যকে ঘিরে তিন মাত্রার রক্ষণশীলতা।

এক লাইনে (interview-সংস্করণ)

"তিনটা workflow আসলে release-মডেলের তিনটা উত্তর — Git Flow versioned/scheduled রিলিজের জন্য কাঠামোবহুল কিন্তু ভারী; GitHub Flow single-version web-service-এর জন্য PR-কেন্দ্রিক সরল মধ্যপন্থা; trunk-based continuous-deployment-এর জন্য দ্রুততম, কিন্তু তার দাম শক্তিশালী টেস্ট, feature-flag অবকাঠামো আর টিম-শৃঙ্খলা; বাছাইটা Git-এর প্রশ্ন নয় — deployment-বাস্তবতা আর টিম-পরিপক্বতার প্রশ্ন, আর সর্বজনীন নীতি একটাই: branch যত ছোট, integration যত ঘন, conflict তত কম।"