Rebase: এটি কী, Merge থেকে কীভাবে আলাদা এবং কার্যনীতি

Rebase কী?

Rebase (রিবেজিং) হল একটি Git অপারেশন যা বর্তমান শাখা থেকে একটি নতুন বেস পয়েন্টে কমিট স্থানান্তর করে। একটি মার্জ কমিট তৈরি করার পরিবর্তে, rebase উৎস শাখা থেকে প্রতিটি কমিট নেয় এবং নতুন বেসের উপরে একে একে প্রয়োগ করে। ফলাফল হল শাখাবিহীন কমিটের একটি রৈখিক ক্রম।

নাম rebase “re-base” থেকে এসেছে — বেস পরিবর্তন করা। যেখানে merge দুটি শাখাকে একটি বিন্দুতে একত্রিত করে, rebase আপনার সম্পূর্ণ শাখাকে একটি নতুন অবস্থানে স্থানান্তর করে, যেন আপনি লক্ষ্য শাখার বর্তমান অবস্থা থেকে উন্নয়ন শুরু করেছিলেন। এটি সম্পূর্ণ অনুক্রমিক কাজের বিভ্রম তৈরি করে।

Atlassian, 2025 অনুসারে, যে দলগুলি ফিচার শাখার জন্য rebase ব্যবহার করে, তারা কেবল merge ব্যবহার করা দলগুলির তুলনায় কমিট ইতিহাস বিশ্লেষণে 30% কম সময় ব্যয় করে। রৈখিক ইতিহাস git blame, bisect এবং git log --oneline-এর মাধ্যমে লগ দেখা সহজ করে।

Merge থেকে মৌলিক পার্থক্য

Merge দুটি প্যারেন্টবিশিষ্ট একটি কমিট তৈরি করে শাখাগুলিকে একত্রিত করে। Rebase ইতিহাস পুনরায় লেখে: নতুন কমিট নতুন হ্যাশ দিয়ে তৈরি হয়, যদিও তাদের পরিবর্তনগুলি মূলের মতোই। এর মানে rebase কমিটের SHA শনাক্তকারী পরিবর্তন করে, যা পাবলিক শাখার জন্য গুরুত্বপূর্ণ।

Rebase কীভাবে কাজ করে

Rebase প্রক্রিয়া চারটি ধাপ নিয়ে গঠিত: Git বর্তমান এবং লক্ষ্য শাখার সাধারণ পূর্বপুরুষ (মার্জ বেস) নির্ধারণ করে, তারপর লক্ষ্য শাখার উপরে বর্তমান শাখার প্রতিটি কমিট ক্রমিকভাবে প্রয়োগ করে। কোনো ধাপে দ্বন্দ্ব দেখা দিলে, rebase থেমে যায় এবং সমাধানের জন্য অপেক্ষা করে।

# প্রারম্ভিক পরিস্থিতি: feature শাখা develop থেকে 3 কমিট পিছিয়ে আছে
git checkout feature/new-login
git rebase develop

# Git feature থেকে 3 কমিট নেয় এবং develop-এর উপরে প্রয়োগ করে
# যদি কোনো দ্বন্দ্ব না থাকে — rebase স্বয়ংক্রিয়ভাবে সম্পূর্ণ হয়
# যদি থাকে — Git দ্বন্দ্বযুক্ত কমিটে থেমে যায়

Rebase-এর পরে, ফিচার শাখা-এ develop-এর সমস্ত কমিট এবং নিজস্ব কমিট থাকে, যা develop-এর ধারাবাহিকতা হিসাবে দেখা যায়। এটি মার্জ কমিট না তৈরি করেই fast-forward-এর মাধ্যমে develop-এ মার্জ করার অনুমতি দেয়।

ধাপে ধাপে প্রক্রিয়া

একটি বিস্তারিত উদাহরণ দেখি: একজন ডেভেলপার develop থেকে একটি ফিচার শাখা তৈরি করলেন, দুটি কমিট করলেন, এবং এই সময়ে অন্যান্য ডেভেলপাররা develop-এ তিনটি কমিট যোগ করলেন। Rebase দুটি ফিচার কমিটকে একটি নতুন অবস্থানে স্থানান্তর করবে, নতুন SHA দিয়ে তাদের কপি তৈরি করবে।

# 1. একটি feature শাখা তৈরি করুন
git checkout -b feature/payment-refactor develop

# 2. feature-এ কমিট করুন
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. develop আপডেট করুন (সহকর্মীদের কাজ)
git checkout develop
git pull

# 4. নতুন develop-এর উপরে feature-এর rebase করুন
git checkout feature/payment-refactor
git rebase develop

# 5. এখন feature fast-forward-এর মাধ্যমে মার্জ করা যেতে পারে
git checkout develop
git merge feature/payment-refactor

