মার্জ (Merge) — এটি কী, merge কীভাবে কাজ করে এবং মার্জিং কৌশল

Git-এ মার্জ কী

মার্জ (Merge) হল git merge কমান্ড যা নির্দিষ্ট ব্রাঞ্চ থেকে পরিবর্তনগুলিকে বর্তমান ব্রাঞ্চে একত্রিত করে। Git সাধারণ পূর্বপুরুষ (বেস কমিট) খুঁজে বের করে, পূর্বপুরুষের সাপেক্ষে প্রতিটি ব্রাঞ্চের diff গণনা করে এবং পরিবর্তনগুলির সম্মিলিত সেট ধারণকারী একটি merge-কমিট তৈরি করে। ফলাফল হল যে লক্ষ্য ব্রাঞ্চ মার্জ করা ব্রাঞ্চ থেকে সমস্ত পরিবর্তন গ্রহণ করে।

সিনট্যাক্স: লক্ষ্য ব্রাঞ্চে (যেমন, main) থাকাকালীন, git merge feature চালান। কোনো সংঘাত না থাকলে Git স্বয়ংক্রিয়ভাবে একটি merge-কমিট তৈরি করে। ডিফল্ট merge-কমিট বার্তা হল: “Merge branch 'feature' into main”। আপনি -m ফ্ল্যাগ ব্যবহার করে বার্তা পরিবর্তন করতে পারেন বা খোলা এডিটরে এটি সম্পাদনা করতে পারেন।

মার্জ একটি অ-ধ্বংসাত্মক অপারেশন। rebase-এর বিপরীতে, merge বিদ্যমান কমিটগুলিকে স্পর্শ করে না: তারা একই হ্যাশ, লেখক এবং তারিখ ধরে রাখে। এটি merge-কে সেই ব্রাঞ্চগুলি মার্জ করার একমাত্র নিরাপদ উপায় করে তোলে যেখানে একসঙ্গে多名 ডেভেলপার কাজ করছেন। যদি কিছু ভুল হয়, তাহলে git merge --abort দিয়ে merge বাতিল করা যেতে পারে।

# লক্ষ্য ব্রাঞ্চে স্যুইচ করুন
git checkout main

# ফিচার ব্রাঞ্চ মার্জ করুন
git merge feature

# ফলাফল — দুটি প্যারেন্ট সহ merge-কমিট
git log --oneline --graph

# কাস্টম বার্তা সহ মার্জ
git merge feature -m "feat: integrate authentication module"

মার্জের ধরন: regular, squash, fast-forward

Git তিনটি মার্জিং মোড সমর্থন করে যা কাঙ্ক্ষিত ফলাফলের উপর ভিত্তি করে বেছে নেওয়া হয়। রেগুলার মার্জ (ডিফল্ট) একটি merge-কমিট তৈরি করে। Squash merge ফিচার ব্রাঞ্চের সমস্ত কমিট একটিতে একত্রিত করে। Fast-forward সম্ভব হলে কমিট না তৈরি করে ব্রাঞ্চ পয়েন্টারকে এগিয়ে নিয়ে যায়। মোডের পছন্দ টিমের ওয়ার্কফ্লো এবং ইতিহাসের নিয়মের উপর নির্ভর করে।

রেগুলার মার্জ (--no-ff) — merge-fast-forward হিসাবে করা যেতে পারে এমন হলেও merge-কমিট তৈরি করে। main ব্রাঞ্চের জন্য সুপারিশ করা হয়: merge-কমিট স্পষ্টভাবে ফিচার ইন্টিগ্রেশন পয়েন্ট চিহ্নিত করে এবং একটি merge-কমিট revert-এর মাধ্যমে সমস্ত ফিচার ব্রাঞ্চ পরিবর্তন সহজেই পূর্বাবস্থায় ফিরিয়ে আনা যায়। GitHub Merge বাটনের মাধ্যমে PR মার্জ করার সময় ডিফল্টরূপে এই মোড ব্যবহার করে।

Squash merge (--squash) — ফিচার ব্রাঞ্চের সমস্ত কমিট লক্ষ্য ব্রাঞ্চে একটি একক কমিটে সংগ্রহ করে। উপযোগী যখন ফিচার ব্রাঞ্চের খসড়া ইতিহাস main-কে দূষিত করা উচিত নয়। ত্রুটি: মূল কমিটগুলির সাথে যোগাযোগ হারিয়ে যায় — আপনি দেখতে পারেন না কিভাবে ফিচারটি ধাপে ধাপে বিকশিত হয়েছে। GitHub PR-এ “Squash and merge” নির্বাচন করলে এই মোড ব্যবহার করে।

Fast-forward (--ff) — যদি ফিচার ব্রাঞ্চ বিচ্ছিন্ন হওয়ার পর লক্ষ্য ব্রাঞ্চে কোনো নতুন কমিট না থাকে, তাহলে Git merge-কমিট না তৈরি করে পয়েন্টারকে এগিয়ে নিয়ে যায়। ইতিহাস রৈখিক থাকে। --no-ff ফ্ল্যাগ merge-কমিটকে বাধ্য করে, যেখানে --ff-only ত্রুটি দেবে যদি fast-forward সম্ভব না হয়।

