Git-এ pull request: এটি কী এবং GitHub-এ PR কীভাবে তৈরি করবেন

Pull request (PR) হলো পরিবর্তন এক branch থেকে অন্য branch-এ মেশানোর প্রস্তাব, যা GitHub-এর মতো প্ল্যাটফর্মে খোলা হয়। আপনি branch সার্ভারে পাঠান, PR খোলেন, দল diff দেখে, লাইনে মন্তব্য করে, স্বয়ংক্রিয় checks চলে, এবং তারপর merge বোতাম চাপা হয়। GitLab-এ একই ব্যবস্থাকে merge request (MR) বলা হয়। "git pull request কী" প্রশ্নের সংক্ষিপ্ত উত্তর: এটি সেই নিয়ন্ত্রণ-বিন্দু, যা "আমি কোড লিখেছি" এবং "কোড main-এ পৌঁছেছে" এর মাঝে থাকে।

Pull request নামটি কোথা থেকে এলো

নামটি ঐতিহাসিক কারণে এসেছে। লেখক repository-র মালিককে অনুরোধ করেন তাঁর branch "pull" করে নিতে, অর্থাৎ নিজের সঙ্গে মিলিয়ে নিতে, তাই pull request। GitLab নামটি রেখেছে কাজের ফল অনুযায়ী — merge request, অর্থাৎ মেশানোর অনুরোধ, নাম দিয়েছে। Bitbucket ও Azure DevOps-ও "pull request" ব্যবহার করে। মূলত দুটি একই জিনিস: উৎস branch, লক্ষ্য branch, বিবরণ, আলোচনা, checks এবং merge বোতাম।

মনে রাখবেন, pull request Git-এর অংশ নয়। Git-এ "PR" নামের কোনো বস্তু নেই, এটি commit দিয়ে বানানো যায় না এবং .git ফোল্ডারে খুঁজে পাওয়া যায় না। এটি প্ল্যাটফর্মের জিনিস: GitHub বিবরণ, মন্তব্য ও checks-এর অবস্থা নিজের কাছে রাখে, আর Git শুধু সেই branch ও commit সামলায় যা PR-এ আছে।

কথাবার্তায় ডেভেলপাররা "PR" বললে প্রায় সবসময় pull request বোঝায়: "PR পাঠিয়ে দাও", "PR review-তে আছে", "PR merge করে দিলাম"। GitLab-এর জন্য তারা বলে MR।

Pull request ও git pull-এর পার্থক্য

দুটি শব্দ মিলে যাওয়ায় মানুষ প্রায়ই গুলিয়ে ফেলে। git pull remote থেকে নতুন commit এনে সরাসরি আপনার বর্তমান branch-এ মিশিয়ে দেয়। এটি terminal-এ হওয়া স্থানীয় কাজ। Pull request GitHub-এর একটি ওয়েব পেজ, যা এক branch-কে আরেকটিতে মেশানোর প্রস্তাব রাখে।

Git-এ "git pull request" নামের কোনো কমান্ড নেই। একটি পুরনো utility git request-pull আছে, কিন্তু সেটি শুধু পরিবর্তনের সারাংশসহ একটি ইমেইলের টেক্সট বানায় এবং GitHub-এর PR-এর সঙ্গে তার কোনো সম্পর্ক নেই।

Pull request কেন দরকার

একা প্রজেক্টে কাজ করলে main-এ সরাসরি commit করা চলে। দুজন বা তার বেশি মানুষ যুক্ত হলেই main-এ সরাসরি push ভাঙা build ও হারানো কাজের কারণ হতে থাকে। Pull request একসঙ্গে কয়েকটি সমস্যা মেটায়:

