গিট (গিট ফ্লো) এর জন্য সাধারণ কর্মপ্রবাহ বৈশিষ্ট্য শাখা ব্যবহার করে, যেখানে প্রতিটি নতুন বৈশিষ্ট্যের জন্য একটি পৃথক শাখা তৈরি করা হয়। বিকাশকারীরা এই বিচ্ছিন্ন শাখাগুলিতে নতুন কার্যকারিতা প্রয়োগ করে এবং তারপরে তাদের পরিবর্তনগুলিকে main
বা master
শাখায় একত্রিত করে।
সেই কর্মপ্রবাহের সুবিধাগুলি স্পষ্ট: QA পরিবেশে একটি পৃথক শাখা সুবিধামত স্থাপন এবং পরীক্ষা করা যেতে পারে, এবং যদি সমালোচনামূলক বাগগুলি সনাক্ত করা হয় তবে এটি কেবল main
শাখায় একত্রিত হবে না। একই শাখায় সমস্যা সংশোধন করা যেতে পারে এবং কোড উন্নত করা যেতে পারে।
এদিকে, প্রধান শাখা ক্রমাগত মোতায়েনযোগ্য এবং সেই সমস্যা থেকে সুরক্ষিত থাকে।
দুর্ভাগ্যবশত, এই কৌশলটির একটি উল্লেখযোগ্য নেতিবাচক দিক রয়েছে - একত্রীকরণ দ্বন্দ্ব। দীর্ঘজীবী শাখাগুলির সাথে, যা কিছু সময়ে অনিবার্য, এই দ্বন্দ্বগুলি সমাধান করা খুব কঠিন হতে পারে যে এটি সম্পূর্ণরূপে শাখা থেকে পরিত্রাণ পেতে এবং স্ক্র্যাচ থেকে শুরু করা সহজ হয়ে যায়।
পাশাপাশি, যখন অনেক দ্বন্দ্ব থাকে, তখন একত্রিত হওয়ার ফলাফল অপ্রত্যাশিত হতে পারে।
যাইহোক, এটি একমাত্র সম্ভাব্য কৌশল নয়, এবং এই নিবন্ধটি উপরে তালিকাভুক্ত অসুবিধাগুলি ছাড়াই নতুন পণ্য বৈশিষ্ট্যগুলি পরিচালনা করার একটি বিকল্প উপায় কভার করবে।
গিট ডিজাইন অনুসারে, একত্রীকরণের সময় একত্রীকরণ দ্বন্দ্ব ঘটে যখন শাখাগুলির একই ফাইল লাইনে বিভিন্ন বিষয়বস্তু থাকে।
এটি ব্যাখ্যা করার জন্য, আসুন একটি দৃশ্যকল্প বিবেচনা করা যাক যেখানে দুটি দল একই পরিষেবার আপডেটগুলি বাস্তবায়ন করছে। টিম A ক্রেডিট কার্ড সমর্থনকে একীভূত করছে, যখন টিম B ব্যবহারকারীর প্রোফাইল পৃষ্ঠাকে সংশোধন করছে। মনে হচ্ছে এই বৈশিষ্ট্যগুলি একে অপরের সাথে কিছু করার নেই।
যাইহোক, এটি দেখা যাচ্ছে যে পেমেন্ট-সম্পর্কিত কোডটি পূর্বে প্রোফাইল পৃষ্ঠার কোডের মতো একই জায়গায় অবস্থিত ছিল। তাই উভয় দলই তাদের কোড আলাদা আলাদা শাখায় বের করেছে এবং ইন্টিগ্রেশনটি আবার লিখেছে।
এখন প্রশ্ন হল, কে তাদের পরিবর্তনগুলিকে main
শাখায় একীভূত করবে এবং ভান করবে যে সমস্যাটি তাদের পক্ষে নেই যখন অন্য দলটি ফলে সৃষ্ট দ্বন্দ্ব সমাধানের চেষ্টা করবে?
সামগ্রিকভাবে, একত্রীকরণ দ্বন্দ্ব এড়ানো অসম্ভব, তবে আমরা অবশ্যই নিম্নলিখিত সুপরিচিত নিয়ম ব্যবহার করে সমাধান করা সহজ করতে পারি:
যদি একটি কাজ কঠিন এবং ভীতিকর হয়, তবে এটি আরও প্রায়ই করুন
গিট পদে, এর অর্থ হল আমাদের যতটা সম্ভব ঘন ঘন একত্রিত হতে হবে (আদর্শভাবে প্রতিটি প্রতিশ্রুতিতে)। এবং অবশ্যই, সেই ক্ষেত্রে দ্বন্দ্ব আরও প্রায়ই ঘটবে, তবে সেগুলি সমাধান করা আরও সহজ হবে।
একে ট্রাঙ্ক-ভিত্তিক উন্নয়ন বলা হয় এবং এর অর্থ হল পরিবর্তনগুলি সরাসরি main
শাখায় ঠেলে দেওয়া এবং অপ্রয়োজনীয় হলে শাখাগুলি ব্যবহার করা এড়ানো।
উপরের উদাহরণে, যদি উভয় দল নিয়মিতভাবে তাদের পরিবর্তনগুলিকে main
শাখায় ঠেলে দেয়, তারা দ্রুত লক্ষ্য করবে যে তারা একই ফাইল সংশোধন করার চেষ্টা করছে।
এমনকি আরও, তারা সমস্যাগুলি সম্পূর্ণভাবে এড়াতে পারত। প্রথম দলটি সেই আপডেটগুলি বিবেচনা করে ফাইলটি ইতিমধ্যে পরিবর্তন করার পরে দ্বিতীয় দলটি তাদের পরিবর্তন করা শুরু করবে।
একজন মনোযোগী পাঠক ভাবতে পারেন: সবকিছু দুর্দান্ত শোনাচ্ছে, কিন্তু আমরা কীভাবে পরীক্ষা করব? বৈশিষ্ট্য প্রতি শাখা প্রকাশের আগে বিচ্ছিন্নভাবে সম্পূর্ণ নতুন কার্যকারিতা পরীক্ষা করার অনুমতি দেয়; যদি আমরা ক্রমাগত পরিবর্তনগুলিকে main
শাখায় একীভূত করি, তবে এর কোন সুযোগ থাকবে না।
একটি বৈশিষ্ট্য পতাকা, বা একটি বৈশিষ্ট্য টগল, একটি সাধারণ গতিশীল পতাকা যা রানটাইমে নির্দিষ্ট বৈশিষ্ট্যটিকে টগল করার অনুমতি দেয়। সাধারণত, বৈশিষ্ট্য পতাকাগুলি ব্যবহারকারীদের নির্দিষ্ট গোষ্ঠীর জন্য বৈশিষ্ট্যগুলি সক্ষম বা অক্ষম করার অনুমতি দেয়, যেমন QA ইঞ্জিনিয়ার, কর্মী, নির্দিষ্ট গ্রাহক ইত্যাদি।
বৈশিষ্ট্য পতাকাগুলির বেশ কয়েকটি অতিরিক্ত সুবিধা রয়েছে:
বৈশিষ্ট্য পতাকা ব্যবহার করে main
শাখায় পরিবর্তনগুলিকে নিরাপদ করে তোলে। বৈশিষ্ট্য পতাকা বন্ধ থাকাকালীন, পরিবর্তনগুলি কাউকে প্রভাবিত করে না৷
এই কৌশলটি সরাসরি main
শাখার সাথে কাজ করতে বা স্বল্প-জীবিত শাখা তৈরি করতে দেয়। সুতরাং, একত্রীকরণ বিরোধগুলি বেশ বিরল হয়ে ওঠে এবং দ্রুত সমাধান হয়।
সংক্ষেপে, ফিচার ফ্ল্যাগগুলির সাথে মিলিত ট্রাঙ্ক-ভিত্তিক বিকাশ একটি চমৎকার কৌশল যা বৈশিষ্ট্য শাখায় পরস্পরবিরোধী পরিবর্তন দ্বারা প্ররোচিত অনেক সমস্যা এড়াতে সাহায্য করে।
যাইহোক, সর্বদা হিসাবে, কোন এক-আকার-ফিট-সব নেই. এটি একই রিপোজিটরিতে কাজ করছে এমন অল্প সংখ্যক দলের জন্য কাজ করে - এই সংখ্যা বাড়ানোর জন্য সাধারণত কিছু সমন্বয় প্রয়োজন।
তদুপরি, উভয় পদ্ধতি ব্যবহার করা সর্বদা সম্ভব: নির্দিষ্ট পরিস্থিতি এবং কাজের উপর নির্ভর করে বৈশিষ্ট্য শাখা বা বৈশিষ্ট্য পতাকা ব্যবহার করুন।