Pull Request: এটি কী, তৈরি করার প্রক্রিয়া এবং কোড রিভিউ

Pull Request কী?

Pull Request (PR) হল একটি ডিস্ট্রিবিউটেড ভার্সন কন্ট্রোল সিস্টেমের মধ্যে একটি শাখা থেকে অন্য শাখায় পরিবর্তন অন্তর্ভুক্ত করার একটি আনুষ্ঠানিক অনুরোধ। PR হল GitHub, GitLab এবং Bitbucket প্ল্যাটফর্মে সহযোগিতামূলক উন্নয়নের কেন্দ্রীয় উপাদান, যা কোড আলোচনা, স্বয়ংক্রিয় পরীক্ষণ এবং পরিবর্তন অনুমোদন প্রক্রিয়াকে একত্রিত করে।

নামটি “Pull Request” অপারেশনের সারমর্ম প্রতিফলিত করে: একজন ডেভেলপার রিপোজিটরি মালিকের কাছে তার পরিবর্তনগুলি “টানার” (pull) অনুরোধ (request) করে। শব্দটি GitHub 2008 সালে প্রবর্তন করেছিল — তার আগে, প্যাচ এবং merge requests (GitLab-এর শব্দ) আকারে একই রকম প্রক্রিয়া বিদ্যমান ছিল। আজ, PR টিম Git ডেভেলপমেন্টের জন্য ডি ফ্যাক্টো স্ট্যান্ডার্ড।

GitHub Octoverse, 2025 অনুযায়ী, 89% ওপেন-সোর্স প্রকল্পে পরিবর্তন আনার জন্য PR তৈরি করা প্রয়োজন। কর্পোরেট ডেভেলপমেন্টে, এই সংখ্যা 95% এ পৌঁছায়। PR শুধু একটি প্রযুক্তিগত সরঞ্জাম নয়, বরং উন্নয়ন সংস্কৃতির অংশ হয়ে উঠেছে: PR-এর মাধ্যমে জ্ঞান স্থানান্তর, বাগ সনাক্তকরণ এবং আর্কিটেকচারাল সিদ্ধান্ত সমন্বয় ঘটে।

Pull Request-এর উপাদান

একটি সাধারণ PR-এ শিরোনাম, বিবরণ, পরিবর্তিত ফাইলের তালিকা (diff), রিভিউয়ার মন্তব্য এবং CI চেক স্ট্যাটাস থাকে। প্রতিটি PR একটি নির্দিষ্ট উৎস শাখা এবং লক্ষ্য শাখার সাথে সংযুক্ত থাকে এবং মার্জ করার পরে স্বয়ংক্রিয়ভাবে মুছে ফেলা যেতে পারে।

কীভাবে Pull Request তৈরি করবেন

PR তৈরি করা রিমোট রিপোজিটরিতে একটি ফিচার শাখা প্রকাশ করার মাধ্যমে শুরু হয়। পুশ করার পরে, ডেভেলপার প্ল্যাটফর্ম ইন্টারফেস বা CLI (gh, glab) এর মাধ্যমে PR খোলে। আসুন GitHub-এর উদাহরণ দিয়ে প্রক্রিয়াটি দেখি।

শাখা পুশ করা এবং PR খোলা

প্রথম ধাপ — রিমোট রিপোজিটরিতে ফিচার শাখা পুশ করা এবং ওয়েব ইন্টারফেস বা কমান্ড লাইনের মাধ্যমে Pull Request তৈরি করা।

# ফিচার শাখা তৈরি এবং পুশ করুন
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLI-এর মাধ্যমে PR তৈরি করুন
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

