ব্রাঞ্চ মার্জ করা — এটি কী, একত্রীকরণের পদ্ধতি এবং দ্বন্দ্ব সমাধান

Git-এ মার্জ কী

Git-এ মার্জ হল দুই বা ততোধিক ডেভেলপমেন্ট ইতিহাসকে একটিতে একত্রিত করার অপারেশন। যখন একজন ডেভেলপার একটি ব্রাঞ্চ মার্জ করেন, Git স্বয়ংক্রিয়ভাবে সাধারণ পূর্বপুরুষ (base commit) খুঁজে পায় এবং একটি নতুন মার্জ commit তৈরি করে যা উভয় ব্রাঞ্চের পরিবর্তন অন্তর্ভুক্ত করে। Three-way merge হল মানক অ্যালগরিদম যা তিনটি অবস্থা তুলনা করে: সাধারণ পূর্বপুরুষ, প্রথম ব্রাঞ্চ এবং দ্বিতীয় ব্রাঞ্চ।

মার্জ প্রক্রিয়া git merge কমান্ড দিয়ে শুরু হয়। Git ব্রাঞ্চগুলির বিচ্ছিন্নতার বিন্দু নির্ধারণ করে এবং উৎস ব্রাঞ্চ থেকে লক্ষ্য ব্রাঞ্চে ক্রমান্বয়ে পরিবর্তন প্রয়োগ করে। যদি পরিবর্তনগুলি দ্বন্দ্ব না করে, Git সেটিংস অনুযায়ী fast-forward বা merge commit তৈরি করে। Fast-forward হল একটি পরিস্থিতি যেখানে লক্ষ্য ব্রাঞ্চটি উৎস ব্রাঞ্চের commits-এ চলে যায়।

# লক্ষ্য ব্রাঞ্চে সুইচ করুন এবং মার্জ করুন
git checkout main
git merge feature/payment-module

# স্পষ্ট no-fast-forward সহ মার্জ করুন
git merge --no-ff feature/payment-module

# দ্বন্দ্ব খুব জটিল হলে মার্জ বাতিল করুন
git merge --abort

--no-ff ফ্ল্যাগ (no fast-forward) fast-forward সম্ভব হলেও merge commit তৈরি করতে বাধ্য করে। এটি তথ্য সংরক্ষণ করে যে পরিবর্তনগুলি একটি পৃথক ব্রাঞ্চে করা হয়েছিল। অনেক দল স্পষ্টভাবে ব্রাঞ্চিং ইতিহাস বজায় রাখতে এই পদ্ধতি পছন্দ করে।

ব্রাঞ্চ একত্রীকরণের পদ্ধতি

Git-এ ব্রাঞ্চ একত্রীকরণের তিনটি প্রধান কৌশল রয়েছে, প্রতিটি নির্দিষ্ট পরিস্থিতির জন্য উপযুক্ত। কৌশলের পছন্দ দলের সংস্কৃতি এবং প্রকল্পের ইতিহাসের পরিচ্ছন্নতার প্রয়োজনীয়তার উপর নির্ভর করে।

Standard merge দুটি পিতা-মাতা সহ merge commit তৈরি করে। সম্পূর্ণ ইতিহাস সংরক্ষিত হয়, কিন্তু ব্রাঞ্চিং গ্রাফ আরও জটিল হয়ে যায়। Squash merge ফিচার ব্রাঞ্চের সমস্ত commit একটি করে একত্রিত করে এবং লক্ষ্য ব্রাঞ্চের উপরে প্রয়োগ করে — ইতিহাস রৈখিক এবং পরিষ্কার হয়, কিন্তু মধ্যবর্তী পর্যায়ের তথ্য হারিয়ে যায়।

