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

অপারেশনটি নিশ্চিত করুন এবং অসমাপ্ত সম্পাদনাগুলো সুরক্ষিত রাখুন

Terminal বা আপনার এডিটরের সমন্বিত টার্মিনাল খুলুন, রিপোজিটরিতে যান এবং এর স্থিতি পরীক্ষা করুন:

cd "/path/to/repository"
git status

উদাহরণের পরিবর্তে প্রকৃত ফোল্ডার পাথ ব্যবহার করুন। Git-এর স্ট্যাটাস আপনাকে জানিয়ে দেয় কোন ফাইলগুলো অমীমাংসিত এবং অপারেশনটি একটি মার্জ, রিব্যাস নাকি অন্য কোনো অ্যাকশন। এই নিবন্ধটি মার্জ প্রক্রিয়া নিয়ে আলোচনা করে। সাধারণ মার্জের ক্ষেত্রে, আপনি যতক্ষণ না দ্বন্দ্বগুলো সমাধান করছেন, ততক্ষণ Git বর্তমান শাখাকে যথাস্থানে রেখে দেয়; যেসব পাথ নির্বিঘ্নে মার্জ হয়েছে সেগুলো ইতিমধ্যেই আপডেট হয়ে গেছে, আর দ্বন্দ্বপূর্ণ পাথগুলোর পর্যালোচনা প্রয়োজন। Git-এর git merge ডকুমেন্টেশন

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

প্রতিটি দ্বন্দ্বকে দুটি প্রস্তাব হিসেবে বিবেচনা করুন

তালিকাভুক্ত প্রতিটি ফাইল একটি টেক্সট এডিটরে খুলুন। একটি টেক্সট দ্বন্দ্ব সাধারণত এভাবে চিহ্নিত করা হয়:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

=======-এর উপরের টেক্সটটি সাধারণত বর্তমান শাখার সংস্করণ; আর এর নিচের টেক্সটটি সাধারণত যে শাখাটি মার্জ করা হচ্ছে তার সংস্করণ। লেবেলগুলো ভিন্ন হতে পারে। Git ইনডেক্সে সাধারণ উৎস (common ancestor) এবং উভয় শাখার সংস্করণ রেকর্ড করে, এবং কার্যকারী ফাইলটিতে দ্বন্দ্ব-চিহ্নিত ফলাফল দেখায় যাতে আপনি তা সম্পাদনা করতে পারেন। Git-এর মার্জ ডকুমেন্টেশন

এই দুটি অংশকে পরিবর্তনের উদ্দেশ্য বোঝার প্রমাণ হিসেবে বিবেচনা করুন, এমন কোনো বিকল্প হিসেবে নয় যা আপনাকে পুরোপুরি মেনে নিতে হবে। প্রতিটি সম্পাদনার মাধ্যমে কী অর্জন করার চেষ্টা করা হয়েছিল তা বোঝার চেষ্টা করুন। এক পক্ষ হয়তো একটি যাচাইকরণ শর্ত (validation condition) যুক্ত করেছে এবং অন্য পক্ষ একটি ফিল্ডের নাম পরিবর্তন করেছে; উভয়টি রক্ষা করার অর্থ হতে পারে সেগুলোকে একটি আপডেট করা শর্তে একত্রিত করা। ফাইল-স্তরের দ্বন্দ্বের ক্ষেত্রে, যেমন এক পক্ষ একটি ফাইল মুছে ফেলেছে এবং অন্য পক্ষ এটি সম্পাদনা করেছে, সেক্ষেত্রে ফাইলটি রাখা উচিত কিনা তা নির্ধারণ করুন এবং প্রয়োজন হলে প্রয়োজনীয় সম্পাদনাগুলো অন্তর্ভুক্ত করুন। লাইনগুলো দেখে উদ্দেশ্য স্পষ্ট না হলে, সিদ্ধান্ত নেওয়ার আগে আশেপাশের কোড পরীক্ষা করুন বা পরিবর্তনের লেখকের সাথে কথা বলুন।

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

সমাধান করা ফাইলগুলো পর্যালোচনা ও স্টেজ করুন

