ব্লগে ফিরুন

Git Sync Fork With Upstream: 3টি নিরাপদ পদ্ধতি

৬ সেপ্টেম্বর, ২০২৬

TL;DR: git fetch upstream && git merge upstream/main && git push origin main চালালেই আপনার fork ক্যাচ আপ হয়ে যায়। একটাই লাইনে পুরো “git sync fork with upstream” ওয়ার্কফ্লো — যে প্রজেক্টটা fork করেছেন তার পরিবর্তন টেনে নিন, তারপর নিজের কপিতে পুশ করুন। লিনিয়ার history পছন্দ হলে merge-এর জায়গায় git rebase upstream/main নিন আর force-push করুন। আর upstream remote-টাই যদি কখনো জোড়াই না হয়ে থাকে, শুরু করুন নিচের ধাপ 1 থেকে — এই নিখোঁজ remote-ই fork “sync হয় না”-র নম্বর এক কারণ। বাকি সব — rebase, GitHub sync বোতাম, অপুশেবল diverged ব্রাঞ্চ — এই তিন কমান্ডের ওপরের বিস্তারিত অংশ।

Fork-কে upstream-এর সাথে sync করা মানে কী?

Fork মানে GitHub-এ কারও রিপোজিটরির আপনার নিজের কপি। মূলটা হলো upstream; আপনার কপিটা origin। GitHub fork নিজে নিজে আপডেট হয় না — মেইনটেইনাররা pull request merge করলেও আপনার কপি গড়পড়তা গতকালের কোডেই থেকে যায়। Fork sync মানে upstream-এর নতুন commit-গুলো আপনার fork-এ টেনে নেওয়া, যাতে আপনার ব্রাঞ্চ প্রজেক্টের বর্তমান অবস্থার সাথে মেলে, অন্তত সেটা ধারণ করে।

এটা দুই কারণে জরুরি। এক, contribution: বাসি fork থেকে খোলা প্রতিটা pull request বাড়তি গোলমাল বয়ে আনে, আর মেইনটেইনাররা merge-এর আগে আপডেট করতে বলবেনই। দুই, self-hosted ব্যবহার বা পড়াশোনা: fork-টা প্রোডাকশনে চালান বা শুধু কোড পড়েন — এক মাস বাসি fork মানে এক মাসের বাগ ফিক্স, যা আপনার হাতে নেই।

কমান্ড লাইন থেকে fork-কে upstream-এর সাথে কীভাবে sync করব?

তিন ধাপ: একবার upstream ঘোষণা করা, তা থেকে fetch করা, তারপর merge ও push। তার জোড়া স্থায়ী — পরেরবার টাইপ করবেন শুধু ধাপ 2 আর 3।

ধাপ 1 — upstream remote যোগ করুন (প্রতি ক্লোনে একবার)।

# fork-এর লোকাল ক্লোনের ভেতরে
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # যাচাই: origin -> আপনার fork, upstream -> মূল রিপো

সঠিক URL মেলে মূল রিপোর পাতায়: সবুজ Code বোতাম। সাধারণ ভুল — দুটো remote-ই নিজের fork-এ ধরা; তখন “sync” চুপচাপ কিছুই করে না, কারণ আপনি ঠিক ততটাই বাসি একটা কপি থেকে fetch করেছেন।

ধাপ 2 — upstream ব্রাঞ্চ fetch করে merge করুন।

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

“git sync fork with upstream command line”-এর এই-ই স্ট্যান্ডার্ড উত্তর। স্বাভাবিক ফল fast-forward — আপনার fork-এর main-এ নতুন কিছুই ছিল না, তাই সেটা কেবল upstream/main পর্যন্ত স্লাইড করে এগিয়ে যায়, কোনো merge commit তৈরি হয় না।

ধাপ 3 — প্রয়োজনে বারবার। git fetch upstream && git merge upstream/main && git push origin main-এর বাইরে মনে রাখার কিছু নেই। Merge-এর আগে কতটা পেছনে আছেন দেখতে fetch-এর পর git rev-list --count main..upstream/main চালান।