PR তৈরি করার পরে, GitHub স্বয়ংক্রিয়ভাবে CI পাইপলাইন (GitHub Actions) চালায়, লক্ষ্য শাখার সাথে দ্বন্দ্ব পরীক্ষা করে এবং রিভিউয়ারদের আমন্ত্রণ জানায়। PR বিবরণ টেমপ্লেট .github/PULL_REQUEST_TEMPLATE.md এর মাধ্যমে কনফিগার করা যেতে পারে যাতে সমস্ত PR-এ প্রয়োজনীয় বিভাগ থাকে: লক্ষ্য, পরিবর্তন, পরীক্ষণ, সম্পর্কিত কাজ।

বিবরণ এবং ট্যাগিং

একটি মানসম্পন্ন PR বিবরণ-এ অন্তর্ভুক্ত: কাজের লিঙ্ক (issue/ticket), পরিবর্তনের সংক্ষিপ্ত বিবরণ, পরীক্ষণের নির্দেশনা এবং সম্পর্কিত পরিবর্তনের তালিকা। লেবেল (bug, feature, refactoring) PR শ্রেণিবদ্ধ করতে সাহায্য করে, যখন assignees এবং reviewers CODEOWNERS-এর মাধ্যমে স্বয়ংক্রিয়ভাবে নিযুক্ত হয়।

# CODEOWNERS-এর মাধ্যমে রিভিউয়ার নিয়োগ করুন (রিপোজিটরি রুটে ফাইল)
# উদাহরণ .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# gh cli-এর মাধ্যমে রিভিউয়ার নিয়োগ করে PR তৈরি করুন
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS হল পরিবর্তিত ফাইলের উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে রিভিউয়ার নিযুক্ত করার জন্য একটি মানক GitHub/GitLab প্রক্রিয়া। উদাহরণস্বরূপ, src/auth/ ডিরেক্টরিতে যে কোনো পরিবর্তন স্বয়ংক্রিয়ভাবে team-auth এবং senior-dev কে রিভিউয়ার হিসেবে নিযুক্ত করে। এটি প্রক্রিয়াকে গতি দেয় এবং নিশ্চিত করে যে সঠিক ব্যক্তিরা PR দেখেন।

রিভিউর উপর ভিত্তি করে PR আপডেট করা

রিভিউয়ারের মন্তব্য পাওয়ার পরে, ডেভেলপার একই ফিচার শাখায় সংশোধন করে এবং নতুন কমিট পুশ করে — PR স্বয়ংক্রিয়ভাবে আপডেট হয়। প্রকাশিত ফিচার শাখায় ইতিহাস পুনরায় লেখা (rebase) গুরুত্বপূর্ণ নয় যদি PR ইতিমধ্যে খোলা থাকে, কারণ এটি মন্তব্যে নির্দিষ্ট কমিটের লিঙ্ক ভেঙ্গে দেয়।

# রিভিউয়ারের মন্তব্যের উপর ভিত্তি করে পরিবর্তন করুন
git checkout feature/biometric-auth
# কোড ঠিক করুন
git commit -m "fix: handle biometric timeout per review"
git push

# PR স্বয়ংক্রিয়ভাবে আপডেট হবে
# অনুমোদনের পরে — GitHub ইন্টারফেসের মাধ্যমে PR মার্জ করুন

কোড রিভিউ প্রক্রিয়া

কোড রিভিউ হল Pull Request-এর কেন্দ্রীয় উপাদান। রিভিউয়ার সঠিকতা, কোড শৈলী, নিরাপত্তা এবং আর্কিটেকচারাল সামঞ্জস্যের জন্য পরিবর্তনগুলি পরীক্ষা করে। একটি মানসম্পন্ন রিভিউ শুধু বাগ প্রতিরোধ করে না বরং টিমের মধ্যে কোডবেস সম্পর্কে জ্ঞান ছড়িয়ে দেয়।

Google-এর Engineering Practices (2025) কোড রিভিউর নিম্নলিখিত নীতিগুলি সুপারিশ করে: রিভিউয়ারকে পরিবর্তনের প্রসঙ্গ বুঝতে হবে, সাধারণ মন্তব্যের পরিবর্তে নির্দিষ্ট সুপারিশ দিতে হবে এবং প্রযুক্তিগত ও শৈলীগত মন্তব্য আলাদা করতে হবে। রিভিউর সময় PR তৈরি করার 24 ঘন্টার বেশি হওয়া উচিত নয়।