যদি ধাপ 4-এ দ্বন্দ্ব দেখা দেয়, Git সমস্যাযুক্ত কমিটে থেমে যায়। ডেভেলপার দ্বন্দ্ব সমাধান করে, git add চালায় এবং git rebase --continue নির্বাহ করে। একটি কমিট এড়িয়ে যেতে — git rebase --skip, সম্পূর্ণ rebase বাতিল করতে — git rebase --abort।

স্বয়ংক্রিয়ভাবে খালি কমিট এড়িয়ে যাওয়া

--empty ফ্ল্যাগ খালি কমিটের ক্ষেত্রে rebase-এর আচরণ নিয়ন্ত্রণ করে — যেসব পরিস্থিতিতে একটি কমিটের সমস্ত পরিবর্তন ইতিমধ্যে লক্ষ্য শাখায় বিদ্যমান। ডিফল্টভাবে, rebase থেমে যায় এবং সিদ্ধান্ত চায়। --empty=drop-এর সাথে, Git স্বয়ংক্রিয়ভাবে এই জাতীয় কমিট না থেমে এড়িয়ে যায়, যা বিপুল সংখ্যক কমিটের সাথে ব্যাপক রিবেজিং দ্রুত করে।

ইন্টারেক্টিভ Rebase

ইন্টারেক্টিভ rebase (git rebase -i) কমিট ইতিহাস সম্পাদনার জন্য একটি শক্তিশালী টুল। এটি কমিট এবং কী কমান্ডের তালিকা সহ একটি এডিটর খোলে: pick (রাখুন), reword (বার্তা পরিবর্তন), edit (বিষয়বস্তু পরিবর্তন), squash (পূর্ববর্তীর সাথে মার্জ), fixup (বার্তা ছাড়া মার্জ), drop (মুছে ফেলুন)।

# শেষ 4 কমিটের ইন্টারেক্টিভ rebase
git rebase -i HEAD~4

# এডিটর rebase পরিকল্পনা নিয়ে খুলবে:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# পরিবর্তন করুন:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

ফলাফল: তিনটি কমিট (লগইন স্ক্রিন, ভ্যালিডেশন, লেআউট) একটি কমিটে সংকুচিত হয় এবং মন্তব্য সহ কমিটটি মুছে ফেলা হয়। এটি খসড়া এবং সংশোধন ছাড়াই কোড পর্যালোচনার জন্য একটি পরিষ্কার ইতিহাস জমা দেওয়ার অনুমতি দেয়। Pull Request-এর আগে ফিচার শাখা প্রস্তুত করার জন্য ইন্টারেক্টিভ rebase একটি মানক টুল।

Rebase vs Merge: তুলনা

Rebase এবং Merge একই সমস্যার সমাধান করে — পরিবর্তনগুলি একীভূত করা — কিন্তু মৌলিকভাবে ভিন্ন উপায়ে। তাদের মধ্যে পছন্দ নির্ভর করে আপনি git log-এ কী ধরনের ইতিহাস দেখতে চান এবং আপনার শাখার সাথে আর কে কাজ করছে।

ব্যবহারিক নিয়ম: শেয়ার্ড শাখায় (develop, main) একীকরণের জন্য merge ব্যবহার করুন এবং ব্যক্তিগত ফিচার শাখা হালনাগাদ করতে rebase ব্যবহার করুন। অনেক দল দুটোই একত্রিত করে: develop-এ ফিচারের rebase, তারপর develop-এ --no-ff merge।

git bisect-এ প্রভাব

Git bisect হল সেই কমিট খুঁজে বের করার টুল যা একটি রিগ্রেশন এনেছে। merge ব্যবহার করার সময়, git bisect উভয় প্যারেন্ট বিবেচনা করে মার্জ কমিটের মাধ্যমে সঠিকভাবে অতিক্রম করে। rebase-এর সাথে, bisect দ্রুত কাজ করে কারণ ইতিহাস রৈখিক এবং শাখাকরণের প্রয়োজন হয় না। তবে, যদি কমিটগুলি দলের কাছে পরিচিত হওয়ার পরে rebase করা হয়, মূল SHA হারিয়ে যায় এবং bisect সমস্যাযুক্ত কমিট খুঁজে নাও পেতে পারে।

কখন Rebase ব্যবহার করবেন

Rebase তিনটি পরিস্থিতিতে সর্বোত্তম: Pull Request-এর জন্য ফিচার শাখা প্রস্তুত করা, main/develop-এর বর্তমান অবস্থায় ব্যক্তিগত শাখা হালনাগাদ করা এবং মার্জের আগে ইতিহাস পরিষ্কার করা। প্রতিটি ক্ষেত্রে, rebase টিমওয়ার্কের ঝুঁকি ছাড়াই ইতিহাস পঠনযোগ্যতা উন্নত করে।

