Merge Request (MR): এটি কী, কীভাবে তৈরি করবেন এবং রিভিউ প্রক্রিয়া

Merge Request (MR) কী?

Merge Request (MR) — একটি Git ব্রাঞ্চ থেকে অন্যটিতে পরিবর্তন একীভূত করার অনুরোধ, যা কোড রিভিউ এবং স্বয়ংক্রিয় পরীক্ষার প্রক্রিয়া শুরু করে। কনসোলের মাধ্যমে সরাসরি মার্জের বিপরীতে, MR একটি আনুষ্ঠানিক পদ্ধতি তৈরি করে: ডেভেলপার পরিবর্তন বর্ণনা করে, রিভিউয়ার নিয়োগ করে, CI/CD চালু করে এবং পরিবর্তন প্রয়োগের আগে প্রতিক্রিয়া পায়। এটি GitLab-এর একটি মূল উপাদান, কিন্তু GitHub-এর সমতুল্য প্রক্রিয়াকে Pull Request (PR) বলা হয়।

GitLab Documentation, 2026 অনুসারে, GitLab-এ বার্ষিক 80 মিলিয়নেরও বেশি Merge Requests তৈরি হয়। প্রতিটি MR-এ চারটি প্রধান উপাদান থাকে: পরিবর্তনের প্রসঙ্গ সহ বর্ণনা, কমিটের তালিকা, কোডের পার্থক্য (diff) এবং আলোচনা (আলোচনা সূত্র)। এই উপাদানগুলির একটির অনুপস্থিতিতে, MR অসম্পূর্ণ বিবেচিত হয়।

Merge Request (MR) তিনটি কাজ সমাধান করে: সুরক্ষিত ব্রাঞ্চে (main, develop) সরাসরি পরিবর্তন প্রতিরোধ করে, রিভিউর মাধ্যমে গুণমান নিয়ন্ত্রণ প্রদান করে এবং ভবিষ্যতের ডেভেলপারদের জন্য আলোচনার ইতিহাস সংরক্ষণ করে। GitLab-এ, MR-এর স্ট্যাটাস ইন্টারফেসে রঙ নির্দেশকের সাথে প্রদর্শিত হয়: Draft-এর জন্য ধূসর, অপেক্ষমাণের জন্য কমলা, Approved-এর জন্য সবুজ, Merged-এর জন্য বেগুনি এবং Closed-এর জন্য লাল।

পরিভাষা: MR, PR এবং CR

বিভিন্ন Git প্ল্যাটফর্মে, Merge Request ভিন্ন ভিন্ন নামে ডাকা হয়। GitLab “Merge Request” (MR) ব্যবহার করে, GitHub “Pull Request” (PR) ব্যবহার করে। Gerrit-এ Change Request (CR) সাদৃশ্যপূর্ণ। তিনটিই একই প্রক্রিয়া নির্দেশ করে: কোড রিভিউর মাধ্যমে পরিবর্তন একীভূত করার অনুরোধ। শব্দটির পছন্দ শুধুমাত্র প্রকল্পে ব্যবহৃত প্ল্যাটফর্মের উপর নির্ভর করে।

# পরিবর্তন সহ একটি ব্রাঞ্চ তৈরি করুন
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# আপনি GitLab/GitHub UI বা CLI-এর মাধ্যমে MR তৈরি করতে পারেন:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR বনাম PR: GitLab এবং GitHub-এর মধ্যে পার্থক্য

GitLab-এ Merge Request এবং GitHub-এ Pull Request কার্যকরীভাবে অভিন্ন প্রক্রিয়া ভিন্ন নামে। পার্থক্যটি ইতিহাসের কারণে: GitLab প্রাথমিকভাবে নিজেকে GitHub-এর Self-Hosted বিকল্প হিসাবে অবস্থান করেছিল এবং মার্জ প্রক্রিয়ার জন্য “merge request” শব্দটি বেছে নিয়েছিল। GitHub, যা আগে চালু হয়েছিল, “pull request” ব্যবহার করেছিল — মূল ব্রাঞ্চে পরিবর্তন “টানার” (pull) অনুরোধ।

GitHub Docs, 2024 অনুসারে, উভয় টুল একই সেট বৈশিষ্ট্য সমর্থন করে: Markdown বর্ণনা, রিভিউয়ার নিয়োগ, কোডের নির্দিষ্ট লাইনে মন্তব্য, পরীক্ষার স্ট্যাটাস এবং শর্ত পূরণ হলে স্বয়ংক্রিয় মার্জ। পার্থক্যগুলি ইন্টারফেস এবং অতিরিক্ত ক্ষমতার সাথে সম্পর্কিত।