মোবাইল ডেভেলপমেন্ট-এর জন্য, কোড রিভিউতে নির্দিষ্ট চেক অন্তর্ভুক্ত: targetSdk-এর সাথে সামঞ্জস্য, সঠিক lifecycle হ্যান্ডলিং (Android) / view lifecycle (iOS), মেমরি লিকের অনুপস্থিতি (LeakCanary, Instruments), ডার্ক থিম সমর্থন এবং স্থানীয়করণ। এই চেকগুলি linters এবং Detekt/ktlint-এর মাধ্যমে স্বয়ংক্রিয় করা যেতে পারে।

মন্তব্যের প্রকার

PR প্ল্যাটফর্ম তিন ধরনের মন্তব্য সমর্থন করে: সাধারণ (সম্পূর্ণ PR-এ), লাইনভিত্তিক (কোডের নির্দিষ্ট লাইনে), এবং পরামর্শ (প্রতিস্থাপন কোড সহ)। পরামর্শ এক ক্লিকে পরিবর্তন প্রয়োগ করতে দেয়, যা প্রক্রিয়াকে গতি দেয় এবং পুনরাবৃত্তির সংখ্যা কমায়।

সমস্ত মন্তব্য সমাধান হওয়ার পরে এবং CI চেক পাস করার পরে, রিভিউয়ার অনুমোদন (Approved) পাঠায়। PR মার্জ করা যেতে পারে। GitHub এবং GitLab শাখা সুরক্ষা নিয়ম সমর্থন করে: প্রয়োজনীয় অনুমোদনের সংখ্যা, বাধ্যতামূলক CI চেক এবং PR ছাড়া main-এ পুশ নিষেধাজ্ঞা। মোবাইল প্রকল্পের জন্য, শাখা সুরক্ষায় বিল্ড যাচাইকরণও অন্তর্ভুক্ত: PR মার্জ করা যাবে না যদি অ্যাপ্লিকেশন বিল্ড না হয় (gradle build failed / xcodebuild failed)।

PR-এ দ্বন্দ্ব সমাধান

মার্জ দ্বন্দ্ব Pull Request-এ সক্রিয় টিম কাজের একটি সাধারণ ঘটনা। প্ল্যাটফর্মগুলি ওয়েব ইন্টারফেসের মাধ্যমে দ্বন্দ্ব সমাধান প্রদান করে (সরল দ্বন্দ্বের জন্য) বা স্থানীয়ভাবে সমাধান করার সুপারিশ করে। GitHub Actions ফিচার শাখায় প্রতিটি পুশের সাথে স্বয়ংক্রিয়ভাবে মার্জযোগ্যতা পরীক্ষা করে এবং যদি মার্জ সম্ভব না হয় তবে PR-কে দ্বন্দ্ব হিসেবে চিহ্নিত করে।

Pull Request-এর সেরা অনুশীলন

কার্যকর Pull Requests কোড রিভিউকে গতি দেয় এবং বাগের সংখ্যা কমায়। SmartBear (2025) এর একটি গবেষণায় দেখা গেছে যে 200 লাইন কোড পর্যন্ত PR 1000 লাইনের বেশি PR-এর তুলনায় 2 গুণ বেশি অর্থপূর্ণ মন্তব্য পায় এবং রিভিউ সময় 3 গুণ কমে যায়।