Fork sync-এর সময় rebase না merge?

দুটোই একই কোড আপনার fork-এ নামায়; পেছনে যে history রেখে যায়, সেখানেই পার্থক্য। প্রতি রিপোতে একটা নীতি বেছে সেটাতেই লেগে থাকুন:

পদ্ধতিকমান্ডHistory-র ফলসবচেয়ে ভালো যেখানে
Mergegit merge upstream/mainDiverged ব্রাঞ্চে বাড়তি একটা merge commitখোলা PR-সহ ফিচার ব্রাঞ্চ — কিছুই রিরাইট করে না
Rebasegit rebase upstream/mainআপনার commit-গুলো ওপরে রিপ্লে, লিনিয়ার historyFork-এর main পরিষ্কার রাখা; reset করতে চাওয়া diverged fork
GitHub UISync branch বোতাম / PR mergeMerge-এর মতোইক্লোন না খুলে দ্রুত ক্যাচ আপ

Sync-এর rebase রূপটা:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Force push লাগেই, কারণ rebase commit ID ঘুরিয়ে দেয় — আপনার fork-এর রিমোট ব্রাঞ্চ আর লোকালটার বংশধর থাকে না। --force-এর বদলে সবসময় --force-with-lease: ফাঁকে কেউ (বা আপনারই অন্য কোনো মেশিন) পুশ করে থাকলে রিমোট লেখা মানতে অস্বীকার করে — বিপজ্জনক কমান্ডটা এতে ডিফল্টে নিরাপদ হয়ে যায়।

হাতে গোঁজা একটা নিয়ম: যে ব্রাঞ্চে খোলা pull request আছে, সেটা কখনো rebase করবেন না — যতক্ষণ না জানেন কী করছেন — rebase commit ID বদলায়, যা খোলা PR-কে তার commit থেকে বিচ্ছিন্ন করে দিতে পারে। main sync করুন merge দিয়ে (বা নতুন কাজ শুরুর আগে rebase করুন), আর PR ব্রাঞ্চগুলোকে এই খেলার বাইরে রাখুন।

Fork upstream-এর সাথে sync হচ্ছে না কেন?

চারটা চিরচেনা সন্দেহভাজন, আসল টার্মিনালে যে ক্রমে দেখা দেয়:

  1. upstream remote নেইgit remote -v দেখায় শুধু origin। লক্ষণ: git fetch upstream ফেল করে 'upstream' does not appear to be a git repository দিয়ে। সমাধান: ওপরের ধাপ 1।
  2. Fetch করেছেন কিন্তু merge করেননি — fetch লোকাল রিপোর upstream/main আপডেট করে, কোনো কর্মরত ব্রাঞ্চ ছোঁয় না। লক্ষণ: fetch সফল, তবু git log পুরোনো লাগে। সমাধান: git merge upstream/main
  3. Diverged history — নিজের fork-এর main-এ commit করেছেন, আবার upstream-ও এগিয়েছে। git pull তখন unrelated histories-এর অভিযোগ তোলে বা জোর করে merge চায়। সমাধান, upstream-কেই জেতাতে চাইলে: git reset --hard upstream/main (আপনার লোকাল main-only commit ফেলে দেয় — আগে git stash list দেখুন বা ব্রাঞ্চ করে ব্যাকআপ নিন; reset ইতিমধ্যে হয়ে গেলে উদ্ধারের পথ এটাই, git undo last commit-এর মতো: git reflog পুরোনো tip-এর ঠিকানা এখনো জানে)।
  4. Rebase-এর পরে push non-fast-forward বলে বাতিল — rebase করেছেন কিন্তু সাধারণভাবে পুশ করেছেন। সমাধান: git push --force-with-lease origin main