কীভাবে Merge Request তৈরি করবেন: ধাপে ধাপে নির্দেশিকা

Merge Request (MR) তৈরি করা রিমোট রিপোজিটরিতে পরিবর্তন সহ একটি ব্রাঞ্চ প্রকাশের মাধ্যমে শুরু হয়। GitLab বা GitHub-এ push করার পরে, ইন্টারফেসে “Create Merge Request” বা “Compare & Pull Request” বাটন দেখা যায়। ডেভেলপার বর্ণনা পূরণ করে, লক্ষ্য ব্রাঞ্চ (সাধারণত develop বা main) নির্দিষ্ট করে, রিভিউয়ার নিয়োগ করে এবং লেবেল সংযুক্ত করে।

GitLab Documentation, 2025 অনুসারে, একটি স্ট্যান্ডার্ড MR-এ 72 অক্ষর পর্যন্ত শিরোনাম, একটি টেমপ্লেট সহ বর্ণনা এবং ইস্যুর লিঙ্ক থাকে। বর্ণনাটি প্রশ্নের উত্তর দেওয়া উচিত: কী করা হয়েছে, কেন, কীভাবে পরীক্ষা করা হয়েছে। GitLab Closes, Fixes, Resolves কীওয়ার্ডের মাধ্যমে মার্জের সময় ইস্যু স্বয়ংক্রিয় বন্ধ করার সমর্থন করে।

# .gitlab/merge_request_templates/default.md টেমপ্লেটের উদাহরণ
## What does this MR do?

[পরিবর্তনের সংক্ষিপ্ত বিবরণ: কী এবং কেন]

## How to test

1. চালান ./gradlew test
2. যাচাই করুন LoginActivity টেস্ট টোকেনসহ
3. নিশ্চিত করুন যে রিগ্রেশন নেই AuthManager

## Related issues

Closes #142

MR জীবনচক্র: Draft থেকে Merged পর্যন্ত

Merge Request (MR) GitLab-এ পাঁচটি স্ট্যাটাসের মধ্য দিয়ে যায়। প্রথমটি হল Draft (খসড়া), শিরোনামে “Draft:” উপসর্গ দিয়ে চিহ্নিত, যা মার্জ ব্লক করে। প্রস্তুত হলে, ডেভেলপার Draft সরিয়ে দেয়, এবং MR Opened স্ট্যাটাসে চলে যায় — কোড রিভিউ শুরু হয় এবং CI/CD পাইপলাইন শুরু হয়।

GitLab Docs, 2024 অনুসারে, Opened স্ট্যাটাসে, রিভিউয়াররা diff পরীক্ষা করে, মন্তব্য রাখে এবং Resolve Threads-এর মাধ্যমে পরিবর্তন অনুরোধ করে। যখন সকল থ্রেড সমাধান হয় এবং CI/CD সফলভাবে পাস করে, দায়িত্বশীল ডেভেলপার Approve সেট করে। তারপর, MR Merge বাটন ব্যবহার করে মার্জ করা যেতে পারে, বা স্বয়ংক্রিয় মার্জ (Auto-merge) অপেক্ষা করা যেতে পারে।

GitLab তিনটি চূড়ান্ত স্ট্যাটাস বিকল্প সমর্থন করে: Merged (সফলভাবে মার্জ), Closed (মার্জ ছাড়া বন্ধ, যেমন একটি বৈশিষ্ট্য পরিত্যাগ করার সময়), এবং Reopened (বন্ধ করার পরে পুনরায় খোলা)। অডিটের জন্য প্রতিটি স্ট্যাটাস MR কার্যকলাপ টাইমলাইনে লগ হয়।

স্বয়ংক্রিয় স্ট্যাটাস এবং ট্রিগার

GitLab ঘটনাগুলিতে Merge Request স্ট্যাটাস স্বয়ংক্রিয়ভাবে আপডেট করে: নতুন কমিট push করলে Approvals রিসেট হয়, সফল CI পাইপলাইনে স্ট্যাটাস Pipeline passed হয়, ব্যর্থতায় — Pipeline failed (মার্জ ব্লক হয়)। Auto-merge কনফিগার করা যেতে পারে: সফল CI এবং সমস্ত প্রয়োজনীয় অনুমোদন পাওয়ার পরে MR স্বয়ংক্রিয়ভাবে মার্জ হয়।

