মার্জ — এটি কী, মার্জের প্রকার এবং কার্যপ্রণালী

মার্জ কী?

মার্জ Git-এর একটি মৌলিক অপারেশন যা একটি ব্রাঞ্চ (উৎস) থেকে অন্য ব্রাঞ্চে (লক্ষ্য) পরিবর্তনগুলিকে একত্রিত করে। মার্জের ফলস্বরূপ, লক্ষ্য ব্রাঞ্চ উৎস ব্রাঞ্চের সেই সব কমিট পায় যা এখনও এতে ছিল না। পরিস্থিতির উপর নির্ভর করে, Git তিনটি ভিন্ন উপায়ে মার্জ সম্পাদন করতে পারে।

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

GitLab Flow অনুসারে, Git-এর সাথে কাজ করা 73% টিম মার্জ কমিট ব্যবহার করে। বিকল্প পদ্ধতি (রিবেস, স্কোয়াশ) সেই টিমগুলি পছন্দ করে যারা রৈখিক ইতিহাসের উপর কেন্দ্রীভূত। কৌশলের পছন্দ টিমের আকার, রিলিজ ফ্রিকোয়েন্সি এবং প্রকল্পে গৃহীত নিয়মাবলীর উপর নির্ভর করে।

কখন মার্জ প্রয়োজন

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

মার্জ ছাড়া, Git-এ একক কোডবেসে সহযোগিতামূলকভাবে কাজ করা অসম্ভব। প্রতিবার যখন দুই ডেভেলপার একই সময়ে একটি কোডবেসে পরিবর্তন করে, তাদের ব্রাঞ্চগুলি বিচ্যুত হয়। মার্জই ডেটা ক্ষতি ছাড়া এই পরিবর্তনগুলি ফিরিয়ে আনার একমাত্র উপায়।

Git-এ মার্জের প্রকার

Git তিন ধরনের মার্জ সমর্থন করে, প্রতিটি নিজস্ব দৃশ্যকল্পের জন্য ডিজাইন করা হয়েছে। মার্জের প্রকারের পছন্দ কমিট ইতিহাস, রোলব্যাক সুবিধা এবং লগ পঠনযোগ্যতাকে প্রভাবিত করে।

ফাস্ট-ফরোয়ার্ড মার্জ

ফাস্ট-ফরোয়ার্ড ঘটে যখন লক্ষ্য ব্রাঞ্চে উৎস ব্রাঞ্চ তৈরি হওয়ার পর থেকে কোনো নতুন কমিট নেই। এই ক্ষেত্রে, Git কেবল লক্ষ্য ব্রাঞ্চ পয়েন্টারটিকে উৎস ব্রাঞ্চের শেষ কমিটের দিকে এগিয়ে নিয়ে যায়। ইতিহাস রৈখিক থাকে, মার্জ কমিট ছাড়া।

# ফাস্ট-ফরোয়ার্ড মার্জ: ফিচার তৈরির পর থেকে develop পরিবর্তিত হয়নি
git checkout develop
git merge feature/new-login

# ফলাফল: develop পয়েন্টার ফিচারের শেষে চলে গেছে
# কোনো মার্জ কমিট তৈরি হয়নি

ফাস্ট-ফরোয়ার্ড স্বল্পস্থায়ী ব্রাঞ্চের জন্য সুবিধাজনক যেখানে একজন ডেভেলপার একা কাজ করে। কিন্তু এই পদ্ধতির একটি ত্রুটি রয়েছে: ব্রাঞ্চের অস্তিত্বের তথ্য হারিয়ে যায় — সব কমিট দেখে মনে হয় যেন সরাসরি develop-এ করা হয়েছে।

থ্রি-ওয়ে মার্জ

থ্রি-ওয়ে মার্জ সম্পাদিত হয় যখন বিচ্যুতি বিন্দুর পর উভয় ব্রাঞ্চেই নতুন কমিট থাকে। Git দুই পিতামাতা সহ একটি পৃথক মার্জ কমিট তৈরি করে, যা ব্রাঞ্চ মার্জিংয়ের ঘটনা রেকর্ড করে। এই পদ্ধতিটি টিম ডেভেলপমেন্টে ফিচার ব্রাঞ্চের জন্য সুপারিশ করা হয়।

# --no-ff ফ্ল্যাগ সহ বাধ্যতামূলক থ্রি-ওয়ে মার্জ
git checkout develop
git merge --no-ff feature/new-login