• ছোট PR — সর্বোত্তম আকার 100-300 লাইন। বড় PR-কে যৌক্তিক অংশে ভাগ করুন: প্রতিটি PR একটি কাজ সমাধান করে। এটি রিভিউ সহজ করে এবং দ্বন্দ্বের সম্ভাবনা কমায়
• স্পষ্ট বিবরণ — Conventional Commits অনুযায়ী শিরোনাম (feat:, fix:, refactor:), বডিতে “কী এবং কেন” থাকে “কীভাবে”-এর পরিবর্তে (কোড নিজেই কথা বলে)। টেমপ্লেট: লক্ষ্য → পরিবর্তন → পরীক্ষণ → সম্পর্কিত issues
• দ্রুত প্রতিক্রিয়া — 24 ঘন্টার মধ্যে রিভিউ। যদি PR এক দিনের বেশি অপেক্ষা করে, টিম প্রসঙ্গ হারায় এবং মার্জ দ্বন্দ্বের সংখ্যা বেড়ে যায়
• অটোমেশন — linters, ফরম্যাটার এবং পরীক্ষণ PR তৈরি করার সময় স্বয়ংক্রিয়ভাবে চলা উচিত। লাল CI চেক সহ PR মার্জ করতে দেবেন না
• Draft PR — প্রাথমিক আর্কিটেকচার আলোচনার জন্য ব্যবহার করুন। Draft PR-এর রিভিউ প্রয়োজন হয় না এবং এটি মার্জ করা যায় না, তবে সহকর্মীদের প্রাথমিক পর্যায়ে কোড দেখাতে দেয়

অতিরিক্ত অনুশীলন: শুক্রবার সন্ধ্যায় PR তৈরি করবেন না (সোমবার পর্যন্ত কেউ রিভিউ করবে না), 1-2 জনের কাছ থেকে রিভিউ অনুরোধ করুন (বেশি গুণমান উন্নত না করে প্রক্রিয়াকে ধীর করে), মার্জ করার আগে ইতিহাস সংকুচিত করতে squash merge ব্যবহার করুন। মোবাইল প্রকল্পের জন্য, PR বিবরণে পরীক্ষণ বিল্ডের (Firebase App Distribution / TestFlight) লিঙ্ক যোগ করারও সুপারিশ করা হয় যাতে রিভিউয়ার চলমান অ্যাপ্লিকেশনে পরিবর্তন যাচাই করতে পারে।

বিভিন্ন প্ল্যাটফর্মে Pull Request

Pull Requests নিয়ে কাজ করার জন্য প্রধান প্ল্যাটফর্ম হল GitHub, GitLab এবং Bitbucket। ভাগ করা ধারণা সত্ত্বেও, প্রতিটির বৈশিষ্ট্য রয়েছে যা টিমের জন্য টুল বেছে নেওয়ার সময় বিবেচনা করা উচিত।

GitHub সবচেয়ে জনপ্রিয় প্ল্যাটফর্ম যা সবচেয়ে বড় কমিউনিটি, CI/CD-এর জন্য Actions এবং অ্যাপ্লিকেশনের বিস্তৃত ইকোসিস্টেম (GitHub Marketplace) নিয়ে। GitLab-এ বিল্ট-ইন CI/CD এবং সম্পূর্ণ সেল্ফ-হোস্টেড ডিপ্লয়মেন্ট ক্ষমতা রয়েছে। Bitbucket Jira এবং Atlassian ইকোসিস্টেমের সাথে ঘনিষ্ঠভাবে সংহত, কর্পোরেট পরিবেশে জনপ্রিয়।

মোবাইল ডেভেলপমেন্ট-এর জন্য, প্ল্যাটফর্মের পছন্দ প্রায়শই CI/CD ক্ষমতা দ্বারা নির্ধারিত হয়: GitHub Actions iOS বিল্ডের জন্য macOS runners সমর্থন করে, GitLab-এ iOS/Android-এর জন্য বিল্ট-ইন runners রয়েছে, Bitbucket Firebase Test Lab-এর সাথে ভালভাবে সংহত হয়। প্ল্যাটফর্ম নির্বিশেষে, PR প্রক্রিয়া একই থাকে: শাখা → রিভিউ → CI → মার্জ।