GitHub pull request খুঁজতে scroll নয়—AND, OR ও nested filter লিখুন

বড় repository-তে নির্দিষ্ট pull request (PR) খুঁজতে তালিকা ধরে scroll করার বদলে সার্চ বক্সে is:pr, repo:, অবস্থা এবং প্রয়োজনীয় reviewer বা branch একসঙ্গে লিখুন। একাধিক বিকল্প OR দিয়ে জুড়ুন; বিকল্পগুলোর সব ফলের জন্য একই শর্ত রাখতে সেগুলো বন্ধনীর বাইরে রাখুন। GitHub-এর PR সার্চ নির্দেশিকা এসব qualifier এক কুয়েরিতে মিলিয়ে ব্যবহারের নিয়ম দেখায়।

Repository-র Pull requests পৃষ্ঠার ফিল্টার থেকেও কুয়েরি শুরু করা যায়, তারপর সার্চ বক্সে শর্ত বাড়ানো যায়। GitHub-এর নতুন পৃষ্ঠার ঘোষণায় বলা হয়েছে, পৃষ্ঠাটি সব ব্যবহারকারীর জন্য উন্মুক্ত; এতে AND, OR ও nested search-এর পাশাপাশি ফিল্টার লেখার সহায়তা, sidebar এবং একাধিক PR-এ একসঙ্গে কাজ করার সুবিধা আছে।

প্রথমে খোঁজার পরিসর ঠিক করুন

পুনর্ব্যবহারযোগ্য কুয়েরির একটি ভিত্তি হলো is:pr is:open repo:OWNER/REPO। OWNER/REPO-এর জায়গায় নিজের repository-র নাম বসান। Repository-র Pull requests পৃষ্ঠা থেকে শুরু করলেও repo: লিখে রাখলে কুয়েরিটি পরে অন্য সার্চ পৃষ্ঠায় ব্যবহার করার সময় তার পরিসর স্পষ্ট থাকে। বন্ধ PR-ও খুঁজতে চাইলে is:open বাদ দিন; কেবল merge হওয়া PR চাইলে is:merged ব্যবহার করুন।

এরপর প্রশ্ন অনুযায়ী শর্ত যোগ করুন। author:USERNAME দিয়ে লেখকের PR, assignee:USERNAME দিয়ে তাঁর নামে বরাদ্দ PR এবং base:main দিয়ে main branch-এ merge করার জন্য তৈরি PR খোঁজা যায়। সব qualifier একসঙ্গে লেখার দরকার নেই: অতিরিক্ত শর্ত এমন PR-ও বাদ দিতে পারে, যেটি আসলে আপনার প্রশ্নের উত্তর। উদাহরণে ব্যবহৃত OWNER/REPO, USERNAME ও branch-এর নাম নিজের তথ্য দিয়ে বদলাতে হবে।

AND, OR ও বন্ধনীতে কোন শর্ত কার জন্য, তা লিখুন

AND-এর দুই পাশের শর্তই মিলতে হবে; OR-এর যেকোনো একটি মিললেই হবে। যেমন, is:pr AND is:open AND base:main খোলা PR-এর মধ্যে main-কে লক্ষ্য branch হিসেবে ব্যবহার করা PR খোঁজে। পাশাপাশি লেখা শর্তগুলোর মাঝের ফাঁকাও AND হিসেবে কাজ করে। ছোট কুয়েরিতে ফাঁকা যথেষ্ট, তবে বিকল্প যোগ করলে AND স্পষ্ট করে লেখা যুক্তিটি বুঝতে সাহায্য করে।

ধরা যাক, আপনার কাছে সরাসরি অথবা ORG/TEAM দলের কাছে review চাওয়া হয়েছে এমন খোলা PR খুঁজবেন, এবং সব ফলই main branch-এর জন্য হতে হবে। কুয়েরি হবে: is:pr AND is:open AND repo:OWNER/REPO AND base:main AND (user-review-requested:@me OR team-review-requested:ORG/TEAM)। বন্ধনীর ভেতরে আছে review অনুরোধের বিকল্প দুটি পথ; বাইরের শর্তগুলো উভয় পথেই প্রযোজ্য।

বন্ধনীর জায়গা বদলালে প্রশ্নও বদলায়। যেমন, (is:open AND user-review-requested:@me) OR team-review-requested:ORG/TEAM লিখলে দলের কাছে চাওয়া PR-এর ক্ষেত্রে is:open শর্তটি আর একইভাবে প্রযোজ্য থাকে না। তাই আগে সব ফলের সাধারণ শর্ত লিখুন, তারপর শুধু বিকল্প অংশটি বন্ধনীতে রাখুন। আরও জটিল প্রশ্নে একটি বন্ধনীর মধ্যে আরেকটি দল রাখা যায়, তবে সহজ কুয়েরি দিয়ে একই ফল পাওয়া গেলে বাড়তি স্তর যোগ করার প্রয়োজন নেই।

Review queue-র জন্য কুয়েরি বেছে নিন

Review-সংক্রান্ত qualifier-গুলো একই প্রশ্নের ভিন্ন বানান নয়। কোন PR-এ অনুরোধ এখনো আছে, কোনটিতে review হয়েছে এবং কোনটির merge-এর আগে review প্রয়োজন—এগুলো আলাদা অবস্থা। কাজ অনুযায়ী নিচের কুয়েরিগুলো ব্যবহার করুন।