# Merge-কমিট বাধ্য করুন (main-এর জন্য সুপারিশকৃত)
git merge --no-ff feature

# Squash merge — সমস্ত কমিট একটিতে
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward কেবল যদি সম্ভব হয়
git merge --ff-only feature

# সংঘাতপূর্ণ মার্জ বাতিল করুন
git merge --abort

Git মার্জিং কৌশল

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

Recursive — দুটি ব্রাঞ্চ মার্জ করার জন্য ডিফল্ট কৌশল। Git সাধারণ পূর্বপুরুষ খুঁজে বের করে, প্রতিটি ব্রাঞ্চের পরিবর্তন গণনা করে এবং সেগুলি মার্জ করে। যদি একটি সাধারণ পূর্বপুরুষ পাওয়া যায়, recursive ফাইল পুনঃনামকরণ এবং সংযোজন সঠিকভাবে পরিচালনা করে। সংঘাতের সময়, recursive অতিরিক্ত বিকল্প ব্যবহার করতে পারে: ours (স্বয়ংক্রিয়ভাবে আমাদের সংস্করণ বেছে নিন) এবং theirs (তাদের সংস্করণ বেছে নিন)।

Octopus — একসঙ্গে দুটির বেশি ব্রাঞ্চ মার্জ করার জন্য: git merge feature1 feature2 feature3। Octopus সংঘাত সমাধান সমর্থন করে না — কমান্ড কল করার আগে সমস্ত সংঘাত সমাধান করতে হবে। এটি খুব কমই ব্যবহৃত হয়, প্রধানত বেশ কয়েকটি স্বাধীন ব্রাঞ্চ মার্জ করার জন্য যা সংঘাত না হওয়ার নিশ্চয়তা দেয় (যেমন, বিভিন্ন মডিউল)।

Ours — একটি বিশেষ কৌশল যা মার্জ করা ব্রাঞ্চের পরিবর্তনগুলি সম্পূর্ণরূপে উপেক্ষা করে এবং লক্ষ্য ব্রাঞ্চের বর্তমান বিষয়বস্তু ধরে রাখে। একটি merge-কমিট তৈরি করা হয়, কিন্তু বিষয়বস্তু অপরিবর্তিত থাকে। উপযোগী যখন আপনাকে ইতিহাসে মার্জের ঘটনা রেকর্ড করতে হবে কিন্তু প্রকৃতপক্ষে অন্য ব্রাঞ্চের সমস্ত পরিবর্তন প্রত্যাখ্যান করতে হবে।

মার্জ সংঘাত সমাধান

মার্জ সংঘাত (Merge conflict) ঘটে যখন একটি ফাইলের একই লাইন উভয় ব্রাঞ্চে ভিন্নভাবে পরিবর্তিত হয়। Git স্বয়ংক্রিয়ভাবে নির্ধারণ করতে পারে না কোন সংস্করণ সঠিক এবং merge স্থগিত করে। সংঘাত তখনও হতে পারে যখন একটি ফাইল এক ব্রাঞ্চে পুনঃনামকরণ করা হয় এবং অন্যটিতে সংশোধন করা হয়, বা যখন একই ফাইল একসঙ্গে মুছে ফেলা এবং সংশোধন করা হয়।

সমাধান প্রক্রিয়া: Git সংঘাতপূর্ণ ফাইলগুলিকে চিহ্নিতকারী দিয়ে চিহ্নিত করে। ফাইলে <<<<<<< HEAD (আমাদের সংস্করণ), ======= (বিভাজক), এবং >>>>>>> feature (তাদের সংস্করণ) সহ বিভাগগুলি দেখায়। ডেভেলপার ম্যানুয়ালি সংঘাতপূর্ণ বিভাগ সম্পাদনা করে, উভয় সংস্করণ থেকে পছন্দসই লাইন নির্বাচন করে, চিহ্নিতকারীগুলি সরিয়ে ফেলে, ফাইল সংরক্ষণ করে এবং git add দিয়ে এটি ইনডেক্সে যোগ করে।

সংঘাতের দৃশ্যমান সমাধানের জন্য, Git mergetool সমর্থন করে — একটি বাহ্যিক তুলনা সরঞ্জাম। জনপ্রিয় mergetool: Meld, KDiff3, Beyond Compare, VS Code (অন্তর্নির্মিত সংঘাত সম্পাদক)। Mergetool তিনটি প্যানেল প্রদর্শন করে: আমাদের সংস্করণ, তাদের সংস্করণ এবং ফলাফল। ডেভেলপার চূড়ান্ত ফাইলে অন্তর্ভুক্ত করার জন্য দৃশ্যমানভাবে কোড ব্লক নির্বাচন করে।

# মার্জ শুরু করুন এবং সংঘাত সনাক্ত করুন
git merge feature
# সংঘাত (বিষয়বস্তু): src/main.swift-এ মার্জ সংঘাত

# সংঘাতপূর্ণ ফাইল পরীক্ষা করুন
git status

# দৃশ্যমান mergetool খুলুন
git mergetool

