Linear আর GitHub-এর মধ্যে সুইচ করা বন্ধ করো
কেন ইঞ্জিনিয়াররা Linear আর GitHub-এর মধ্যে সুইচ করতে গিয়ে ঘণ্টার পর ঘণ্টা হারায়, নেটিভ ইন্টিগ্রেশন আসলে কী করে, আর কীভাবে এই দুই টুলকে একসাথে কাজ করাবে।
By Chris Calo · 2026-03-17
Branch name ছিল feat/onboarding-email-verification। Linear ticket-এ লেখা ছিল "Implement email verification flow – priority: urgent." GitHub PR-এ তিনটা review comment ছিল, তার মধ্যে দুটো unresolved। আর গত মঙ্গলবারের একটা Slack thread-এ আমাদের designer flag করেছিল যে verification email copy update করা দরকার, ship করার আগে।
the measurable cost of jumping between tools our GitHub PR analysis on context switching the worked calculation on per-developer context switching cost how Slack interruptions erode deep work
আমি জানতাম এগুলো সব আছে। কিন্তু এগুলো যে একই কাজের অংশ, সেটা বুঝতে পারিনি যতক্ষণ না Linear, GitHub, Slack আর নিজের ক্রমশ অবিশ্বস্ত স্মৃতির মধ্যে কুড়ি মিনিট ট্যাব বদলাতে হয়েছে।
তুমি যদি কখনও এমন টিমে কাজ করে থাকো যারা Linear আর GitHub দুটোই ব্যবহার করে (এই সময়ে যেটা প্রায় সব engineering team-এর বাস্তবতা, যারা ঠিক করেছে Jira হলো টুলের চেয়ে শাস্তি বেশি), তাহলে আমি কী বলছি সেটা তুমি একদম বুঝবে। Linear আর GitHub-এর মধ্যে বারবার সুইচ করা কোনো ছোটখাটো বিরক্তি না – এটা আসলে তোমার codebase আর project plan-এ একই সাথে কী হচ্ছে সেটা বোঝার সক্ষমতার ওপর সরাসরি ট্যাক্স।
মিথ: এই টুলগুলো একে অপরের সাথে কথা বলে
Linear-এর একটা GitHub ইন্টিগ্রেশন আছে। সেটআপের শুরুতেই এটা করে ফেলো। আর এটা কাজ করে – তবে নির্দিষ্ট, সীমিত একটা ভাবে, যেটা ঠিকমতো বোঝা দরকার, কারণ মানুষ ভাবে এটা যা করে আর বাস্তবে যা করে, এই দুইয়ের ফাঁকেই বেশিরভাগ কষ্ট থাকে।
Linear-এর GitHub ইন্টিগ্রেশন আসলে যা হ্যান্ডেল করে: তুমি Linear issue থেকে branch বানালে branch name-এ issue ID থাকে। ওই issue ID রেফার করা PR merge হলে Linear issue-টাকে auto-transition করে "Done" করতে পারে। Linear issue detail page-এ PR link দেখতে পারো। এটা সত্যিই কাজের, আর আমি এটা খাটো করে দেখাতে চাই না।
যা হ্যান্ডেল করে না: দুই প্ল্যাটফর্মের মধ্যে comment sync করা। PR-এ unresolved review comment থাকলেও Linear ticket "Done" হয়ে গেলে সেটা flag করা। যেই Slack discussion-এ approach নিয়ে debate হয়েছিল সেটা issue বা PR-এর সাথে কানেক্ট করা। PR খোলার পর Figma design update হয়েছে – এটা সামনে আনা। বা এই ticket-এর requirement যে গত সপ্তাহে কোনো Notion doc-এ চুপচাপ deprioritise করা হয়েছে – সেটা জানা।
ইন্টিগ্রেশন mechanical link হ্যান্ডেল করে – issue থেকে PR। কিন্তু দুটোকে ঘিরে থাকা contextual web হ্যান্ডেল করে না। আর তুমি যখনই Linear আর GitHub-এর মধ্যে সুইচ করো, ওই contextual web-টাই মাথায় রিকন্সট্রাক্ট করার চেষ্টা করো।
সুইচ করলে আসলে কী হয়
Linear আর GitHub-এর মধ্যে একটা সাধারণ কনটেক্সট সুইচিং আসলে কেমন দেখায় সেটা হাঁটিয়ে বলি, কারণ আমার মনে হয় cognitive কাজটা কতটা বেশি সেটা মানুষ underestimate করে।
তুমি Linear-এ আছো। একটা ticket দেখলে যেটা "In Review" মার্ক করা। Review-এর অবস্থা জানতে GitHub PR-এ ক্লিক করলে। এখন তুমি review comments পড়ছো, কিন্তু Linear ticket-এর context হারিয়ে ফেলেছো – priority, acceptance criteria, linked sub-tasks। আবার Linear-এ ট্যাব বদলালে। এবার review comments-এ কোথায় ছিলে সেটা হারালে। আবার GitHub-এ গেলে। Reviewer Slack conversation থেকে কিছু mention করেছে, তাই Slack খুলে thread খুঁজলে। কুড়ি মিনিট চলে গেছে (জানি, কারণ আমি নিজে টাইম ধরে এটা করেছি), তবুও ticket আসলে ship-ready কিনা তার complete picture এখনও নেই।
সমস্যা এটা না যে কোনো একটা টুল খারাপ। Linear তার কাজে দারুণ। GitHub তার কাজে দারুণ। সমস্যা হলো, "তার কাজ" প্রতিটা টুলের boundary-তে থেমে যায়, কিন্তু তুমি যে কাজটা বুঝতে চাইছো সেটা এই boundary মানে না।
Linear আর GitHub-এর মধ্যে সুইচ করা শুধু tab-management সমস্যা না। এটা context-reconstruction সমস্যা – প্রতিবার সুইচে তোমাকে আলাদা টুলের দৃষ্টিকোণ থেকে কাজের mental model আবার গড়তে হয়।
"সবকিছু লিঙ্ক করো" কেন স্কেল করে না
এখানে স্ট্যান্ডার্ড পরামর্শ হলো linking-এ disciplined হও। প্রতিটা PR description-এ Linear ticket URL থাকবে। প্রতিটা Linear ticket-এ তার PR link থাকবে। প্রতিটা commit message issue রেফার করবে।
আর এটা সত্যি কাজ করে, যদি তোমার টিমে তিন-চার জন মানুষ থাকে। ওই স্কেলে সবাই জানে কে কী করছে, linking nice-to-have বেশি, necessity কম, আর মাঝে মাঝে link miss হলেও সমস্যা হয় না কারণ তুমি সরাসরি জিজ্ঞেস করতে পারো।
এটা ভাঙতে শুরু করে যখন পুরো project মাথায় ধরে রাখা যায় না। তুমি যদি চারটা workstream চালাও আর এমন feature-এর PR review করো যেটা তুমি personally spec করোনি, linking discipline critical হয়ে যায় – এবং চাপের মধ্যে সবার আগে ভাঙেও এটাই। কেউ PR link দিতে ভুলে অলসতার কারণে না। ভুলে কারণ তারা coding-এর মধ্যে আছে, তিনটা ট্যাব খোলা, আর PR description-এ Linear URL কপি-পেস্ট করা হলো এমন ছোট, zero-feedback কাজ যেটা ধারাবাহিকভাবে করতে মানুষের brain ভয়ংকরভাবে দুর্বল।
আসল সমস্যা: দুইটা source of truth
এই friction নিয়ে একটা জিনিস বুঝতে আমার সময় লেগেছে, আর আমার মতে এটাই root cause।
এই দুই টুল একই কাজকে একদম আলাদা দৃষ্টিভঙ্গি থেকে দেখায়। Linear দেখায় project management view – priorities, sprints, কে assigned, কী blocked। GitHub দেখায় code view – কী লেখা হয়েছে, কী review হয়েছে, কী merge হয়েছে। দুটোই valid। দুটোই দরকারি। কিন্তু দুটো একই reality-কে আলাদা vocabulary-তে describe করে, আর এদের মধ্যে translation পুরোপুরি manual।
"দুটোই valid। দুটোই দরকারি। কিন্তু দুটো একই reality-কে আলাদা vocabulary-তে describe করে, আর এদের মধ্যে translation পুরোপুরি manual।" – Chris Calo
GitHub-এ PR merge হলে code view বলে "done." Linear ticket update না হলে project view বলে "in progress." নিজ নিজ context-এ দুটোই ঠিক, কিন্তু একে অন্য ছাড়া দুটোই misleading।
এই dual-source-of-truth সমস্যাই (আমার মতে) মূল কারণ কেন বারবার tab-switching এত taxing লাগে। তুমি শুধু টুল বদলাচ্ছো না। তুমি worldview বদলাচ্ছো, তারপর সিদ্ধান্ত নেওয়ার আগে মাথার ভিতর দুটোকে reconcile করতে হচ্ছে।
আজই যা করতে পারো
Architectural solution-এ যাওয়ার আগে (যেটায়, হ্যাঁ, নলেজ গ্রাফ আছে – আমি এমন কোম্পানিতে কাজ করি যে এটা বানায়, তাই প্রয়োজনমতো salt নিয়ে পড়ো), switching cost কমাতে কাজে লাগে এমন কয়েকটা concrete জিনিস:
Branch naming conventions. Linear-এর auto-generated branch name ডিফল্টে issue ID রাখে। এটা নিয়ে লড়ো না। Machine-কে linking করতে দাও।
PR templates. একটা PR template বানাও যাতে "Linear ticket" field থাকে। GitHub .github/PULL_REQUEST_TEMPLATE.md দিয়ে PR template support করে – সেটআপে দশ মিনিট দেবে, missing link-এর কারণে ঘণ্টার ক্ষতি বাঁচবে।
Bidirectional status. তোমার CI pipeline যথেষ্ট sophisticated হলে Linear-এর API ব্যবহার করে PR merge, review, বা changes requested হলে ticket state অটোমেটিক update করতে পারো। এটা বানানো trivial না (draft PR আর force-push নিয়ে webhook handling-এ কিছু edge case আছে), কিন্তু stale-state সমস্যার বড় একটা ক্যাটাগরি কেটে দেয়।
Weekly reconciliation. প্রতি শুক্রবার দশ মিনিট নিয়ে Linear board আর GitHub-এর open PR compare করো। state mismatch হলে flag করো। হ্যাঁ, software লিখে জীবিকা চালানো মানুষের জন্য এটা অস্বস্তিকরভাবে manual – irony আমারও চোখে পড়ে – কিন্তু sprint review-তে mismatch ধরা পড়ার চেয়ে এটা অসীম ভালো, আর drift বড় হওয়ার আগেই ধরে ফেলে।
এগুলো ভালো practice। আমরা সবই ব্যবহার করি। এগুলো constant কনটেক্সট সুইচিং-এর কষ্ট কমায়, কিন্তু শেষ করে না, কারণ মূল সমস্যা – দুই টুল, দুই perspective, এক reality – থেকেই যায়।
Connected view আসলে কেমন দেখায়
Constant switching-এর বিকল্প হলো এমন একটা system যেটা দুই টুলই বোঝে এবং তোমাকে একই সাথে দুইটা mental model মাথায় ধরে না রেখেও একটা কাজের combined state দেখাতে পারে।
Concrete করে বললে: তুমি একটা task দেখলে একসাথে Linear ticket-এর priority আর sprint, GitHub PR-এর review status আর CI results, যে Slack thread-এ approach আলোচনা হয়েছে, আর গতকাল update হওয়া Figma design – সব দেখবে। ক্লিক করে আলাদা আলাদা link খোলার জিনিস হিসেবে না – context হিসেবে, এক জায়গায়, relationship আগেই resolved অবস্থায়।
Sugarbug দিয়ে আমরা এটাই বানাচ্ছি, আর এটাই একমাত্র সমাধান না (কিছু টিম webhook আর decent frontend দিয়ে internal tool বানায়), কিন্তু principle একই: শুরু থেকেই যেসব টুল connected হওয়া উচিত ছিল, সেগুলো connect করার কাজ মানুষকে দিয়ে করানো বন্ধ করো।
---
Sugarbug Linear issues, GitHub PRs, Slack threads, আর Figma comments-কে এক নলেজ গ্রাফে লিঙ্ক করে – যাতে তুমি সুইচ করা বাদ দিয়ে পুরো picture দেখতে পারো। ওয়েটলিস্টে যোগ দাও
---
Linear, GitHub, Slack, আর Figma-কে এক নলেজ গ্রাফে কানেক্ট করো – আর হাতে ধরে context রিকন্সট্রাক্ট করা বন্ধ করো।
প্রশ্ন: Sugarbug কি Linear আর GitHub-এর মধ্যে সুইচ করার দরকার কমায়? উত্তর: হ্যাঁ। Sugarbug API দিয়ে দুই টুলের সাথেই কানেক্ট করে এবং issues, PRs, branches আর conversations-কে লিঙ্ক করে একটা নলেজ গ্রাফ বানায়। প্রতিটা টুল আলাদা করে চেক করার বদলে, তুমি একটা কাজ কীভাবে এগোচ্ছে তার ইউনিফায়েড ভিউ পাও – related Slack discussion আর Figma design সহ।
প্রশ্ন: Sugarbug কি GitHub PR-কে Linear issue-এর সাথে অটোমেটিকভাবে লিঙ্ক করতে পারে? উত্তর: Sugarbug ধরতে পারে যখন একটা GitHub PR Linear issue রেফার করে (branch name, PR description, বা commit message-এর মাধ্যমে), এবং সেগুলোকে অটোমেটিকভাবে তার নলেজ গ্রাফে লিঙ্ক করে। এটা related Slack discussion আর Figma comment-ও একই work item-এর সাথে কানেক্ট করে, তাই প্রতিটা টুলে ক্লিক করে না গিয়েও পুরো context দেখা যায়।
প্রশ্ন: নেটিভ Linear-GitHub ইন্টিগ্রেশন আসলে কী করে? উত্তর: Linear-এর built-in GitHub ইন্টিগ্রেশন PR status-কে Linear issue-এর সাথে sync করে – PR merge হলে linked issue auto-close হতে পারে। Issue detail page-এ PR link-ও দেখায়। কিন্তু এটা comments sync করে না, related Slack conversation কানেক্ট করে না, বা PR আর issue পরস্পরবিরোধী state-এ থাকলে flag করে না (যেমন PR merge হয়ে গেছে কিন্তু ticket "Done" থাকা অবস্থায় review comment unresolved)।
প্রশ্ন: কাজ ট্র্যাক করার জন্য Linear ভালো, নাকি GitHub Issues? উত্তর: দুটোই ভিন্ন উদ্দেশ্যে বানানো। Linear project planning-এর জন্য – sprints, cycles, priorities, roadmaps। GitHub Issues code-level tracking-এর জন্য – bugs, feature requests যেগুলো specific repo-র সাথে tied। বেশিরভাগ engineering team শেষ পর্যন্ত দুটোই ব্যবহার করে (অথবা অন্তত Linear + GitHub PRs), আর ঠিক এই কারণেই switching cost গুরুত্বপূর্ণ, এবং ঠিকভাবে connect করা worth the effort।