• code review — দ্বিতীয় একজন মানুষ পরিবর্তন main-এ যাওয়ার আগে দেখেন এবং লেখকের চোখ এড়িয়ে যাওয়া ভুল ধরেন;
• স্বয়ংক্রিয় checks — GitHub Actions বা অন্য CI প্রতিটি PR-এ tests ও linters চালায়, এবং লাল status থাকলে ভাঙা কোড merge করা যায় না;
• সিদ্ধান্তের ইতিহাস — এক বছর পরেও PR দেখে বোঝা যায় কী বদলানো হয়েছিল এবং কেন, আলোচনাসহ;
• অন্যের প্রজেক্টে অবদান — open source-এ আপনার লেখার অধিকার থাকে না, এবং fork থেকে PR-ই সংশোধন পাঠানোর উপায়;
• branch protection — GitHub-এর নিয়ম main-এ সরাসরি push আটকাতে পারে এবং অনুমোদিত PR চাইতে পারে।

GitHub-এ branch থেকে pull request কীভাবে তৈরি করবেন

এটি সেই দলের মূল পদ্ধতি, যেখানে সবার repository-তে লেখার অধিকার আছে। কাজ হয় feature branch-এ, আর main বদলায় শুধু PR-এর মাধ্যমে।

ধাপ ১. সর্বশেষ main থেকে branch বানান

git switch main
git pull
git switch -c feature/login-form

Branch-এর নাম অর্থবহ রাখুন: feature/…, fix/…, বা task নম্বর। Reviewer সঙ্গে সঙ্গে বুঝবেন কী নিয়ে কথা হচ্ছে।

ধাপ ২. commit করুন

git add src/login.js
git commit -m "লগইন ফর্ম যোগ করা"

একটি PR-এ একটি task। ১০০–৩০০ লাইনের ছোট PR দ্রুত ও মনোযোগ দিয়ে দেখা যায়, আর ৩০০০ লাইনের PR-এ reviewer না দেখেই অনুমোদন দিয়ে দেন।

ধাপ ৩. branch সার্ভারে পাঠান

git push -u origin feature/login-form

-u স্থানীয় branch-কে remote branch-এর সঙ্গে যুক্ত করে, এরপর শুধু git push লিখলেই চলে। GitHub উত্তরে PR তৈরির লিংক নিজে থেকে দেখায়:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

ধাপ ৪. ওয়েবে PR খুলুন

Terminal-এর লিংকে যান, অথবা GitHub-এ repository খুলুন। নতুন push-এর পর সেখানে "Compare & pull request" বোতামসহ একটি ব্যানার দেখা যায়। আরেকটি পথ হলো Pull requests ট্যাব ও New pull request বোতাম।

1. জোড়া যাচাই করুন: base — কোথায় মেশাতে হবে (সাধারণত main), compare — আপনার branch।
2. শিরোনাম লিখুন: কী করা হয়েছে, সংক্ষেপে বা আদেশের আকারে।
3. বিবরণে বলুন কেন, কীভাবে যাচাই করবেন, এবং কী বাকি আছে। Repository-তে PR টেমপ্লেট থাকলে ঘরগুলো নিজে থেকেই ভরে যায়।
4. ডানদিকে reviewers, assignee ও labels ঠিক করুন, যদি দল সেগুলো ব্যবহার করে।
5. Create pull request চাপুন, অথবা draft বেছে নিন (এ নিয়ে পরে)।

Terminal থেকে PR তৈরি: GitHub CLI

Browser-এ যেতে না চাইলে GitHub-এর অফিসিয়াল টুল gh আছে। এটি Git-এর কমান্ড নয়, GitHub-এর আলাদা প্রোগ্রাম, কিন্তু PR-এর জন্য সুবিধাজনক:

gh pr create --base main --title "লগইন ফর্ম যোগ করা" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

"git pull request কমান্ড" প্রশ্নের সৎ উত্তর: Git branch, commit ও push সামলায়, আর PR তৈরি হয় প্ল্যাটফর্মে — browser-এ, gh-এ, বা API-তে।

Fork থেকে অন্যের repository-তে pull request

খোলা প্রজেক্টে আপনার লেখার অধিকার থাকে না। তাই প্রথমে fork বানান, অর্থাৎ GitHub-এ repository-র নিজের কপি, সেখানে কাজ করুন, এবং মূল প্রজেক্টে পরিবর্তন পাঠান।