# সমাধানের পরে — add এবং commit
git add src/main.swift
git commit

# মার্জ বাতিল করুন
git merge --abort

কখন rebase-এর পরিবর্তে merge বেছে নেবেন

Merge rebase-এর চেয়ে পছন্দনীয় বেশ কয়েকটি মূল পরিস্থিতিতে। প্রথম: অন্যান্য ডেভেলপারদের জন্য অ্যাক্সেসযোগ্য পাবলিক ব্রাঞ্চ নিয়ে কাজ করার সময়। Merge ইতিহাস পুনরায় লেখে না, তাই সহকর্মীরা নিরাপদে সিঙ্ক্রোনাইজ করতে পারেন। পাবলিক ব্রাঞ্চে rebase করলে বিভক্ত ইতিহাস তৈরি হয় এবং যাদের কাছে ইতিমধ্যে পুরানো কমিট আছে তাদের জন্য সংঘাত সৃষ্টি করে।

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

তৃতীয় পরিস্থিতি: পর্যালোচিত pull request নিয়ে কাজ করার সময়। GitHub এবং GitLab বিভিন্ন বিকল্প সহ একটি merge বাটন অফার করে। Merge (Create a merge commit) — merge-কমিট সহ সম্পূর্ণ ইতিহাস। Squash and merge — উন্নয়ন বিবরণ ছাড়া পরিষ্কার ইতিহাস। Rebase and merge — merge-কমিট ছাড়া রৈখিক ইতিহাস, কিন্তু কমিট পুনর্লিখন সহ। পছন্দ টিমের নিয়মের উপর নির্ভর করে।

• পাবলিক ব্রাঞ্চ (main, develop) — শুধুমাত্র merge, কখনও rebase নয়।
• PR সমাপ্তি — ইন্টিগ্রেশন পয়েন্ট চিহ্নিত করতে --no-ff সহ merge।
• অন্যের কমিট সহ ব্রাঞ্চ — merge অন্যের কাজ পুনরায় লেখে না।
• রিলিজের আগে — merge বেশি নিরাপদ কারণ এতে কম ঝুঁকি রয়েছে।
• ভাগ করা ব্রাঞ্চ — যদি একাধিক ডেভেলপার একটি ব্রাঞ্চে কাজ করেন, merge বাধ্যতামূলক।

ব্রাঞ্চ মার্জিংয়ের সেরা অভ্যাস

প্রথম নিয়ম: মার্জ করার আগে সর্বদা লক্ষ্য ব্রাঞ্চের সর্বশেষ সংস্করণে থাকুন। ফিচার ব্রাঞ্চ মার্জ করার আগে git checkout main && git pull চালান। এটি সংঘাত হ্রাস করে এবং নিশ্চিত করে যে merge-কমিটে সমস্ত সর্বশেষ পরিবর্তন রয়েছে। যদি লক্ষ্য ব্রাঞ্চ উল্লেখযোগ্যভাবে এগিয়ে যায়, প্রথমে ফিচার ব্রাঞ্চের ভিতরে git merge main চালান যাতে তার প্রসঙ্গে সংঘাত সমাধান করা যায়।

দ্বিতীয় নিয়ম: মার্জের পরে কোড পরীক্ষা করুন। মার্জ আচরণ পরিবর্তন করতে পারে এমনকি যদি কোনো সংঘাত না থাকে। CI/CD পাইপলাইনের উচিত প্রোডাকশনে পাঠানোর আগে merge-কমিটে পরীক্ষা চালানো। কিছু টিম merge গেট ব্যবহার করে — বাধ্যতামূলক চেক যা পাস না হওয়া পর্যন্ত merge ব্লক করে।

তৃতীয় নিয়ম: merge-কমিট ডকুমেন্ট করুন। মানক বার্তা “Merge branch 'feature' into main” খুব একটা উপযোগী নয়। কী মার্জ করা হয়েছে তার বিবরণ যোগ করার পরামর্শ দেওয়া হয়: “Merge authentication module: login, registration, password recovery”। এটি ইতিহাস বিশ্লেষণ এবং রিগ্রেশন অনুসন্ধান সহজ করে। বড় প্রকল্পগুলিতে, merge-কমিট স্বয়ংক্রিয়ভাবে PR শিরোনাম থেকে উত্পন্ন হয়।

• হালনাগাদ — মার্জ করার আগে, নিশ্চিত করুন লক্ষ্য ব্রাঞ্চ আপডেটেড (git pull)।
• পরীক্ষা — CI/CD-র উচিত ফলস্বরূপ merge-কমিটে পরীক্ষা চালানো।
• বর্ণনামূলক বার্তা — merge-কমিটে উল্লেখ করুন কোন ফিচার মার্জ করা হয়েছে।
• ফ্রিকোয়েন্সি — ফিচার ব্রাঞ্চ যথাসম্ভব দ্রুত এবং প্রায়ই মার্জ করুন (সর্বোচ্চ এক সপ্তাহ)।
• পূর্বাবস্থা — merge-কমিটের git revert সম্পূর্ণ ফিচার ফিরিয়ে আনে।