একই সফ্টওয়্যারটির বিভিন্ন সংস্করণ বজায় রাখতে শাখা ব্যবহার করা কি ভাল অভ্যাস?


72

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

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


উত্তর:


45

এটি পরিবর্তনের মাত্রার উপর নির্ভর করে, তবে আপনি বর্ণিত পার্থক্যের জন্য আমি এটিকে ভাল অনুশীলন হিসাবে বিবেচনা করব না।

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

আপনার যদি সামান্য পরিবর্তন হয়, সমস্যার তুলনায় সম্পূর্ণ মার্জিং এবং শাখা-রক্ষার প্রচেষ্টা ওভারকিল বলে মনে হয়। সংস্করণগুলির মধ্যে পার্থক্য করতে আপনার প্রিপ্রসেসর বা বিল্ড সিস্টেম ব্যবহার করুন। একটি সহজ #ifdefকৌশল কি না? তাহলে গিট দিয়ে সমস্যাগুলি সমাধান করবেন না, এটি ওভারকিল।


4
আমি বলতে চাই এটি গিটের জন্য সঠিক, তবে এটি মনে রাখা আকর্ষণীয় যে অন্যান্য ভিসিএসের সাথে রিলিজ / সংস্করণগুলির জন্য শাখা প্রশাখা আরও ভাল কৌশল হতে পারে
জে.কে।

16

শাখাগুলি আসলে এটিই নয়। শাখাগুলি একই কোডের দীর্ঘমেয়াদী সমান্তরাল সংস্করণ নয়, আপনার বিকাশের লাইনের মধ্যমেয়াদী পার্শ্ব পাথগুলি সংক্ষিপ্ত থেকে কম বলে মনে করা হচ্ছে to

সংস্করণগুলির মধ্যে পৃথক অংশগুলির একটি সাব-ডিরেক্টরি সহ আমি সমস্ত শাখাকে একই শাখায় রেখে দিয়েছিলাম এবং আপনার বিল্ড প্রক্রিয়াটি সেট করেছিলাম (আপনার একটি স্বয়ংক্রিয় বিল্ড আছে, তাই না?) যাতে এটি চাহিদা অনুসারে সংস্করণটি আউটপুট করতে পারে (বা তাদের সমস্ত একবারে)।

সর্বোপরি, আপনি একটি "সত্যের একক উত্স" রাখতে চান; শাখাগুলি সহ, আপনি কিছু কোডের সদৃশ হবেন, তবে সমস্ত নয় এবং নির্দিষ্ট সংযুক্তিগুলি আসলে আপনার সেটআপটি ভেঙে দেবে।


যদি সামান্য পার্থক্য সহ একই শ্রেণীর দুটি সংস্করণ থাকে তবে এখানে একটি স্বয়ংক্রিয় বিল্ড কীভাবে সহায়তা করবে? একমাত্র সমাধান যে আমার মনে আসে যে (বিভিন্ন সমাধান কনফিগারেশনের ব্যবহার করছে EditionA, EditionBইত্যাদি) এবং শর্তসাপেক্ষে ক্লাস এই ধরনের সহ csprojফাইল (যেমন <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'EditionA|AnyCPU' ">)। প্রকল্পটি তৈরি করতে স্বয়ংক্রিয় বিল্ডগুলি এই বিভিন্ন কনফিগারেশন ব্যবহার করতে পারে। আপনি কি মনে করেন?

এটি নির্ভর করে আপনি কোন বিল্ড সরঞ্জামগুলি ব্যবহার করেন তবে সাধারণভাবে বলছেন, হ্যাঁ, আপনার যে বিল্ড সিস্টেমটি চান সেটি কনফিগারেশন তৈরি করার কথা বলার উপায় থাকা উচিত এবং এটির পরে স্বয়ংক্রিয়ভাবে সঠিক কোডটি অন্তর্ভুক্ত করা উচিত। আমি কয়েক বছরে কিছু করি নি। নেট বছরগুলিতে, সুতরাং আজকাল এটি করার সঠিক উপায়টি কী বলে বিবেচিত তা আমি জানি না।
টিডামার্স

12

একটি সমাধান - যেমন লোকেরা উল্লেখ করেছে - হ'ল বিল্ড সিস্টেমকে বিভিন্ন সংস্করণ সমর্থন করার জন্য কনফিগার করা।

আমি এটিকে বৈশিষ্ট্য টগল হিসাবে প্রয়োগ করে একটি কনফিগারেশন ফাইল ব্যবহার করব। আপনার যত কম নির্মাণ করতে হবে তত ভাল।

এই সাইটে একবার দেখুন।


3

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


2

এটি বিভিন্ন বিল্ড কনফিগারেশনের জন্য একটি কাজের মতো শোনাচ্ছে। থাইটনের উত্তরটি এই দিকে চলে যায় তবে আমি এটার থেকে অনেক বেশি দূরে নিয়ে যাব #ifdef:

সফ্টওয়্যারটির বিভিন্ন সংস্করণ তৈরি করতে বিভিন্ন বিল্ড লক্ষ্যগুলি ব্যবহার করুন। লক্ষ্যগুলি পৃথক হতে পারে

  • তারা অন্তর্ভুক্ত কনফিগারেশন,
  • তারা অন্তর্ভুক্ত বস্তু বা উত্স ফাইল, বা
  • উত্স কোড প্রাকপ্রসেসিং।

এই প্রিপ্রোসেসিংটিতে স্পষ্টত ধ্রুপদী সি প্রিপ্রোসেসর অন্তর্ভুক্ত থাকতে পারে তবে এটি কাস্টম প্রিপ্রসেসর, কাস্টম ভিউগুলি তৈরির জন্য একটি টেম্পলেট ইঞ্জিন ব্যবহার করেও জড়িত হতে পারে ...

এইভাবে, আপনি প্রতিটি একক পরিবর্তনকে একাধিক শাখায় সক্রিয়ভাবে ধাক্কা দেওয়া থেকে বিরত থাকুন, যা ডিআরওয়াই লঙ্ঘন করে (অবশ্যই এটিও স্বয়ংক্রিয়ভাবে চালিত হতে পারে তবে আমি সুবিধাটি দেখতে পাচ্ছি না)।


1

আমি শাখাগুলি কেবলমাত্র উল্লেখযোগ্য পরিবর্তনের জন্য ব্যবহার করব, অন্যথায় আপনি অসংখ্য শাখায় প্রতিটি সামান্য পরিবর্তন যুক্ত করে শেষ করেন যা করা মোটেও মজাদার নয় এবং খুব ত্রুটিযুক্ত, বিশেষত যদি আপনি আরও বেশি লোকের সাথে কাজ করছেন working


1

আপনি যদি তাদের সমস্তকে আলাদা পণ্য হিসাবে ছেড়ে দিচ্ছেন তবে একাধিক শাখা রাখার পরামর্শ দেওয়া হচ্ছে। যদি তা না হয় তবে এটি এখনও ট্রাঙ্ক বা মাস্টার শাখার মতো কিছু ব্যবহার করার পরামর্শ দেওয়া হয়।

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


-2

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


1
ওপি পৃথক বৈশিষ্ট্য ইত্যাদির বিকাশের জন্য নয়, একক পণ্যের বিভিন্ন রূপের জন্য বিভিন্ন শাখা সম্পর্কে জিজ্ঞাসা করছে
একটি সিএনএন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.