1. প্রজেক্টের পেজে "Fork" চাপুন; আপনার অ্যাকাউন্টে github.com/you/project তৈরি হবে।
2. আপনার fork clone করুন এবং মূল প্রজেক্টকে দ্বিতীয় remote হিসেবে যুক্ত করুন, যাকে সাধারণত upstream বলা হয়।
3. branch বানান, commit করুন এবং branch-টি আপনার fork-এ পাঠান।
4. GitHub-এ PR খুলুন: base repository — মূল প্রজেক্ট, head repository — আপনার fork এবং আপনার branch।

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "README-এর বানান ভুল ঠিক করা"
git push -u origin fix/typo-readme

কাজ শুরুর আগে CONTRIBUTING.md ফাইলটি পড়ুন: সেখানে সাধারণত commit লেখার নিয়ম, tests, এবং আগে issue খুলতে হবে কি না লেখা থাকে। Fork হালনাগাদ রাখুন: git fetch upstream এবং আপনার branch-এ git rebase upstream/main, যাতে PR মূল প্রজেক্ট থেকে পিছিয়ে না থাকে।

GitLab-এ merge request: কী এবং কীভাবে তৈরি করবেন

GitLab-এর merge request GitHub-এর pull request-এর পূর্ণ সমকক্ষ। নাম ও ইন্টারফেসের বিবরণ আলাদা, কিন্তু প্রক্রিয়া একই: branch, push, মেশানোর অনুরোধ, review, merge।

MR তৈরির কয়েকটি উপায়:

• নতুন branch git push করার পর terminal-এ GitLab-এর দেওয়া লিংক;
• প্রজেক্টের Merge requests অংশে "New merge request" বোতাম দিয়ে উৎস ও লক্ষ্য branch বেছে;
• push-এর সময় push options দিয়ে — browser না খুলেই।

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

GitLab-এর শব্দভাণ্ডার একটু আলাদা: অনুমোদনকে approve বলে, merge-এর দায়িত্বে থাকা ব্যক্তিকে assignee, এবং GitHub Actions-এর জায়গায় থাকে GitLab CI/CD, যা .gitlab-ci.yml ফাইল থেকে চলে। Draft MR-ও আছে।

Pull request-এর review

Reviewer "Files changed" ট্যাব খুলে diff দেখেন। যেকোনো লাইনে মন্তব্য লেখা যায়, অথবা তৈরি সংশোধন প্রস্তাব করা যায় (suggestion), যা লেখক এক বোতামে প্রয়োগ করতে পারেন। মন্তব্যগুলো একটি review-তে জমা হয়ে একটি সিদ্ধান্তসহ একসঙ্গে পাঠানো হয়:

• Comment — শুধু পরামর্শ বা প্রশ্ন, কোনো সিদ্ধান্ত নয়;
• Approve — পরিবর্তন অনুমোদিত;
• Request changes — আরও কাজ দরকার, merge করা উচিত নয়।

ভালো review যুক্তি, পাঠযোগ্যতা, tests ও edge cases দেখে, রুচি নিয়ে তর্ক করে না। ফরম্যাটিং linter-এর হাতে ছেড়ে দিন, যা CI-তে চলে। লেখক প্রতিটি মন্তব্যের উত্তর দেবেন: ঠিক করেছি, আলোচনা করেছি, বা কারণসহ যেমন আছে তেমনই রেখেছি।

অন্যের PR স্থানীয়ভাবে যাচাই (git checkout pull request)

মাঝে মাঝে কোড নিজের কম্পিউটারে চালিয়ে দেখতে হয়। Branch যদি একই repository-তে থাকে, তাহলে git fetch ও git switch-ই যথেষ্ট। Fork থেকে আসা PR-এর জন্য GitHub বিশেষ রেফারেন্স pull/<নম্বর>/head দেয়:

git fetch origin pull/57/head:pr-57
git switch pr-57