# ডিফল্ট বার্তা সহ একটি মার্জ কমিট তৈরি হয়েছে
# -m এর মাধ্যমে নিজস্ব বার্তা সেট করতে পারেন
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

--no-ff ফ্ল্যাগ মার্জ কমিট তৈরির নিশ্চয়তা দেয়, এমনকি যদি ফাস্ট-ফরোয়ার্ড সম্ভব হয়। এটি একটি প্রকল্পে ব্রাঞ্চিং তথ্য সংরক্ষণের জন্য সর্বোত্তম অনুশীলন।

স্কোয়াশ মার্জ

স্কোয়াশ মার্জ উৎস ব্রাঞ্চের সব কমিটকে একটিতে সংকুচিত করে এবং লক্ষ্যে প্রয়োগ করে। ফিচারের ইতিহাস হারিয়ে যায় — সব পরিবর্তন সহ একটি কমিট ব্রাঞ্চে আসে। এটি তখন সুবিধাজনক যখন ফিচার ব্রাঞ্চে বিস্তারিত কমিট সামগ্রিক ইতিহাসে মূল্য যোগ করে না।

# স্কোয়াশ মার্জ: ফিচারের সব কমিট একটিতে সংকুচিত
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

স্কোয়াশ খসড়া, পরীক্ষামূলক ব্রাঞ্চ এবং এমন পরিস্থিতির জন্য উপযুক্ত যেখানে পরিষ্কার ইতিহাস বজায় রাখা গুরুত্বপূর্ণ। নেতিবাচক দিক — মূল কমিটের সাথে সংযোগ হারিয়ে যায়, যা পৃথক পরিবর্তন ফিরিয়ে আনা কঠিন করে তোলে।

Ours এবং Theirs কৌশল

Ours এবং Theirs Git-এ দুটি বিশেষ মার্জ কৌশল। Ours উৎস ব্রাঞ্চের পরিবর্তনগুলি সম্পূর্ণরূপে উপেক্ষা করে, শুধু লক্ষ্যে যা আছে তা রাখে। Theirs, বিপরীতভাবে, যেকোনো কনফ্লিক্টে উৎস ব্রাঞ্চের সংস্করণ গ্রহণ করে। এই কৌশলগুলি বড় পরিমাণ কোড মার্জ করার সময় উপযোগী যখন আগে থেকেই জানা থাকে কোন সংস্করণটি প্রাধান্য পাবে।

মার্জ কীভাবে কাজ করে

Git-এ মার্জ মেকানিজম তিনটি বিন্দুর তুলনার উপর ভিত্তি করে: সাধারণ পূর্বপুরুষ (মার্জ বেস), উৎস ব্রাঞ্চের অবস্থা এবং লক্ষ্য ব্রাঞ্চের অবস্থা। Git মার্জ বেস খুঁজে পায় — উভয় ব্রাঞ্চের জন্য সাধারণ শেষ কমিট — এবং গণনা করে বিচ্যুতির পর প্রতিটি ব্রাঞ্চে কী পরিবর্তন হয়েছে।

• ধাপ 1 — Git মার্জ বেস নির্ধারণ করে: উভয় ব্রাঞ্চে থাকা শেষ কমিট
• ধাপ 2 — Git দুটি ডিফ তৈরি করে: মার্জ বেস থেকে উৎস পর্যন্ত এবং মার্জ বেস থেকে লক্ষ্য পর্যন্ত
• ধাপ 3 — Git পরিবর্তনের উভয় সেট মার্জ বেসে প্রয়োগ করার চেষ্টা করে
• ধাপ 4 — যদি পরিবর্তনগুলি বিরোধপূর্ণ না হয় — মার্জ স্বয়ংক্রিয়ভাবে সম্পন্ন হয়
• ধাপ 5 — যদি কনফ্লিক্ট থাকে — Git থেমে যায় এবং সমাধানের অনুরোধ করে

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

মার্জ কাজের উদাহরণ

একটি দৃশ্যকল্প বিবেচনা করুন: দুই ডেভেলপার একটি ফিচার ব্রাঞ্চে ভিন্ন ভিন্ন ফাইলে কাজ করছেন। প্রথমজন LoginActivity.kt পরিবর্তন করলেন, দ্বিতীয়জন ProfileFragment.kt পরিবর্তন করলেন। যখন তারা তাদের পরিবর্তনগুলি মার্জ করেন, Git দেখে যে পরিবর্তনগুলি ভিন্ন ফাইলকে প্রভাবিত করেছে এবং মানুষের হস্তক্ষেপ ছাড়া স্বয়ংক্রিয়ভাবে মার্জ সম্পাদন করে।

