নামকরণ করা শাখা বনাম একাধিক সংগ্রহস্থল


130

আমরা বর্তমানে তুলনামূলকভাবে বড় কোডবেসে সাবভারশন ব্যবহার করছি। প্রতিটি প্রকাশের নিজস্ব শাখা পায় এবং ট্রাঙ্কের বিরুদ্ধে সংশোধন করা হয় এবং ব্যবহার করে রিলিজ শাখায় স্থানান্তরিত হয়svnmerge.py

আমি বিশ্বাস করি আরও ভাল উত্স নিয়ন্ত্রণের দিকে এগিয়ে যাওয়ার সময় এসে গেছে এবং আমি কিছুক্ষণের জন্য মারকুরিয়ালের সাথে কথা বলছি।

সেখানে দুটি স্কুল আছে বলে মনে হচ্ছে মার্কুরিয়াল ব্যবহার করে এ জাতীয় রিলিজ স্ট্রাকচার পরিচালনা করা। হয় প্রতিটি প্রকাশের নিজস্ব রেপো পাওয়া যায়, এবং রিলিজ শাখার বিপরীতে সংশোধন করা হয় এবং মূল শাখায় (এবং অন্য কোনও নতুন রিলিজ শাখা।) বা একক সংগ্রহস্থলের মধ্যে নামযুক্ত শাখা ব্যবহার করা হয় (বা একাধিক মিলের অনুলিপি))

উভয় ক্ষেত্রেই মনে হচ্ছে আমি মুক্তির শাখাগুলিতে অন্তর্ভুক্তির জন্য চেরিপিক পরিবর্তনের জন্য ট্রান্সপ্ল্যান্টের মতো কিছু ব্যবহার করছি।

আমি তোমাকে জিজ্ঞাসা করি; প্রতিটি পদ্ধতির আপেক্ষিক গুণাবলী কি?

উত্তর:


129

বৃহত্তম পার্থক্য হ'ল কীভাবে শাখার নাম ইতিহাসে রেকর্ড করা হয়। নামযুক্ত শাখাগুলির সাথে শাখার নামটি প্রতিটি চেঞ্জসেটে এম্বেড করা হয় এবং এইভাবে ইতিহাসের অপরিবর্তনীয় অংশে পরিণত হবে। ক্লোনগুলির সাথে কোনও স্থায়ী থাকবে না নির্দিষ্ট পরিবর্তনটি কোথা থেকে এসেছে রেকর্ড ।

এর অর্থ হ'ল ক্লোনগুলি দ্রুত পরীক্ষার জন্য দুর্দান্ত যেখানে আপনি কোনও শাখার নাম রেকর্ড করতে চান না এবং নামযুক্ত শাখা দীর্ঘমেয়াদী শাখাগুলির জন্য ভাল ("1.x", "2.x" এবং অনুরূপ)।

এটিও নোট করুন যে কোনও একক সংগ্রহস্থল সহজেই মার্চুরিয়ালে একাধিক হালকা ওজনের শাখাগুলিকে সংযুক্ত করতে পারে। এগুলিতে os সংগ্রহস্থল শাখাগুলি বুকমার্ক করা যায় যাতে আপনি সহজেই সেগুলি আবার খুঁজে পেতে পারেন। ধরা যাক যে আপনি যখন কোম্পানির ভান্ডারটিকে এমন দেখাচ্ছে তখন আপনি ক্লোন করেছেন:

[a] --- [b]

আপনি দূরে হ্যাক এবং তৈরি [x]এবং [y]:

[a] --- [b] --- [x] --- [y]

কেউ যখন রাখে [c]এবং[d] সংগ্রহশালায় , তারপরে আপনি যখন টানেন তখন আপনি একটি ইতিহাস গ্রাফ পাবেন:

            [এক্স] --- [y]
           /
[এ বি সি ডি]

এখানে একক ভাণ্ডারে দুটি মাথা রয়েছে। আপনার কাজের অনুলিপি সর্বদা একটি একক চেঞ্জসেট প্রতিবিম্বিত হবে, তথাকথিত ওয়ার্কিং কপির প্যারেন্ট চেঞ্জসেট। এটি দিয়ে পরীক্ষা করুন:

% hg parents

এর রিপোর্ট যে বলা যাক [y]। আপনি মাথা দেখতে পারেন

% hg heads

এবং এটি রিপোর্ট করবে [y]এবং [d]। আপনি যদি আপনার সংগ্রহস্থলটিকে একটি পরিষ্কার চেকআউটে আপডেট করতে চান [d], তবে কেবল করুন (এর [d]জন্য সংশোধন নম্বরটির বিকল্প [d]):

% hg update --clean [d]