GitLab-এ একই ধরনের রেফারেন্সের নাম merge-requests/<নম্বর>/head। অথবা GitHub CLI থাকলে সরাসরি gh pr checkout 57।

Review-এর পর pull request কীভাবে আপডেট করবেন

PR একটি branch-এর সঙ্গে যুক্ত, কোনো নির্দিষ্ট commit-এর সঙ্গে নয়। সেই একই branch-এ নতুন commit করে পাঠালেই PR নিজে থেকে আপডেট হয়; নতুন PR খোলার দরকার নেই।

git commit -am "review-এর মন্তব্য অনুযায়ী পরিবর্তন"
git push

Git rebase pull request: সর্বশেষ main আনা

PR review-তে থাকাকালীন main এগিয়ে যেতে পারে। GitHub যদি বলে branch পুরনো বা conflict আছে, তাহলে সেটি আপডেট করুন। Rebase ইতিহাসকে সরল রেখায় রাখে:

git fetch origin
git rebase origin/main
# conflict মেটান, git add, git rebase --continue
git push --force-with-lease

Rebase-এর পর commit-এর hash বদলে যায়, তাই সাধারণ push বাতিল হবে এবং force push লাগবে। --force-with-lease ব্যবহার করুন: branch-এ অন্য কারও নতুন commit এলে এটি overwrite করতে অস্বীকার করবে। সেই branch-এ যদি শুধু আপনি কাজ না করেন, তবে ইতিহাস না বদলিয়ে git merge origin/main দিয়ে main মেশানো নিরাপদ।

Pull request merge করা: merge, squash ও rebase

Review অনুমোদিত হলে এবং checks সবুজ হলে PR merge করা যায়। GitHub তিনটি উপায় দেয়, আর repository-র admin তার মধ্যে কিছু চালু রাখতে পারেন।

ইন্টারফেস থেকে merge আসলে git merge-ই, শুধু সার্ভারে হয়। Merge-এর পর GitHub branch মুছতে বলবে; মুছে দিন, সেটি আর দরকার নেই। স্থানীয়ভাবে পরিষ্কার করুন:

git switch main
git pull
git branch -d feature/login-form

PR terminal থেকেও merge করা যায়: স্থানীয়ভাবে branch-কে main-এ মিশিয়ে push করুন। GitHub বুঝে নেয় যে commit গুলো base-এ এসে গেছে এবং PR-কে merged হিসেবে চিহ্নিত করে। তবে এতে checks ও branch protection বাদ পড়ে যায়, তাই দলগুলো সাধারণত বোতাম দিয়ে merge করে।

Auto-merge ও merge queue

Checks-এ সময় লাগলে auto-merge চালু করা যায়: সব শর্ত পূরণ হলেই PR নিজে থেকে merge হয়। বড় repository-তে merge queue ব্যবহৃত হয়, যা প্রতিটি PR-কে queue-র আগের পরিবর্তনের ওপর যাচাই করে, যাতে বেমানান পরিবর্তনে main না ভাঙে।

Draft pull request

Draft হলো এমন PR, যা এখনও review-র জন্য প্রস্তুত নয়। সেটি merge করা যায় না, এবং reviewers-এর কাছে review-র অনুরোধ যায় না। Draft উপযোগী, কারণ আগেভাগে দিক দেখানো যায়, CI চালানো যায়, বা architecture নিয়ে মতামত নেওয়া যায়। GitHub-এ PR বানানোর সময় বোতামের মেনু থেকে draft বেছে নিন, অথবা gh pr create --draft চালান। কাজ শেষ হলে "Ready for review" চাপুন। GitLab-এ MR-এর শিরোনামের আগে Draft: লেখা হয়।

Pull request ও issue-র সম্পর্ক

PR-এর বিবরণে কীওয়ার্ড ও issue নম্বর লিখলে merge-এর পর GitHub সেই issue নিজে থেকে বন্ধ করে দেয়:

Closes #42
Fixes #17
Resolves #8