• আমার কাছে সরাসরি review চাওয়া হয়েছে: is:pr is:open repo:OWNER/REPO user-review-requested:@me। দলের অনুরোধও ধরতে চাইলে আগের বিভাগের বন্ধনীযুক্ত কুয়েরিটি ব্যবহার করুন।
• এখনো review হয়নি: is:pr is:open repo:OWNER/REPO review:none। review:required মানে merge-এর আগে review প্রয়োজন; এটি ‘কেউ এখনো review করেনি’ বোঝায় না।
• পরিবর্তন চাওয়া হয়েছে এবং একটি status check ব্যর্থ: is:pr is:open repo:OWNER/REPO review:changes_requested status:failure। দুই সমস্যার যেকোনো একটি থাকলেই ফল চাইলে শেষের দুই শর্তের মাঝে OR দিয়ে সেগুলো বন্ধনীতে রাখুন।
• নির্দিষ্ট ব্যক্তির review করা PR: is:pr repo:OWNER/REPO reviewed-by:USERNAME। review-requested:USERNAME দিয়ে তাঁর কাছে বর্তমানে review চাওয়া PR খোঁজা হয়; সেটি review ইতিহাসের সমান নয়।

অনুরোধ পাওয়া ব্যক্তি review করলে তাঁকে আর requested reviewer হিসেবে ফলাফলে দেখানো হয় না। অতীতে review করেছেন বা এখনো review-তে যুক্ত আছেন—দুই ধরনের PR একসঙ্গে খুঁজতে review-involves:USERNAME কাজে আসে; শুধু সম্পন্ন করা review-এর জন্য reviewed-by:USERNAME বেশি নির্দিষ্ট। আর team-review-requested:ORG/TEAM একটি নির্দিষ্ট দলের অনুরোধ ধরে, ব্যবহারকারীর নিজের সব দলের অনুরোধ নয়।

Branch, linked issue ও নিজের অংশগ্রহণ আলাদা করুন

PR কোন branch থেকে এসেছে এবং কোন branch-এ merge হওয়ার কথা, তার qualifier আলাদা। head:release উৎস branch-এর নামের শুরুতে release আছে এমন PR খোঁজে; base:main লক্ষ্য branch ধরে। দুই শর্তই প্রয়োজন হলে লিখুন is:pr is:open repo:OWNER/REPO base:main head:release। এখানে release দিয়ে ঠিক একটি branch শনাক্ত হয়েছে ধরে নেবেন না; মিল থাকা branch-এর নাম একাধিক হতে পারে।

Merge হলে বন্ধ হতে পারে এমন issue-র সঙ্গে যুক্ত PR খুঁজতে is:pr is:open repo:OWNER/REPO linked:issue লিখুন। এই qualifier-কে PR-তে কোনো issue-এর সাধারণ উল্লেখের সমার্থক ভাবা ঠিক হবে না। উল্টো প্রশ্নে—কোন issue একটি PR-এর closing reference দিয়ে যুক্ত—কুয়েরিতে is:issue এবং linked:pr ব্যবহার করুন। ফলে খোঁজার বস্তু PR, নাকি issue, সেটিও শুরুতেই ঠিক করতে হয়।

নিজের অংশগ্রহণের বিস্তৃত তালিকার জন্য is:pr is:open repo:OWNER/REPO involves:@me লিখুন। involves: লেখক, দায়িত্বপ্রাপ্ত ব্যক্তি, উল্লেখিত ব্যক্তি বা মন্তব্যকারীর সম্পর্ক মিলিয়ে খোঁজে; কেবল review অনুরোধের তালিকা দেয় না। নিজের লেখা PR আলাদা করতে author:@me, আর নিজের নামে বরাদ্দ PR আলাদা করতে assignee:@me ব্যবহার করুন। একই PR একাধিক সম্পর্কের কারণে প্রাসঙ্গিক হতে পারে, কিন্তু ওই সম্পর্কগুলো এক কাজ বোঝায় না।

শেষ আপডেটের তারিখ দিয়ে পুরোনো PR ধরুন

দীর্ঘদিন আপডেট না হওয়া খোলা PR বাছতে updated: qualifier-এ একটি সীমা দিন। শর্তসাপেক্ষ উদাহরণ হিসেবে, ২০২৬ সালের ১ সেপ্টেম্বরের আগে শেষ আপডেট হওয়া PR দেখতে লিখুন is:pr is:open repo:OWNER/REPO updated:<2026-09-01। এটি শেষ আপডেটের সময় দিয়ে বাছাই করে; PR কেন এগোয়নি, সে সিদ্ধান্ত দেয় না। নতুন তৈরি PR খুঁজতে updated: নয়, created: ব্যবহার করুন।

নিয়মিত ব্যবহারের কুয়েরি ফলের URL হিসেবেও রাখা যায়। GitHub-এর ফিল্টার ব্যবহারের নির্দেশিকা অনুযায়ী, ফিল্টার বা সাজানোর নিয়ম বদলালে ব্রাউজারের URL সেই দৃশ্য অনুযায়ী বদলায়। URL সহকর্মীকে পাঠালে repo ও নির্দিষ্ট তারিখের শর্ত একই থাকবে; তবে @me প্রাপকের নিজের অ্যাকাউন্টকে বোঝাবে। তাই দলজুড়ে একই ব্যক্তির PR খোঁজার কুয়েরি ভাগ করতে হলে @me-এর জায়গায় সেই ব্যবহারকারীর নাম লিখুন।

আরও পড়ুন:

• Pull request-এ secret থাকলে merge বন্ধ—push protection-এর পরেও নতুন জাল
• ইমেইলে অদৃশ্য Unicode: filter পেরোনো phishing ধরতে normalization জরুরি
• GitHub live migration এখন GA—repository চলবে, কিন্তু org settings যাবে না