যদি উভয় ডেভেলপার LoginActivity.kt পরিবর্তন করেন, কিন্তু ভিন্ন মেথডে — Git স্বয়ংক্রিয়ভাবেও এটি সামলাবে, পরিবর্তনগুলি লাইন ধরে লাইন মার্জ করে। কনফ্লিক্ট তখনই দেখা দেয় যখন উভয়েই একই লাইন পরিবর্তন করে বা যদি একজন কোড মুছে ফেলে যা অন্যজন পরিবর্তন করেছে।

মার্জ কনফ্লিক্ট সমাধান

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

কনফ্লিক্ট এলাকা বিশেষ মার্কার দিয়ে চিহ্নিত করা হয়: <<<<<<< HEAD লক্ষ্য ব্রাঞ্চের কোড দেখায়, ======= বিভাজক, >>>>>>> source-branch উৎস ব্রাঞ্চের কোড দেখায়। ডেভেলপারকে ম্যানুয়ালি বেছে নিতে হবে কোন সংস্করণ রাখবেন বা সেগুলি একত্রিত করবেন।

# 1. মার্জ চালান এবং কনফ্লিক্ট দেখুন
git merge feature/new-login
# আউটপুট: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. কনফ্লিক্ট সহ ফাইলের তালিকা দেখুন
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. কনফ্লিক্ট সমাধান: ফাইল সম্পাদনা করুন, মার্কার সরান
# 4. সমাধান করা ফাইল যোগ করুন এবং মার্জ শেষ করুন
git add src/ui/login/LoginActivity.kt
git merge --continue
# অথবা: git commit (--continue ছাড়া)

কনফ্লিক্ট সমাধানের জন্য টুল রয়েছে: git mergetool একটি ভিজুয়াল মার্জার খোলে (Meld, Beyond Compare, VS Code)। অনেক ডেভেলপার IDE-তে কনফ্লিক্ট সমাধান করতে পছন্দ করেন — IntelliJ IDEA এবং Android Studio তিন-প্যানেল তুলনা সহ একটি অন্তর্নির্মিত টool সরবরাহ করে যা এই প্রক্রিয়াটি অনেক সহজ করে।

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

মার্জ বনাম রিবেস: কখন কী বেছে নেবেন

মার্জ এবং রিবেস এর মধ্যে পছন্দ Git-এর সবচেয়ে সাধারণ আর্কিটেকচারাল সিদ্ধান্তগুলির মধ্যে একটি। উভয় পদ্ধতিই পরিবর্তনগুলি একত্রিত করে, কিন্তু ভিন্ন উপায়ে: মার্জ ব্রাঞ্চিং ইতিহাস সংরক্ষণ করে, রিবেস ইতিহাস পুনরায় লেখে এটিকে রৈখিক করে।

• মার্জ — প্রসঙ্গ সংরক্ষণ করে: দেখা যায় কখন এবং কোন ব্রাঞ্চ থেকে মার্জ করা হয়েছিল। পাবলিক ব্রাঞ্চ (develop, main) এবং টিমওয়ার্কের জন্য ভাল
• রিবেস — অতিরিক্ত মার্জ কমিট ছাড়া পরিষ্কার রৈখিক ইতিহাস তৈরি করে। পর্যালোচনার আগে ব্যক্তিগত ফিচার ব্রাঞ্চের জন্য ভাল
• নিয়ম: কখনও পাবলিক ব্রাঞ্চ রিবেস করবেন না যা অন্য ডেভেলপাররা ব্যবহার করছে

অনেক টিম একটি হাইব্রিড পদ্ধতি ব্যবহার করে: ফিচার ব্রাঞ্চকে develop-এর সাথে আপডেট করার জন্য রিবেস (git rebase develop), তারপর মার্জ রেকর্ড করার জন্য --no-ff ফ্ল্যাগ সহ মার্জ। এটি ফিচারের ভিতরে পরিষ্কার ইতিহাস এবং develop স্তরে তথ্যপূর্ণ মার্জ পয়েন্ট দেয়।