তারপরে আপনি সেই hg parentsপ্রতিবেদনটি দেখতে পাবেন [d]। এর অর্থ হ'ল আপনার পরবর্তী প্রতিশ্রুতি [d]অভিভাবক হিসাবে থাকবে । আপনি মূল শাখায় লক্ষ্য করে এমন একটি বাগটি ঠিক করতে পারেন এবং পরিবর্তনটি তৈরি করতে পারেন [e]:

            [এক্স] --- [y]
           /
[এ] --- [খ] --- [সি] --- [ডি] --- [ই]

[e]শুধুমাত্র চেঞ্জসেটটি পুশ করতে , আপনাকে তা করতে হবে

% hg push -r [e]

[e]চেঞ্জসেট হ্যাশ কোথায় ডিফল্টরূপে hg pushকেবল ভান্ডার তুলনা করিয়া দেখ, হবে [x], [y]এবং [e]অনুপস্থিত, কিন্তু আপনি ভাগ করতে চাইতে পারেন [x]এবং [y]এখনো।

যদি বাগফিক্স আপনাকে প্রভাবিত করে তবে আপনি এটিকে আপনার বৈশিষ্ট্য শাখার সাথে একীভূত করতে চান:

% hg update [y]
% hg merge

এটি আপনার সংগ্রহস্থল গ্রাফটি দেখতে এমনভাবে ছাড়বে:

            [এক্স] --- [y] ----------- [জেড]
           / /
[এ] --- [খ] --- [সি] --- [ডি] --- [ই]

কোথায় এবং [z]মধ্যে একত্রীকরণ । আপনি শাখাটি ফেলে দিতে পছন্দ করতে পারেন:[y][e]

% hg strip [x]

আমার এই গল্পের মূল বিষয়টি হ'ল: একটি একক ক্লোন সহজেই বিকাশের বেশ কয়েকটি ট্র্যাক উপস্থাপন করতে পারে। এটি কোনও এক্সটেনশন ব্যবহার না করে "প্লেইন এইচজি" এর পক্ষে সর্বদা সত্য। যদিও বুকমার্কস এক্সটেনশন একটি দুর্দান্ত সহায়তা। এটি আপনাকে চেঞ্জসেটগুলিতে নাম (বুকমার্ক) নির্ধারণের অনুমতি দেবে। উপরের ক্ষেত্রে আপনি আপনার বিকাশের মাথায় এবং একটি উজানের মাথায় একটি বুকমার্ক চাইবেন। বুকমার্কগুলি মার্শিয়াল 1.6 এর সাথে ধাক্কা এবং টান দেওয়া যায় এবং মার্চুরিয়াল 1.8 এ একটি অন্তর্নির্মিত বৈশিষ্ট্যে পরিণত হয়েছে।

আপনি যদি দুটি ক্লোন তৈরি করতে পছন্দ করেন, আপনার বিকাশ ক্লোনটি তৈরির পরে এমন দেখাবে [x]এবং [y]:

[a] --- [b] --- [x] --- [y]

এবং আপনার আপস্ট্রিম ক্লোন এতে থাকবে:

[a] --- [b] --- [c] --- [d]

আপনি এখন বাগটি লক্ষ্য করুন এবং এটি ঠিক করুন। hg updateআপস্ট্রিম ক্লোনটি ব্যবহারের জন্য প্রস্তুত হওয়ায় এখানে আপনার দরকার নেই । আপনি প্রতিশ্রুতিবদ্ধ এবং তৈরি [e]:

[a] --- [b] --- [c] --- [d] --- [e]

আপনার বিকাশের ক্লোনটিতে বাগফিক্স অন্তর্ভুক্ত করতে আপনি এটি এখানে টানুন:

[এ] --- [খ] --- [এক্স] --- [ওয়]
           \
            [সি] --- [ডি] --- [ই]

এবং মার্জ করুন:

[এ] --- [খ] --- [এক্স] --- [ওয়াই] --- [জেড]
           \ /
            [সি] --- [ডি] --- [ই]

গ্রাফটি দেখতে অন্যরকম দেখাচ্ছে তবে এর কাঠামো একই রকম এবং শেষ ফলাফলটি একই। ক্লোনগুলি ব্যবহার করে আপনাকে কিছুটা কম মানসিক বুককিপিং করতে হয়েছিল।

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


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

2
উল্লেখ: 'দ্রুত পরীক্ষার জন্য ক্লোনগুলি দুর্দান্ত' - না, সেগুলি নয়! রেপোতে কয়েক হাজার ফাইল পেলে কী হয়? ক্লোনিং বয়সগুলি গ্রহণ করবে (যে কোনও সময় 1 মিনিটেরও বেশি) শাখাটি কেবল একটি মুহুর্তে স্যুইচ করতে হবে (<1 সেকেন্ড)। তবুও নামযুক্ত শাখা ব্যবহার করা পরিবর্তনকে দূষিত করবে। এটা কি মৃতপ্রায় নয়? নাকি আমি কিছু মিস করছি?
সিলার