Rebase, যদিও সম্পূর্ণ মার্জ নয়, একই ফলাফল অর্জন করে — একটি ব্রাঞ্চের পরিবর্তন অপরটির উপরে স্থানান্তরিত হয়। পার্থক্য হল যে ইতিহাস পুনরায় লেখা হয়: ফিচার ব্রাঞ্চের commits লক্ষ্য ব্রাঞ্চের সর্বশেষ commit-এর উপরে পুনরায় তৈরি হয়। এটি পুরোপুরি রৈখিক ইতিহাস দেয়, কিন্তু push করার সময় force push প্রয়োজন।

মার্জে দ্বন্দ্ব কীভাবে সমাধান করবেন

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

দ্বন্দ্ব সমাধান প্রক্রিয়ায় বেশ কয়েকটি ধাপ অন্তর্ভুক্ত। প্রথমে, ডেভেলপার দ্বন্দ্বযুক্ত ফাইলটি খোলে এবং ম্যানুয়ালি প্রয়োজনীয় পরিবর্তন নির্বাচন করে। শুধু একটি সংস্করণ বেছে নেওয়া নয়, বরং উভয় পরিবর্তনের যুক্তি বোঝা এবং সঠিক সিদ্ধান্ত নেওয়া গুরুত্বপূর্ণ। ফাইল সম্পাদনা করার পর, দ্বন্দ্ব মার্কারগুলি সরানো হয় এবং git add-এর মাধ্যমে staging area-তে যোগ করা হয়।

# দ্বন্দ্বযুক্ত ফাইলের তালিকা দেখুন
git status

# mergetool শুরু করুন (যেমন VS Code, IntelliJ)
git mergetool

# সমস্ত দ্বন্দ্ব সমাধান করার পর
git add .
git merge --continue

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

ভিজুয়াল মার্জ টুল ব্যবহার করা দ্বন্দ্ব সমাধানকে উল্লেখযোগ্যভাবে দ্রুত করে। VS Code, IntelliJ IDEA এবং GitKraken তিনটি প্যানেল সহ ইন্টারফেস প্রদান করে: বর্তমান ব্রাঞ্চ, আগত ব্রাঞ্চ এবং ফলাফল। git mergetool টুল প্রতিটি দ্বন্দ্বযুক্ত ফাইলের জন্য স্বয়ংক্রিয়ভাবে কনফিগার করা সম্পাদক খোলে।

জটিল দ্বন্দ্ব এড়ানোর সর্বোত্তম উপায় হল প্রধান ব্রাঞ্চের সাথে ফিচার ব্রাঞ্চের নিয়মিত সিঙ্ক্রোনাইজেশন। যদি একজন ডেভেলপার দিনে একবার main-কে তার ব্রাঞ্চে মার্জ করে, দ্বন্দ্ব ছোট এবং সহজেই সমাধানযোগ্য হবে। এক সপ্তাহ ধরে পরিবর্তন জমা করা ত্রুটির উচ্চ ঝুঁকি সহ জটিল দ্বন্দ্ব নিশ্চিত করে।

কখন merge-এর পরিবর্তে rebase ব্যবহার করবেন

Rebase এবং merge হল পরিবর্তন একত্রিত করার দুটি উপায়, এবং তাদের মধ্যে পছন্দ প্রায়ই দলে বিতর্ক সৃষ্টি করে। Rebase ইতিহাস পুনরায় লিখে একটি ব্রাঞ্চের commits অপরটির উপরে স্থানান্তরিত করে। Merge ব্রাঞ্চিং ইতিহাস সংরক্ষণ করে একটি নতুন merge commit তৈরি করে। প্রতিটি পদ্ধতির নিজস্ব সুবিধা এবং সীমাবদ্ধতা রয়েছে।