• Draft — খসড়া, CI চলে কিন্তু মার্জ ব্লক করা
• Opened — রিভিউর জন্য প্রস্তুত, রিভিউয়ার নিয়োগ, পাইপলাইন সক্রিয়
• Approved — প্রয়োজনীয় সংখ্যক অনুমোদন প্রাপ্ত
• Merged — পরিবর্তন লক্ষ্য ব্রাঞ্চে মার্জ হয়েছে
• Closed — মার্জ ছাড়া বন্ধ

Merge Request-এ কোড রিভিউর নিয়ম

Merge Request (MR)-এ কোড রিভিউ অধিকাংশ বাণিজ্যিক প্রকল্পে একটি বাধ্যতামূলক ধাপ। SmartBear, 2023 গবেষণা অনুসারে, MR-এর সাথে কোড রিভিউ ত্রুটির সংখ্যা 30–60% কমায় এবং নতুন ডেভেলপারদের অনবোর্ডিং ত্বরান্বিত করে। মূল নিয়ম হল প্রতিটি MR কমপক্ষে একজন, পছন্দসই দুইজন ডেভেলপার দ্বারা পরীক্ষা করা উচিত যারা কোড লেখায় অংশ নেয়নি।

MR পরীক্ষা পাঁচটি মানদণ্ড অন্তর্ভুক্ত করে: যৌক্তিক সঠিকতা, কোড শৈলী মেনে চলা, পরীক্ষার কভারেজ, নিরাপত্তা এবং কর্মক্ষমতা। GitLab-এ, Required Approvals কনফিগার করা যেতে পারে — মার্জের আগে বাধ্যতামূলক অনুমোদনের সংখ্যা, যেমন main-এর জন্য 2টি অনুমোদন এবং develop-এর জন্য 1টি।

MR-এ আলোচনা থ্রেডে পরিচালিত হয় — কোডের নির্দিষ্ট লাইনে মন্তব্য। মার্জের আগে প্রতিটি থ্রেড সমাধান করা আবশ্যক। রিভিউ দ্রুত করতে, MR আকার সীমিত করার পরামর্শ দেওয়া হয়: 200–400 লাইন পরিবর্তন। Google Research (2022) অনুসারে, 400 লাইনের বেশি MR 30% কম কার্যকরভাবে পর্যালোচনা করা হয়।

Merge Request-এ CI/CD পাইপলাইন

Merge Request (MR) তৈরি হলে, CI/CD পাইপলাইন স্বয়ংক্রিয়ভাবে শুরু হয়। GitLab-এ এটি .gitlab-ci.yml ফাইলের মাধ্যমে হয়, GitHub-এ GitHub Actions ওয়ার্কফ্লোর মাধ্যমে। পাইপলাইনে প্রকল্প বিল্ড, ইউনিট টেস্ট, লিন্টার, স্ট্যাটিক বিশ্লেষণ (SAST) এবং কোড কভারেজ পরীক্ষা অন্তর্ভুক্ত।

GitLab Blog, 2024 অনুসারে, পাইপলাইন স্ট্যাটাস সরাসরি MR-এ প্রদর্শিত হয়: সবুজ চেকমার্ক (passed), লাল ক্রস (failed), বা হলুদ বৃত্ত (running)। পাইপলাইন ব্যর্থ হলে, GitLab সমাধান না হওয়া পর্যন্ত Merge বাটন ব্লক করে। সেটিংসে, “Merge when pipeline succeeds” সক্রিয় করা যেতে পারে — সফল পাইপলাইনের পরে স্বয়ংক্রিয় মার্জ।

# .gitlab-ci.yml — Android প্রকল্পের উদাহরণ
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

মার্জ পদ্ধতি: Squash, Merge Commit, Fast-Forward

GitLab এবং GitHub Merge Request-এর জন্য তিনটি মার্জ পদ্ধতি অফার করে। পছন্দ দলের নীতি এবং পছন্দসই ইতিহাস পরিষ্কারতার উপর নির্ভর করে। Merge Commit একটি পৃথক মার্জ কমিট তৈরি করে, সম্পূর্ণ বৈশিষ্ট্য ব্রাঞ্চ ইতিহাস সংরক্ষণ করে। Squash সমস্ত ব্রাঞ্চ কমিট লক্ষ্য ব্রাঞ্চে একটি কমিটে একত্রিত করে। Fast-Forward মার্জ কমিট ছাড়াই কমিটগুলি রৈখিকভাবে প্রয়োগ করে।

