Rebase: এটি কী, কীভাবে rebase কাজ করে এবং Git-এর সাথে কাজ করা

Git-এ Rebase কী

Rebase হল একটি Git কমান্ড যা বর্তমান ব্রাঞ্চকে একটি নির্দিষ্ট ব্রাঞ্চের উপর রিবেস করে: এটি বর্তমান ব্রাঞ্চ থেকে সমস্ত কমিট নেয়, সেগুলি অস্থায়ীভাবে সংরক্ষণ করে, ব্রাঞ্চ পয়েন্টারটিকে টার্গেট কমিটে নিয়ে যায় এবং সংরক্ষিত কমিটগুলি ক্রমান্বয়ে তার উপরে প্রয়োগ করে। ফলাফল — ইতিহাস এমন দেখায় যেন ডেভেলপারটি সরাসরি টার্গেট ব্রাঞ্চের সর্বশেষ কমিট থেকে কাজ করেছে।

মূল সিন্ট্যাক্স: git rebase main — ফিচার ব্রাঞ্চে থাকাকালীন, এই কমান্ডটি সমস্ত ফিচার কমিট main-এর শীর্ষে নিয়ে যায়। Git প্রতিটি কমিটের জন্য আলাদাভাবে থ্রি-ওয়ে মার্জ কৌশল ব্যবহার করে। যদি কমিট A ইতিমধ্যে টার্গেট ব্রাঞ্চে উপস্থিত থাকে (হ্যাশ দ্বারা নির্ধারিত), Git স্বয়ংক্রিয়ভাবে এটি এড়িয়ে যায়, ডুপ্লিকেট পরিবর্তন এড়িয়ে।

Rebase কমিটের একটি উপসেট স্থানান্তরের জন্য অন্টো মোড সমর্থন করে: git rebase --onto target start end — এই ফর্মটি একটি ব্রাঞ্চ থেকে কমিটের একটি পরিসর বের করে এবং সেগুলিকে অন্যটির উপরে প্রয়োগ করার অনুমতি দেয়। উদাহরণস্বরূপ, git rebase --onto main feature~3 feature ফিচার ব্রাঞ্চের শেষ তিনটি কমিট main-এর উপরে নিয়ে যায়।

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: মূল পার্থক্য

Rebase এবং merge একই কাজ সমাধান করে — বিভিন্ন ব্রাঞ্চ থেকে পরিবর্তন একত্রিত করা — কিন্তু মৌলিকভাবে ভিন্ন উপায়ে করে। Merge দুটি প্যারেন্ট সহ merge কমিট তৈরি করে সম্পূর্ণ মার্জ ইতিহাস সংরক্ষণ করে। Rebase ইতিহাস পুনরায় লেখে, এটিকে রৈখিক করে। তাদের মধ্যে পছন্দ টিমের কাজের ধারা এবং রিপোজিটরি ব্যবস্থাপনা নিয়মের উপর নির্ভর করে।

প্রধান পার্থক্য হল কীভাবে মার্জের ঘটনা রেকর্ড করা হয়। Merge সংরক্ষণ করে: «এই বিন্দুতে আমরা ফিচারকে main-এ মার্জ করেছি» — এটি প্রকল্পের ইতিহাসের জন্য তথ্যপূর্ণ কিন্তু ঘন ঘন মার্জের সাথে লগ জঞ্জাল করে। Rebase দেখায়: «ফিচার কমিটগুলি main-এর সর্বশেষ অবস্থা থেকে ক্রমান্বয়ে করা হয়েছিল» — এটি পরিষ্কার কিন্তু এই সত্যটি লুকায় যে ডেভেলপমেন্ট সমান্তরালে করা হয়েছিল।

দ্বিতীয় পার্থক্য হল দ্বন্দ্ব পরিচালনা। Merge-এর সাথে, দ্বন্দ্বগুলি একবার সমাধান করা হয় এবং সমাধান merge কমিটে রেকর্ড করা হয়। Rebase-এর সাথে, প্রতিটি স্থানান্তরিত কমিটের জন্য দ্বন্দ্ব দেখা দিতে পারে, প্রতিটির আলাদা সমাধান প্রয়োজন। এটি আরও শ্রম-নিবিড় কিন্তু চূড়ান্ত সংস্করণে কোন পরিবর্তনগুলি অন্তর্ভুক্ত হবে তার উপর আরও সুনির্দিষ্ট নিয়ন্ত্রণ দেয়।