ঠিক আছে সেলার; তার আসল যুক্তিতে কোনও পরিবর্তন হওয়ার মতো মনে হচ্ছে; ক্লোনগুলি ভাল যেখানে একাধিক সম্পূর্ণ অনুলিপিগুলির ওভারহেড আপনার পক্ষে গুরুত্বপূর্ণ নয় বা আপনি যখন শাখায় পৃথক স্থানীয় কপির অনুলিপি হ্রাস করতে hg এর সিমলিংক / হার্ডলিঙ্কগুলি ব্যবহার করতে পারেন।
ওয়ারেন পি

@ সেলার: আপনি ঠিক বলেছেন যে কোড বেড বড় হলে ক্লোনগুলি অবৈজ্ঞানিক। বুকমার্কগুলি তখন সমাধান।
মার্টিন গিজলার

29

আমি মনে করি আপনি একটি রেপোতে পুরো ইতিহাস চান। স্বল্প-মেয়াদী রেপো ছড়িয়ে দেওয়া স্বল্প-মেয়াদী পরীক্ষার জন্য, প্রকাশের মতো বড় ইভেন্ট নয়।

মার্চুরিয়ালের হতাশার মধ্যে একটি হ'ল মনে হয় যে স্বল্প-কালীন শাখা তৈরি করা, এটির সাথে খেলতে, এটিকে ত্যাগ করা এবং আবর্জনা সংগ্রহের সহজ উপায় নেই। শাখা চিরকাল থাকে। আমি কখনই ইতিহাসকে ত্যাগ করতে চাই না সহানুভূতি জানাই, তবে অতি সস্তার, নিষ্পত্তিযোগ্য শাখা এমন একটি gitবৈশিষ্ট্য যা আমি সত্যিই দেখতে চাই hg


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

8
দেখে মনে hg stripহচ্ছে যা আমি চাই। অনলাইন ডকুমেন্টেশনের দাবি শাখাগুলি মোছা যাবে না কেন?
নরম্যান রামসে 21


9
আপনি এর সাথে একটি নামী শাখা বন্ধ করতে পারেন hg ci --close-branch
আন্দ্রে ভ্লাসোভস্কিখ

3
@ নরম্যান রামসে: লোকেরা যখন বলে যে শাখাগুলি মোছা যায় না, তাদের অর্থ আপনি চেঞ্জসেটে এমবেড করা শাখার নামটি পরিবর্তন করতে পারবেন না। থেকে একটি আমাদের changeset উপর একটি শাখা, এটি সংজ্ঞায়িত একটি শাখা। আপনার যদি পরিবর্তনটি মুছে ফেলা হয় এবং আপনি এটি অন্য একটি শাখায় "স্থানান্তরিত" করতে চান তবে এটি একটি আলাদা শাখার নাম দিয়ে পুনরায় তৈরি করতে হবে।
মার্টিন গিজার

14

আপনার উভয় করা উচিত ।

@ নরমন থেকে গৃহীত উত্তর দিয়ে শুরু করুন: রিলিজের জন্য একটি নামী শাখা সহ একটি সংগ্রহস্থল ব্যবহার করুন।

তারপরে, বিল্ডিং এবং পরীক্ষার জন্য রিলিজ শাখায় এক ক্লোন রাখুন।

একটি মূল নোট হ'ল আপনি যদি একাধিক সংগ্রহস্থল ব্যবহার করেন তবে আপনার transplantমধ্যে চেঞ্জসেটগুলি সরিয়ে নেওয়া উচিত নয় কারণ 1) এটিতে হ্যাশ পরিবর্তন হয় এবং 2) আপনি যে পরিবর্তনগুলি পরিবর্তন করতে পারেন তার মধ্যে বিরোধী পরিবর্তনগুলি উপস্থিত হওয়ার সময় এটি সনাক্ত করা খুব কঠিন এমন বাগগুলি প্রবর্তন করতে পারে প্রতিস্থাপন এবং লক্ষ্য শাখা। পরিবর্তে আপনি (এবং প্রিমার ছাড়াই: সর্বদা মার্জটি দৃষ্টিভঙ্গিটি পরীক্ষা করুন) এর পরিবর্তে সাধারণ মার্জটি করতে চান, যার ফলস্বরূপ @ এমজি তার উত্তর শেষে যা বলেছিল:

গ্রাফটি দেখতে অন্যরকম দেখাচ্ছে তবে এর কাঠামো একই রকম এবং শেষ ফলাফলটি একই।