GitLab Docs, 2025 অনুসারে, উচ্চ কমিট ঘনত্বের প্রকল্পগুলির জন্য (একটি বৈশিষ্ট্য ব্রাঞ্চে 20+ কমিট) Squash পছন্দ করা হয়। Trunk-Based Development-এর জন্য Fast-Forward বাধ্যতামূলক। Git Flow-এ শাখাকরণ শব্দার্থ সংরক্ষণের জন্য Merge Commit ব্যবহার করা হয়।

• Merge Commit — ইতিহাস সংরক্ষণ করে, মার্জ কমিট তৈরি করে, Git Flow-এর জন্য উপযুক্ত
• Squash — সমস্ত কমিট একটিতে একত্রিত করে, পরিষ্কার ইতিহাস, মধ্যবর্তী কমিট হারায়
• Fast-Forward — মার্জ কমিট ছাড়া রৈখিক ইতিহাস, TBD-তে বাধ্যতামূলক

সেরা অভ্যাস: কীভাবে ভালো MR লিখবেন

একটি গুণগত Merge Request (MR) রিভিউ সময় এবং ত্রুটির সংখ্যা হ্রাস করে। প্রথম নিয়ম হল একটি MR একটি কাজ সমাধান করে। যদি পরিবর্তনগুলি একাধিক অসম্পর্কিত বৈশিষ্ট্যকে প্রভাবিত করে, তবে সেগুলি পৃথক MR-এ বিভক্ত করা উচিত। দ্বিতীয়ত, MR শিরোনাম তথ্যপূর্ণ হওয়া উচিত: “Fix stuff” বা “Update code”-এর পরিবর্তে “Add OAuth2 authentication with Google provider”।

Google Engineering Practices, 2024 অনুসারে, একটি ভাল MR-এ প্রসঙ্গ বর্ণনা থাকে: কেন পরিবর্তনগুলি প্রয়োজনীয়, কীভাবে সেগুলি পরীক্ষা করা হয়েছে এবং কী ঝুঁকি রয়েছে। MR-এর আকার 400 লাইনের বেশি হওয়া উচিত নয়। যদি আয়তন বড় হয়, তবে কাজটি উপ-কাজে বিভক্ত করা প্রয়োজন। ডকুমেন্টেশন এবং পরীক্ষার জন্য, ব্যতিক্রম গ্রহণযোগ্য তবে ব্যাখ্যা সহ।

Merge Request (MR)-এ নতুন কার্যকারিতার জন্য স্বয়ংক্রিয় পরীক্ষা অন্তর্ভুক্ত করা উচিত। GitLab-এ, Coverage Check নীতি কনফিগার করা যেতে পারে — কোড কভারেজ একটি সীমার নিচে নেমে গেলে (যেমন 80%) MR স্বয়ংক্রিয়ভাবে ব্লক হয়। এটি নিশ্চিত করে যে নতুন কার্যকারিতা সামগ্রিক প্রকল্পের গুণমান হ্রাস না করে।

• এক MR — একটি কাজ: বড় পরিবর্তনগুলি কয়েকটি ছোট MR-এ বিভক্ত করুন
• টেমপ্লেট সহ বর্ণনা: একরূপতার জন্য .gitlab/merge_request_templates ব্যবহার করুন
• আকার 400 লাইন পর্যন্ত: বড় MR ধীরে এবং আরও ত্রুটির সাথে পর্যালোচনা করা হয়
• পরীক্ষা বাধ্যতামূলক: নতুন বৈশিষ্ট্যগুলি ইউনিট পরীক্ষা দ্বারা আচ্ছাদিত করা উচিত

MR বর্ণনা টেমপ্লেট

GitLab .gitlab/merge_request_templates/ ফাইলের মাধ্যমে Merge Request টেমপ্লেট সমর্থন করে। টেমপ্লেটে বিভাগ অন্তর্ভুক্ত: কী করা হয়েছে, কীভাবে পরীক্ষা করবেন, সম্পর্কিত কাজ এবং চেকলিস্ট। টেমপ্লেট ব্যবহার MR তৈরি দ্রুত করে এবং নিশ্চিত করে যে ডেভেলপাররা গুরুত্বপূর্ণ তথ্য অন্তর্ভুক্ত করতে ভুলবেন না। MR বর্ণনায়, মার্জের সময় কাজগুলির স্বয়ংক্রিয় বন্ধের জন্য সম্পর্কিত ইস্যু (Closes #N) নির্দিষ্ট করা উচিত।