ইন্টারঅ্যাক্টিভ Rebase: কমান্ড এবং ফ্ল্যাগ

ইন্টারঅ্যাক্টিভ rebase (git rebase -i) এমন একটি মোড যেখানে Git কমিটের তালিকা এবং প্রতিটির জন্য উপলব্ধ কর্ম সহ একটি এডিটর খোলে। ডেভেলপার রিমোট রিপোজিটরিতে পাঠানোর আগে ইতিহাস পুনরায় লিখতে পারেন। এটি ফিচার ব্রাঞ্চে পরিষ্কার কমিট বজায় রাখার প্রাথমিক টুল।

ইন্টারঅ্যাক্টিভ মোডে উপলব্ধ কমান্ড: pick (কমিট যেমন আছে তেমন রাখুন), reword (কমিট বার্তা পরিবর্তন করুন), edit (পরিবর্তনের জন্য থামুন), squash (পূর্ববর্তী কমিটের সাথে একত্রিত করুন, উভয় বার্তা রেখে), fixup (একত্রিত করুন, বার্তা বাদ দিয়ে), drop (কমিট মুছুন)। প্রতিটি কমান্ড খোলা এডিটরে কমিট হ্যাশের আগে স্থাপন করা হয়।

Squash এবং fixup কমিট একত্রিত করার জন্য সবচেয়ে বেশি ব্যবহৃত কমান্ড। যদি ডেভেলপার কাজের সময় 5টি ছোট সংশোধন কমিট করে থাকে, squash সেগুলিকে একটি অর্থপূর্ণ বার্তা সহ একটি যৌক্তিক কমিটে মার্জ করে। Fixup টাইপো সংশোধনের জন্য দরকারী: পরিবর্তনগুলি নিজস্ব বার্তা না রেখে পূর্ববর্তী কমিটে যায়।

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

--autosquash ফ্ল্যাগটি স্বয়ংক্রিয়ভাবে সেই কমিটগুলির জন্য fixup/squash সাজায় যাদের বার্তা fixup! বা squash! দিয়ে শুরু হয়। এটি কাজ দ্রুত করে যদি ডেভেলপার আগে থেকে পরবর্তী একত্রিতকরণের জন্য কমিট চিহ্নিত করে। --committer-date-is-author-date ফ্ল্যাগ রিবেস করার সময় মূল কমিট তারিখ সংরক্ষণ করে — ইতিহাসে কালানুক্রমিক ক্রম বজায় রাখার জন্য দরকারী।

Rebase-এর সময় দ্বন্দ্ব সমাধান

Rebase-এর সময় দ্বন্দ্ব দেখা দেয় যখন Git টার্গেট ব্রাঞ্চের পরিবর্তনের সাথে বিরোধের কারণে একটি স্থানান্তরিত কমিট স্বয়ংক্রিয়ভাবে প্রয়োগ করতে পারে না। Merge-এর বিপরীতে, যেখানে দ্বন্দ্ব একবার সমাধান করা হয়, rebase-এর সাথে প্রতিটি কমিট দ্বন্দ্ব সৃষ্টি করতে পারে এবং এটি প্রতিটি কমিটের জন্য প্রাচীনতম থেকে নবীনতম পর্যন্ত ক্রমান্বয়ে সমাধান করতে হবে।

যখন দ্বন্দ্ব দেখা দেয়, Git rebase থামিয়ে দেয় এবং রিপোর্ট করে কোন কমিট সমস্যা সৃষ্টি করেছে। ডেভেলপার দ্বন্দ্বযুক্ত ফাইল খোলে (Git দ্বন্দ্ব এলাকাগুলি <<<<<<<, =======, >>>>>>> মার্কার দিয়ে চিহ্নিত করে), এটি সম্পাদনা করে, এটি ইনডেক্সে যোগ করে (git add), এবং git rebase --continue কমান্ড দিয়ে rebase চালিয়ে যায়। যদি কোনো সমাধান না পাওয়া যায় — git rebase --abort সম্পূর্ণভাবে rebase বাতিল করে।

টিপ: একাধিক দ্বন্দ্বের সাথে, git mergetool ব্যবহার করা আরও কার্যকর, যা দ্বন্দ্ব সমাধানের জন্য একটি ভিজুয়াল এডিটর খোলে। আপনি সমস্যাযুক্ত কমিটটি এড়িয়ে যেতে পারেন (git rebase --skip), কিন্তু এটি চূড়ান্ত ইতিহাস থেকে এর পরিবর্তনগুলি সরিয়ে দেবে, যা খুব কমই সঠিক সিদ্ধান্ত।

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