আরো verbosely, যদি আপনি একাধিক ভান্ডার, "ট্রাঙ্ক" সংগ্রহস্থল ব্যবহার (অথবা ডিফল্ট, প্রধান, উন্নয়ন, যাই হোক না কেন) রয়েছে সব মধ্যে changesets সব ভান্ডার। প্রতিটি প্রকাশ / শাখা ভান্ডার হ'ল ট্রাঙ্কের একটি শাখা, সমস্ত একদিকে বা অন্যটি ট্রাঙ্কে মিশে যায়, যতক্ষণ না আপনি কোনও পুরানো রিলিজ পিছনে রেখে যেতে চান। সুতরাং, নামকৃত শাখা স্কিমের মূল রেপো এবং একক রেপোর মধ্যে একমাত্র আসল পার্থক্যটি কেবল শাখার নাম দেওয়া হয়েছে কিনা is

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

তবে তারপরেও আপনাকে শাখা / প্রকাশের জন্য একটি ক্লোন বজায় রাখতে হবে যা আপনার তৈরি এবং পরীক্ষা করা দরকার। এটি যতটা সম্ভব তুচ্ছ hg clone <main repo>#<branch> <branch repo>, এবং তারপরে hg pullব্রাঞ্চের রেপোতে কেবল সেই শাখায় নতুন চেঞ্জসেটগুলি টেনে আনবে (প্লাস পূর্ববর্তী শাখাগুলিতে পূর্বপুরুষের চেঞ্জসেটগুলি যা সংহত করা হয়েছিল)।

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


এই সেটআপটির জন্য পুনরায় সংযুক্ত করা হয়েছে @ মিলিগ্রামের উদাহরণ। শুরু:

[a] - [b]

রিলিজ সংস্করণটির জন্য একটি নামযুক্ত শাখা তৈরি করুন, "আলফা রিলিজ পাওয়ার পরে" 1.0 বলুন। এটিতে বাগ সংশোধন করুন:

[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

(1.0)আপনি বাস্তবায়ন না হওয়া পর্যন্ত নামকরণ করা শাখার অস্তিত্ব নেই বলে একটি সত্যিকারের পরিবর্তন নেই। (নামযুক্ত শাখাগুলি সঠিকভাবে তৈরি হয়েছে তা নিশ্চিত করতে আপনি একটি ট্যাগ যুক্ত করার মতো একটি তুচ্ছ অঙ্গীকারবদ্ধ করতে পারেন))

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

ইতিমধ্যে ডিফল্ট শাখায় বিকাশ পরবর্তী প্রকাশের দিকে অব্যাহত রয়েছে:

          ------- [c] - [d]
         /
[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

এবং যথারীতি আপনাকে ডিফল্ট শাখায় দুটি মাথা একত্রিত করতে হবে:

          ------- [c] - [d] -------
         /                         \
[a] - [b] ------------------ [m1] - [m2]
         \                 /
          (1.0) - [x] - [y]

এবং এটি 1.0 শাখার ক্লোন:

[a] - [b] - (1.0) - [x] - [y]

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


আমি আশা করি উদাহরণটি আমার পূর্ববর্তী বিষয়গুলি পরিষ্কার করেছে। সংক্ষেপে, এই পদ্ধতির সুবিধাগুলি হ'ল:

  1. একক অনুমোদনমূলক সংগ্রহস্থল যা সম্পূর্ণ পরিবর্তন ও সংস্করণ ইতিহাস ধারণ করে।
  2. সাফ এবং সরলীকৃত রিলিজ পরিচালনা।
  3. বিকাশকারী এবং ইন্টিগ্রেটারের জন্য পরিষ্কার এবং সরলীকৃত ওয়ার্কফ্লো।
  4. ওয়ার্কফ্লো পুনরাবৃত্তি (কোড পর্যালোচনা) এবং অটোমেশন (স্বয়ংক্রিয় খালি মার্জ) সুবিধা করুন।

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


5

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


2

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


0

আমি সংস্করণগুলির জন্য নামযুক্ত শাখা ব্যবহারের বিরুদ্ধে সত্যই পরামর্শ দেব। এটিই কি ট্যাগগুলির জন্য। নামযুক্ত শাখাগুলি দীর্ঘকালীন স্থিতিশীল বিবর্তনের জন্য যেমন একটি stableশাখার জন্য বোঝানো হয় ।

তাহলে শুধু ট্যাগ ব্যবহার করবেন না কেন? একটি প্রাথমিক উদাহরণ:

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

এটি defaultশাখায় একটি নতুন, নামহীন মাথা তৈরি করবে , ওরফে। একটি বেনামে শাখা, যা এইচজি তে পুরোপুরি ঠিক আছে। এরপরে আপনি যে কোনও সময়ে বাগফিক্সকে মূল বিকাশের ট্র্যাকটিতে ফিরে যেতে পারেন merge নামযুক্ত শাখার দরকার নেই।


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