পঞ্চম, বিরল কেস: upstream রিপো rename বা delete হয়ে গেছে, তাই ধাপ 1-এর URL-ও 404 দেয়। GitHub rename হওয়া রিপো redirect করে, তাই কড়া ফেল সাধারণত মানে delete বা প্রাইভেট করা — sync-এর মতো কিছুই আর থাকে না।

GitHub ওয়েবসাইট থেকে কি fork sync করা যায়?

হ্যাঁ। আপনার fork-এর পাতায় ব্রাঞ্চ ড্রপডাউনের পাশে Sync fork বোতাম দেখা যায় যখনই ব্রাঞ্চ পেছনে থাকে; এক ক্লিকে upstream ভেতরে ঢুকে যায়। একটু নিচে, একই কাজ pull request দিয়েও হয়: upstream/main থেকে নিজের fork-এর main-এ PR খুলে merge করুন।

বোতামের সীমাই বলে দেয় CLI-তে কবে ফিরতে হবে: এটি কেবল fast-forward বা merge করে — rebase করে না, আর ব্রাঞ্চ দুটো diverged হলে সরাসরি অস্বীকার করে, commit ফেলতে বা কমান্ড লাইন ব্যবহার করতে বলে। শুধু ডিফল্ট ব্রাঞ্চও sync করে। সাধারণ ক্যাচ আপের বাইরে সব কিছুর জন্য ওপরের তিন কমান্ডই হাতিয়ার।

Fork কত ঘন ঘন sync করা উচিত?

প্রতিটা নতুন কাজের আগে — এটাই সৎ উত্তর: টাটকা main থেকে ব্রাঞ্চ করলে খোলা কোনো PR “তিন সপ্তাহ আগের ভার্সনের ওপর বানানো”-তে শুরু হয় না। যেসব fork-এ নিয়মিত contribute করেন, সেখানে রোজ বা প্রতি সেশনে main sync করা সেকেন্ডের হিসাব। যে fork শুধু পড়েন বা deploy করেন, সেটা sync করুন যখন upstream চাওয়া কিছু ছাড়ে — মূল রিপোর releases ফিড subscribe করুন, release-এ sync করুন। Sync সস্তা ঠিক এজন্যই যে সেটা রুটিন; ছয় মাস পেছনের fork-এ প্রায়ই merge-এর বদলে অপারেশন লাগে — এভাবেই “fork sync করি” একটা বিকেলের প্রজেক্ট হয়ে যায়।

Cheat sheet

# একবারের সেটআপ
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# রুটিন sync (merge নীতি)
git fetch upstream && git merge upstream/main && git push origin main

# রুটিন sync (rebase নীতি, লিনিয়ার history)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# কতটা পেছনে?
git fetch upstream && git rev-list --count main..upstream/main

# মেরামতের বাইরে diverged — main-কে upstream-এর হুবহু কপি করুন (ধ্বংসাত্মক)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

রুটিনের দুই-কমান্ড লাইনটা মাংসপেশির স্মৃতিতে গেঁথে গেলে diverged fork আর গল্পের বইয়ের ঘটনা থেকে যায়, সমাধানের সমস্যা নয়। Git-এর গৃহকর্ম সার্ভার পর্যন্ত বিস্তৃত হলে journalctl cheat sheet কভার করে মেশিনের history পাঠযোগ্য রাখার অন্য অর্ধেকটা।

— mrsaynothing

— mrsaynothing

AI, Linux ও self-hosting নিয়ে ফিল্ড নোটস।

পোস্টটি নিয়ে dev.to-তে আলোচনা করুন dev.to ↗

পরের হাউ-টু ইমেইলে পান

প্রতি পোস্টে একটি ইমেইল। সমাধান করুন, এগিয়ে যান।

self-hosted · কোনো তৃতীয় পক্ষ নেই · এক ক্লিকে আনসাবস্ক্রাইব

এটা কী?

ss vs netstat: কোন Linux পোর্ট কমান্ড ব্যবহার করবেন

লেখাগুলো ভালো লাগছে? এমন জিনিস বানানোই আমার পেশা। আমাকে নিন