কখন Rebase করা উচিত নয়

Rebase-এর সোনালী নিয়ম: সেই কমিটগুলি কখনই রিবেস করবেন না যা ইতিমধ্যে রিমোট রিপোজিটরিতে পাঠানো হয়েছে এবং অন্যান্য ডেভেলপারদের জন্য উপলব্ধ। যেহেতু rebase কমিট হ্যাশ পুনরায় লেখে, সহকর্মীরা সিঙ্ক করার চেষ্টা করার সময় দ্বন্দ্বের সম্মুখীন হবে — তাদের স্থানীয় ইতিহাস পুনরায় লেখা রিমোট ইতিহাস থেকে ভিন্ন হবে।

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

ব্যতিক্রম: যদি ব্রাঞ্চটি শুধুমাত্র একজন ডেভেলপার ব্যবহার করে (ব্যক্তিগত ফিচার ব্রাঞ্চ, প্রকাশিত নয় বা ড্রাফট মোডে প্রকাশিত), push-এর আগে rebase একটি স্ট্যান্ডার্ড প্র্যাকটিস। প্রকাশ এবং সহযোগিতামূলক কাজ শুরু করার পরে — শুধুমাত্র merge। GitHub এবং GitLab ডিফল্টরূপে একটি সমঝোতা হিসাবে squash merge অফার করে: এটি কমিটগুলিকে একটিতে একত্রিত করে কিন্তু টার্গেট ব্রাঞ্চের ইতিহাস পুনরায় লেখে না।

• পাবলিক ব্রাঞ্চ (main, develop, release) — rebase সম্পূর্ণ নিষিদ্ধ।
• অন্যের কমিট — যদি ব্রাঞ্চে অন্য ডেভেলপারের কমিট থাকে, rebase অনুমোদিত নয়।
• রিলিজের আগে — দ্বন্দ্বের ঝুঁকি বেশি: ডেডলাইনের একদিন আগে merge বেশি নিরাপদ।
• ট্যাগযুক্ত ব্রাঞ্চ — ট্যাগযুক্ত কমিট সরানো সিম্যান্টিক ভার্সনিং কনভেনশন লঙ্ঘন করে।
• CI/CD হ্যাশের সাথে আবদ্ধ — কিছু ডিপ্লয় সিস্টেম হ্যাশের মাধ্যমে বিল্ড শনাক্ত করে; rebase ট্র্যাকিং ভেঙে দেবে।

Rebase-এর সাথে ব্যবহারিক কাজের ধারা

আধুনিক টিমগুলি প্রায়শই GitHub Flow-এর সাথে মিলিত rebase-ভিত্তিক কাজের ধারা ব্যবহার করে। প্রক্রিয়াটি এইরকম: ডেভেলপার main থেকে একটি ফিচার ব্রাঞ্চ তৈরি করে, এতে কাজ করে, পর্যায়ক্রমে git rebase main-এর মাধ্যমে সিঙ্ক করে এবং পুল রিকোয়েস্ট তৈরি করার আগে ইতিহাস পরিষ্কার করতে একটি ইন্টারঅ্যাক্টিভ rebase করে।

PR তৈরি করার পরে (যদি main থেকে নতুন পরিবর্তন আনার প্রয়োজন হয়), সাধারণ git pull-এর পরিবর্তে git pull --rebase main ব্যবহার করা হয়। এটি অপ্রয়োজনীয় merge কমিট তৈরি না করে পরিবর্তন আনে। --rebase ফ্ল্যাগ সহ git pull git fetch + git rebase-এর সমতুল্য — Git প্রথমে নতুন কমিট ডাউনলোড করে, তারপর সেগুলির উপরে স্থানীয় পরিবর্তনগুলি রিবেস করে।

Git pull-এর জন্য ডিফল্ট আচরণ হিসাবে rebase কনফিগার করার অনুমতি দেয়: git config --global pull.rebase true। এই সেটিং-এর পরে, git pull সবসময় merge-এর পরিবর্তে rebase করে। যদি সাধারণ pull-এর প্রয়োজন হয় — git pull --no-rebase ব্যবহার করা হয়। অনেক টিম autostash-ও সক্ষম করে: git config --global rebase.autoStash true — এটি rebase-এর আগে আনকমিটেড পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে লুকিয়ে রাখে এবং পরে সেগুলি পুনরুদ্ধার করে।