Rebase উপযুক্ত যখন একজন ডেভেলপার তার স্থানীয় ফিচার ব্রাঞ্চে কাজ করছেন এবং Pull Request তৈরি করার আগে একটি পরিষ্কার রৈখিক ইতিহাস চান। Rebase-এর পরে, সমস্ত commits অপ্রয়োজনীয় merge commit ছাড়া ক্রমানুসারে সাজানো হয়। তবে, rebase-এর জন্য force push প্রয়োজন এবং এটি সেই ব্রাঞ্চগুলিতে প্রযোজ্য নয় যেখানে একাধিক ব্যক্তি একসাথে কাজ করেন।

• Rebase — ব্যক্তিগত ফিচার ব্রাঞ্চের জন্য যেখানে পরিষ্কার ইতিহাস প্রয়োজন
• Merge — ভাগ করা ব্রাঞ্চ এবং একত্রীকরণের মুহূর্ত রেকর্ড করার জন্য
• Squash — যখন ফিচার ব্রাঞ্চে অনেক ছোট খসড়া commit থাকে

Git-এর সুবর্ণ নিয়ম: সেই commits-এ rebase ব্যবহার করবেন না যা ইতিমধ্যে ভাগ করা রিপোজিটরিতে push করা হয়েছে। এটি নিশ্চিত করে যে ভাগ করা ব্রাঞ্চের ইতিহাস অপরিবর্তিত থাকে এবং অন্যান্য ডেভেলপাররা নকল বা হারানো commit-এর মুখোমুখি হবেন না। ফিচার ব্রাঞ্চকে প্রধান ব্রাঞ্চে সংহত করতে Pull Request-এর মাধ্যমে merge ব্যবহার করুন।

ব্রাঞ্চ একত্রীকরণের সেরা অভ্যাস

সঠিক মার্জ প্রক্রিয়া স্থিতিশীল ডেভেলপমেন্টের ভিত্তি। আধুনিক দলগত কাজে, মার্জ কনসোলের মাধ্যমে নয়, বরং GitHub-এ Pull Request বা GitLab-এ Merge Request-এর মাধ্যমে করা হয়। PR কোড পর্যালোচনা, স্বয়ংক্রিয় CI পরীক্ষার মধ্য দিয়ে যায় এবং তার পরেই প্রধান ব্রাঞ্চে মার্জ করা হয়।

প্রথম অভ্যাস — সব পরীক্ষা পাস করার পরেই মার্জ করুন। CI পাইপলাইন প্রকল্প তৈরি করবে, পরীক্ষা চালাবে এবং কোডের গুণমান যাচাই করবে। যদি কমপক্ষে একটি পরীক্ষা ব্যর্থ হয়, মার্জ ব্লক হয়ে যায়। আধুনিক প্ল্যাটফর্মে (GitHub, GitLab) অন্তর্নির্মিত সুরক্ষা রয়েছে: branch protection rules CI ব্যর্থ হলে স্বয়ংক্রিয়ভাবে মার্জ ব্লক করে।

দ্বিতীয় অভ্যাস — কখনও ভাঙ্গা কোড মার্জ করবেন না। মার্জের আগে, ডেভেলপারকে নিশ্চিত করতে হবে যে তার পরিবর্তনগুলি বিল্ড ভাঙ্গে না এবং বিদ্যমান কার্যকারিতা রিগ্রেস করে না। এর জন্য স্বয়ংক্রিয় পরীক্ষা এবং কোড পর্যালোচনা বিদ্যমান।

তৃতীয় অভ্যাস — মার্জের পরে ফিচার ব্রাঞ্চ পরিষ্কার করুন। যে ব্রাঞ্চ ইতিমধ্যে মার্জ হয়েছে তা মুছে ফেলা উচিত। এটি বিভ্রান্তি এবং রিপোজিটরিতে জঞ্জাল প্রতিরোধ করে। GitHub স্বয়ংক্রিয়ভাবে PR মার্জ হওয়ার পরে ব্রাঞ্চ মুছে ফেলার প্রস্তাব দেয়, এবং রিপোজিটরি সেটিংস স্বয়ংক্রিয় মুছনের জন্য কনফিগার করা যেতে পারে।