সম্পাদিত ফাইলটি সংরক্ষণ করুন, তারপর পরিবর্তনগুলো পর্যালোচনা করুন। কোনো দ্বন্দ্বপূর্ণ ফাইলের ক্ষেত্রে, git diff আপনার ওয়ার্কিং ট্রিতে এখনও বিদ্যমান দ্বন্দ্ব-সমাধানের কাজটি দেখায়। শুধু চিহ্নিত লাইনগুলো নয়, আশেপাশের সম্পূর্ণ প্রসঙ্গটি পরীক্ষা করুন। আপনার এডিটরের সার্চ ফাংশন দিয়ে অবশিষ্ট মার্কারগুলো খুঁজুন, অথবা রিপোজিটরিতে এই কমান্ডটি ব্যবহার করুন:

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

যদি এটি মিল খুঁজে পায়, সেগুলো পর্যালোচনা করুন: বৈধ ডকুমেন্টেশন বা টেস্ট ফিক্সচারে এই স্ট্রিংগুলো থাকতে পারে, তাই বাছবিচার না করে সেগুলো মুছবেন না। একটি ফাইলের ফলাফল ঠিক হয়ে গেলে, git add-এ কোটেশনসহ পাথ দিয়ে ফাইলটি স্টেজ করুন, উদাহরণস্বরূপ git add "Sources/Example.swift"। স্টেজ করার মাধ্যমে Git-কে জানানো হয় যে ফাইলটির দ্বন্দ্ব সমাধান করা হয়েছে; তবে এটি প্রমাণ করে না যে ফলাফলটি সঠিক। Git-এর নির্দেশনা হলো প্রতিটি দ্বন্দ্ব সম্পাদনা করা, সমাধান করা পাথগুলো যুক্ত করা এবং তারপর মার্জ কমিট করা বা চালিয়ে যাওয়া। Git মার্জ ডকুমেন্টেশন

Mac-এ ভিজ্যুয়াল ওয়ার্কফ্লোর জন্য, Visual Studio Code-এর Source Control-এর Merge Changes-এর অধীনে দ্বন্দ্বপূর্ণ ফাইলগুলোর তালিকা দেখায়। একটি ফাইল খুলুন এবং বর্তমান দিক, আগত দিক এবং ফলাফল পর্যালোচনা করতে এর ইনলাইন দ্বন্দ্ব অ্যাকশন বা Open in Merge Editor ব্যবহার করুন। এডিটরের Accept Both Changes অ্যাকশনটি উভয় বিভাগকে পরপর রাখে; ফলস্বরূপ ফাইলটি পর্যালোচনা করুন এবং প্রয়োজন অনুসারে বিষয়বস্তু একত্রিত বা সামঞ্জস্য করুন। ফলাফল সংরক্ষণ করুন এবং Source Control-এ ফাইলটি স্টেজ করুন। এই নিয়ন্ত্রণগুলো VS Code-এর নিজস্ব; অন্যান্য এডিটর ভিন্ন লেবেল বা বৈশিষ্ট্য ব্যবহার করতে পারে। VS Code-এর মার্জ দ্বন্দ্ব নির্দেশিকা

মার্জ সম্পন্ন করুন এবং ফলাফল যাচাই করুন

প্রতিটি দ্বন্দ্বপূর্ণ ফাইল সমাধান এবং স্টেজ করার পরে, স্থিতিটি আবার পরীক্ষা করুন:

git status
git diff --cached

স্টেজ করা diff পর্যালোচনা করে নিশ্চিত করুন যে উভয় পক্ষের উদ্দেশ্যমূলক অবদান একটি অর্থপূর্ণ চূড়ান্ত আকারে উপস্থিত রয়েছে এবং কোনো সম্পর্কহীন সম্পাদনা অন্তর্ভুক্ত করা হয়নি। প্রযোজ্য হলে প্রকল্পের প্রাসঙ্গিক পরীক্ষাগুলো চালান; সমন্বিত লজিকটি আশানুরূপ কাজ করছে কিনা তা Git নিজে নির্ধারণ করতে পারে না।

কমান্ড-লাইনের মাধ্যমে মার্জ করার ক্ষেত্রে, git merge --continue দিয়ে অপারেশনটি সম্পন্ন করুন (অথবা Git নির্দেশ দিলে মার্জটি কমিট করুন)। Git-এর --continue বিকল্পটি কমিট তৈরির আগে মার্জ প্রক্রিয়াধীন রয়েছে কিনা তা যাচাই করে। তারপর মার্জটি আর প্রক্রিয়াধীন নেই তা নিশ্চিত করতে আবার git status চালান। Git যদি আরও দ্বন্দ্বের রিপোর্ট করে, তবে সেই ফাইলগুলোও সমাধান করুন এবং স্টেজ করুন। Git-এর মার্জ নির্দেশাবলী

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

সূত্র