Close, fix ও resolve-এর বিভিন্ন রূপ (closes, fixed, resolves) কাজ করে। শুধু #42 লিখলে লিংক তৈরি হয়, কিন্তু issue বন্ধ হয় না। GitLab-এও Closes #42 ধরনের বাক্য একইভাবে কাজ করে।

Pull request বা merge request কি মুছে ফেলা যায়

GitHub-এ সাধারণ সদস্য PR মুছতে পারেন না, শুধু "Close pull request" বোতামে বন্ধ করতে পারেন। বন্ধ PR ইতিহাসে থাকে এবং আবার খোলা যায়। বন্ধ হওয়ার পর branch আলাদাভাবে মুছুন। PR সম্পূর্ণ মুছে ফেলার কাজ শুধু GitHub সহায়তা দল করতে পারে, যেমন PR-এ গোপন তথ্য (secret) ঢুকে গেলে।

GitLab-এ MR লেখক বা উপযুক্ত অধিকারের সদস্য বন্ধ করতে পারেন, আর মুছে ফেলা প্রজেক্টের মালিক বা admin-এর কাজ। PR-এ পাসওয়ার্ড বা token চলে গেলে শুধু বন্ধ করা যথেষ্ট নয়: সেটি এখনই বাতিল করুন, কারণ commit ইতিমধ্যে সার্ভারে পৌঁছে গেছে।

Pull request-এর সাধারণ ভুল

• main থেকে PR। আপনি নিজের main-এ commit করে সেখান থেকেই PR খুলেছেন। পরের PR-এ পুরনো পরিবর্তনও আসবে। সবসময় আলাদা branch-এ কাজ করুন।
• ভুল base branch। PR develop-এ খোলা হয়েছে, অথচ main-এ হওয়ার কথা ছিল, বা উল্টো। PR-এর শিরোনামের পাশে Edit বোতাম দিয়ে base বদলানো যায়।
• diff-এ অপ্রয়োজনীয় ফাইল। Builds, node_modules, .env। এগুলো .gitignore-এ যোগ করুন এবং git rm --cached দিয়ে index থেকে সরান।
• অতিরিক্ত বড় PR। কাজটি কয়েকটি ধারাবাহিক PR-এ ভাগ করুন।
• rebase-এর পর সাধারণ push। ত্রুটি rejected (non-fast-forward)। --force নয়, git push --force-with-lease দরকার।
• conflict। Web editor-এ না বুঝে তাড়াহুড়ো করে মেটাবেন না। main স্থানীয়ভাবে টানুন, মেটান এবং tests চালান।

Git flow ও অন্য প্রক্রিয়ায় pull request

Pull request যেকোনো দলীয় প্রক্রিয়ায় খাপ খায়। GitHub Flow-তে সরল পথ: main থেকে branch, PR, review, merge, deploy। Git flow-তে PR feature branch থেকে develop-এ খোলা হয়, আর release ও hotfix branch-ও PR-এর মাধ্যমে main-এ যায়। Trunk-based উন্নয়নে PR ছোট হয় এবং কয়েক ঘণ্টা টিকে থাকে, দিন নয়। প্রক্রিয়া যা-ই হোক, নিয়ম একটাই: শেয়ার্ড branch-এ পরিবর্তন শুধু pull request দিয়ে।

উপসংহার

Pull request প্ল্যাটফর্মের সুবিধা, Git-এর কমান্ড নয়: সার্ভারে পাঠানো branch, আর তার সঙ্গে আলোচনা, review ও checks-সহ একটি পেজ। GitLab-এ এটি merge request, কথাবার্তায় PR ও MR। PR সবসময় আলাদা branch থেকে তৈরি করুন, ছোট রাখুন, একই branch-এ push করে আপডেট করুন, এবং প্রজেক্টের ইতিহাস অনুযায়ী merge-এর পদ্ধতি বেছে নিন। Forks, feature branch ও pull request এই কোর্সে বাস্তবে বিস্তারিত শেখানো হয়েছে।