Pull Request-এর আগে, খসড়া কমিট (WIP, পর্যালোচনা-পরবর্তী সংশোধন) অর্থপূর্ণ যৌক্তিক ইউনিটে একত্রিত করতে ইন্টারেক্টিভ rebase করার পরামর্শ দেওয়া হয়। এটি কোড পর্যালোচনা সহজ করে: পর্যালোচক 15টি ছোট কমিট নয়, বরং স্পষ্ট বার্তা সহ 3-5টি কাঠামোবদ্ধ পরিবর্তন দেখেন।

ফিচার শাখা হালনাগাদ করার জন্য, rebase merge-এর চেয়ে ভাল কারণ এটি অপ্রয়োজনীয় মার্জ কমিট তৈরি করে না। আপনি যদি পর্যায়ক্রমে ফিচার শাখার ভিতরে git rebase develop চালান, চূড়ান্ত মার্জে 10টি মার্জ কমিটের ক্যাসকেড থাকবে না — develop-এর উপরে কেবল পরিষ্কার ফিচার কমিট থাকবে।

মার্জের আগে ইন্টারেক্টিভ rebase-এর মাধ্যমে ইতিহাস পরিষ্কার করা ছোট সংশোধন (টাইপো, ফরম্যাটিং) লুকাতে এবং কার্যকারিতা অনুযায়ী কমিট গ্রুপ করতে দেয়। Git বার্তাগুলিকে Conventional Commits কনভেনশন (fix:, feat:, refactor:, docs:) অনুসরণ করা উচিত, যা একটি স্বয়ংক্রিয় changelog তৈরি করে।

Rebase-এর ঝুঁকি এবং নিয়ম

Rebase একটি বিপজ্জনক অপারেশন যদি ভুলভাবে প্রয়োগ করা হয়। প্রধান ঝুঁকি হল প্রকাশিত ইতিহাস পুনরায় লেখা। যদি কোনো ডেভেলপার এমন একটি শাখার rebase করে যা অন্যরা ইতিমধ্যে push করেছে এবং ব্যবহার করছে, তাদের স্থানীয় কপিগুলি অসমঞ্জস হয়ে যাবে এবং তাদের ডেটা হারানোর ঝুঁকি নিয়ে force-pull করতে হবে।

• সোনালী নিয়ম: কখনই সেই কমিটগুলির rebase করবেন না যা ইতিমধ্যে শেয়ার্ড রিপোজিটরিতে বিদ্যমান। এটি টিমের অন্যান্য সদস্যদের অ্যাক্সেসযোগ্য যেকোনো শাখার ক্ষেত্রে প্রযোজ্য
• Force push: স্থানীয় ফিচার শাখার rebase-এর পরে, --force-with-lease ফ্ল্যাগ সহ push প্রয়োজন, যা --force থেকে নিরাপদ কারণ এটি পরীক্ষা করে যে সerver-এ কেউ শাখাটি আপডেট করেছে কিনা
• প্রসঙ্গ হারানো: rebase কখন এবং কোন শাখা থেকে ফিচার শাখা তৈরি করা হয়েছিল সে সম্পর্কে তথ্য ধ্বংস করে। যদি শাখা তৈরির তারিখ সংরক্ষণ করা গুরুত্বপূর্ণ হয়, merge ব্যবহার করুন
• দ্বন্দ্ব: rebase-এর সময়, প্রতিটি কমিটের জন্য আলাদাভাবে দ্বন্দ্ব সমাধান করতে হবে, যা বিপুল সংখ্যক কমিটের সাথে ক্লান্তিকর হতে পারে

ঝুঁকি কমানোর জন্য, এই নিয়ম অনুসরণ করুন: কেবল ব্যক্তিগত শাখার জন্য rebase করুন যা প্রকাশিত হয়নি। যদি একটি শাখা ইতিমধ্যে শেয়ার্ড রিপোজিটরিতে থাকে, --no-ff সহ merge ব্যবহার করুন। যদি আপনার কোনো প্রকাশিত শাখা rebase করার প্রয়োজন হয়, দলকে সতর্ক করুন এবং আগেই force push সমন্বয় করুন।

বিপজ্জনক rebase-এর বিরুদ্ধে স্বয়ংক্রিয় সুরক্ষা সার্ভার-সাইড hooks-এর মাধ্যমে বাস্তবায়িত হয়: Git সার্ভারে pre-receive hook পরীক্ষা করতে পারে যে push প্রকাশিত কমিট পুনরায় লেখে কিনা। GitHub এবং GitLab সুরক্ষিত শাখার জন্য অন্তর্নির্মিত সুরক্ষা প্রদান করে — force push ব্লক করা থাকে যতক্ষণ না প্রশাসক সুরক্ষা অপসারণ করেন।