সাবভার্সনের চেয়ে ডিভিসিএসে কেন মার্জ করা ভাল তা দাবী করা মূলত কিছুকাল আগে সাবভার্সনে শাখা এবং মার্জ কীভাবে কাজ করেছিল তার উপর ভিত্তি করে ছিল। ১.০.০ এর পূর্বে সাববর্তন কখন শাখাগুলি মার্জ হয়েছিল সে সম্পর্কে কোনও তথ্য সংরক্ষণ করে না, সুতরাং আপনি যখন মার্জ করতে চেয়েছিলেন তখন আপনাকে সংশোধন করতে হবে যে সংশোধনগুলির রেঞ্জটি নির্দিষ্ট করতে হবে।
তাহলে সাবভার্সন কেন স্তন্যপান করল ?
এই উদাহরণটি বিবেচনা করুন:
1 2 4 6 8
trunk o-->o-->o---->o---->o
\
\ 3 5 7
b1 +->o---->o---->o
যখন আমরা বি 1-র পরিবর্তনগুলি ট্রাঙ্কে একত্রীকরণ করতে চাই তখন ট্রাঙ্কযুক্ত একটি ফোল্ডারে দাঁড়িয়ে আমরা নিম্নলিখিত কমান্ডটি প্রদান করব:
svn merge -r 2:7 {link to branch b1}
… যা b1আপনার স্থানীয় ওয়ার্কিং ডিরেক্টরিতে পরিবর্তনগুলি মার্জ করার চেষ্টা করবে । এবং তারপরে আপনি কোনও বিবাদ সমাধানের পরে ফলাফলটি পরীক্ষা করার পরে আপনি পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ। আপনি যখন পুনর্বিবেচনা ট্রিটি দেখতে পাবেন তখন এটি দেখতে পাবেন:
1 2 4 6 8 9
trunk o-->o-->o---->o---->o-->o "the merge commit is at r9"
\
\ 3 5 7
b1 +->o---->o---->o
তবে সংস্করণ গাছ বৃদ্ধি পাওয়ার সাথে সাথে সংস্করণগুলি নির্দিষ্ট করার এই উপায়টি খুব শীঘ্রই হাতছাড়া হয়ে যায় কারণ কখন এবং কী সংশোধনীগুলি একত্রিত হয়ে যায় সে সম্পর্কে কোনও মেটা ডেটা না থাকায় সংস্করণ গাছ বৃদ্ধি পায়। পরে কী ঘটবে তা চিন্তা করুন:
12 14
trunk …-->o-------->o
"Okay, so when did we merge last time?"
13 15
b1 …----->o-------->o
এটি মূলত রিপোজিটরি ডিজাইনের একটি ইস্যু যা সাবভারসন রয়েছে, একটি শাখা তৈরি করার জন্য আপনার ভাণ্ডারে একটি নতুন ভার্চুয়াল ডিরেক্টরি তৈরি করতে হবে যা ট্রাঙ্কের একটি অনুলিপি রাখবে তবে এটি কখন এবং কী সম্পর্কিত কোনও তথ্য সংরক্ষণ করে না জিনিসগুলি আবার একত্রিত হয়ে গেছে That যা সময়ে সময়ে দুষ্টু সংঘর্ষে লিপ্ত হয়। আরও খারাপটি হ'ল ডিফল্টরূপে সাবভারশন দ্বি-মুখী মার্জিং ব্যবহার করেছিল, যখন দুটি শাখা প্রধানকে তাদের সাধারণ পূর্বপুরুষের সাথে তুলনা না করা হয় তখন স্বয়ংক্রিয়ভাবে মার্জিংয়ের কিছু পঙ্গু সীমাবদ্ধতা রয়েছে।
এই সাবভারশনটি প্রশমিত করার জন্য এখন শাখার জন্য মেটা ডেটা সঞ্চয় করে মার্জ করে। যে সব সমস্যার ঠিক সমাধান করতে হবে?
এবং ওহ, যাইহোক, সাবভারশন এখনও চুষে ...
কেন্দ্রীভূত সিস্টেমে, সাবভার্সনের মতো ভার্চুয়াল ডিরেক্টরিগুলি স্তন্যপান করে। কেন? কারণ প্রত্যেকেরই এগুলি দেখার জন্য অ্যাক্সেস রয়েছে ... এমনকি আবর্জনা পরীক্ষামূলক। আপনি পরীক্ষা করতে চান তবে ব্রাঞ্চিং ভাল তবে আপনি প্রত্যেকে দেখতে চান না 'এবং তাদের মাসিদের পরীক্ষা করা । এটি মারাত্মক জ্ঞানীয় শব্দ। আপনি যত বেশি শাখা যুক্ত করবেন, ততই ক্র্যাপগুলি দেখতে পাবেন।
আপনার ভাণ্ডারগুলিতে যত বেশি পাবলিক শাখা রয়েছে তা সমস্ত বিভিন্ন শাখার ট্র্যাক রাখা তত কঠিন। সুতরাং আপনার কাছে প্রশ্নটি থাকবে যদি শাখাটি এখনও বিকাশে রয়েছে বা এটি সত্যিই মারা গেছে যা কোনও কেন্দ্রীভূত সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় বলা মুশকিল।
বেশিরভাগ সময়, যা আমি দেখেছি, সেখান থেকে কোনও সংস্থা একটি বড় শাখা ব্যবহারের জন্য ডিফল্ট হবে। যা লজ্জাজনক কারণ পরিবর্তে পরীক্ষাগুলি এবং প্রকাশের সংস্করণগুলি ট্র্যাক করা এবং অন্য যা কিছু ভাল হয় তা ব্রাঞ্চিং থেকে আসে।
তাহলে ডিভিসিএস, যেমন গিট, মার্কিউরিয়াল এবং বাজার, শাখা এবং মার্জ করার সময়ে সাবভার্সনের চেয়ে কেন ভাল?
খুব সাধারণ কারণ আছে: শাখা প্রশাখা প্রথম শ্রেণির ধারণা । আছে কোন ভার্চুয়াল ডিরেক্টরি নকশা এবং শাখা দ্বারা DVCS মধ্যে হার্ড বস্তু যা এটি সহজভাবে ভান্ডার সিঙ্ক্রোনাইজেশন (অর্থাত সঙ্গে কাজ করার জন্য যেমন হওয়া প্রয়োজন হয় ধাক্কা এবং টান )।
ডিভিসিএসের সাথে কাজ করার সময় আপনি প্রথমে যে কাজটি করেন তা হ'ল সংগ্রহস্থল (গিটস clone, এইচজি cloneএবং বিজেআর) ক্লোন করা branch। ক্লোনিং সংস্করণ নিয়ন্ত্রণে একটি শাখা তৈরি করার মত ধারণাগতভাবে একই জিনিস। কেউ কেউ এটিকে কাঁটাচামক বা শাখা প্রশাখাকে ডেকে আনে (যদিও পরবর্তীকালে প্রায়শই সহ-অবস্থিত শাখাগুলিও ব্যবহৃত হয়) তবে এটি ঠিক একই জিনিস। প্রতিটি ব্যবহারকারী তাদের নিজস্ব সংগ্রহশালা চালায় যার অর্থ আপনার প্রতি ব্যবহারকারী ব্যবহারকারীর শাখা চলছে।
সংস্করণ কাঠামো গাছ নয় , পরিবর্তে একটি গ্রাফ । আরও সুনির্দিষ্টভাবে নির্দেশিত অ্যাসাইক্লিক গ্রাফ (ডিএজি, একটি গ্রাফ যার কোনও চক্র নেই)। প্রতিটি প্রতিশ্রুতিতে এক বা একাধিক অভিভাবক রেফারেন্স (যা প্রতিশ্রুতিবদ্ধ ছিল তার উপর ভিত্তি করে ছিল) ব্যতীত আপনার কোনও ডিএজি-র স্পেসিফিকেশনগুলিতে অবশ্যই অবতীর্ণ হওয়ার দরকার নেই। সুতরাং নিম্নলিখিত গ্রাফগুলি এর কারণে বিপরীতে সংশোধনগুলির মধ্যে তীরগুলি প্রদর্শন করবে।
মার্জ করার একটি খুব সাধারণ উদাহরণ এটি হবে; কল করা একটি কেন্দ্রীয় ভান্ডার originএবং তার ব্যবহারকারী, এলিস তার যন্ত্রটিতে ক্লোনিং করে imagine
a… b… c…
origin o<---o<---o
^master
|
| clone
v
a… b… c…
alice o<---o<---o
^master
^origin/master
ক্লোন চলাকালীন যা ঘটে তা হ'ল প্রতিটি সংশোধন অ্যালিসে ঠিক তেমনভাবে অনুলিপি করা হয় (যা অনন্যরূপে সনাক্তযোগ্য হ্যাশ-আইডি দ্বারা যাচাই করা হয়), এবং যেখানে মূলটির শাখা রয়েছে তা চিহ্নিত করে।
তারপরে অ্যালিস তার রেপোতে কাজ করে তার নিজের ভাণ্ডারে প্রতিশ্রুতিবদ্ধ এবং তার পরিবর্তনগুলি ধাক্কা দেওয়ার সিদ্ধান্ত নেয়:
a… b… c…
origin o<---o<---o
^ master
"what'll happen after a push?"
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
সমাধানটি সহজ সরল, কেবলমাত্র originरिपাইজরিটি যা করতে হবে তা হল সমস্ত নতুন সংশোধনী গ্রহণ করা এবং এর শাখাকে সর্বাধিক সংশোধনীর দিকে নিয়ে যাওয়া (যা গিটকে "দ্রুত-এগিয়ে" বলে):
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
ব্যবহারের কেস, যা আমি উপরে চিত্রিত করেছি, এমনকি কিছু মার্জ করার দরকার নেই । সুতরাং সমস্যাটি আসলে আলগোরিদিমগুলিকে মার্জ করার সাথে নয় কারণ ত্রি-মুখী মার্জ অ্যালগরিদম সমস্ত সংস্করণ নিয়ন্ত্রণ সিস্টেমের মধ্যে প্রায় একই same বিষয়টি যে কোনও কিছুর চেয়ে কাঠামো সম্পর্কে বেশি ।
সুতরাং আপনি কীভাবে আমাকে এমন উদাহরণ দেখান যাতে সত্যিকারের একত্রীকরণ আছে?
স্বীকারোক্তিভাবে উপরের উদাহরণটি একটি খুব সাধারণ ব্যবহারের ক্ষেত্রে, তাই আরও সাধারণ একটি হলেও অনেক বেশি বাঁকানো যাক। মনে আছে originতিনটি সংশোধন দিয়ে শুরু হয়েছে? ঠিক আছে, যে লোকটি সেগুলি করেছিল, তাকে বব বলে , সে তার নিজের উপর কাজ করছে এবং তার নিজের ভাণ্ডারে প্রতিশ্রুতিবদ্ধ করেছে:
a… b… c… f…
bob o<---o<---o<---o
^ master
^ origin/master
"can Bob push his changes?"
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
এখন বব তার পরিবর্তনগুলি সরাসরি originসংগ্রহস্থলের দিকে ঠেলাতে পারবেন না । সিস্টেম কীভাবে এটি সনাক্ত করে তা ববের সংশোধনগুলি সরাসরি origin'র' থেকে নেমে আসে কিনা তা যাচাই করেই হয় , যা এই ক্ষেত্রে হয় না। ধাক্কা দেওয়ার যে কোনও প্রয়াসের ফলে সিস্টেমে কিছুটা অনুরূপ " উহ ... আমি ভয় পাচ্ছি যে আপনাকে এই বব করতে না দিতে পারে "।
সুতরাং ববকে টান-ইন করতে হবে এবং তারপরে পরিবর্তনগুলি একত্রিত করতে হবে (গিট এর সাথে pull; বা এইচজি pullএবং merge; বা বিজেআর merge)। এটি একটি দুই ধাপ পদ্ধতি. প্রথম ববকে নতুন সংশোধনগুলি আনতে হবে, যা সেগুলি originসংগ্রহস্থল থেকে হওয়ায় সেগুলি অনুলিপি করবে । আমরা এখন দেখতে পাচ্ছি যে গ্রাফটি আলাদা হয়:
v master
a… b… c… f…
bob o<---o<---o<---o
^
| d… e…
+----o<---o
^ origin/master
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
টান প্রক্রিয়াটির দ্বিতীয় ধাপটি হ'ল ডাইভারিং টিপসগুলিকে একীভূত করা এবং ফলাফলটির প্রতিশ্রুতিবদ্ধ:
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
^ origin/master
আশা রাখি, একত্রীকরণ (যদি আপনি তাদের কহা আপনি নিজে সঙ্গে Git মধ্যে দুই ধাপ কি করতে পারেন দ্বন্দ্ব মধ্যে চলবে না fetchএবং merge)। পরবর্তীতে যা করা দরকার তা হ'ল সেই পরিবর্তনগুলিকে আবারও ঠেলে দেওয়া origin, যা মার্জ কমান্ড originরিপোজিটরিতে সর্বশেষের সরাসরি বংশধর হওয়ায় দ্রুত ফরোয়ার্ড সংশ্লেষে পরিণত হবে :
v origin/master
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
v master
a… b… c… f… 1…
origin o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
গিট এবং এইচজি-তে একত্রীকরণের জন্য আরও একটি বিকল্প রয়েছে, যাকে রিবেস বলা হয়, যা বব এর পরিবর্তনগুলিকে সর্বাধিক পরিবর্তনের পরে নিয়ে যাবে। যেহেতু আমি এই উত্তরটি আর কোনও ভারবস হতে চাই না, আমি আপনাকে তার পরিবর্তে গিট , পারদর্শী বা বাজারের ডকগুলি পড়তে দেব ।
পাঠকের অনুশীলন হিসাবে, এটি যুক্ত অন্য ব্যবহারকারীর সাথে কীভাবে কার্যকর হবে তা আঁকার চেষ্টা করুন। এটি একইভাবে ববকে উপরের উদাহরণ হিসাবে করা হয়েছে। আপনি যা ভাবেন তার চেয়ে বেশি সংগ্রহস্থলের মধ্যে মার্জ করা সহজ কারণ সমস্ত সংশোধন / কমিটি স্বতন্ত্রভাবে চিহ্নিতযোগ্য।
প্রতিটি বিকাশকারীদের মধ্যে প্যাচগুলি প্রেরণের বিষয়টিও রয়েছে, এটি সাবভার্সনে একটি বিশাল সমস্যা ছিল যা স্বতন্ত্ররূপে চিহ্নিতযোগ্য সংশোধনগুলির দ্বারা গিট, এইচজি এবং বিজেআর-র মাধ্যমে প্রশমিত হয়। একবার তার পরিবর্তনগুলি মার্জ হয়ে গেলে (যেমন একটি মার্জ কমিট তৈরি করা হয়েছে) এবং এটি দলের অন্য সবার জন্য এটি কেন্দ্রীয় ভান্ডারটিতে চাপ দিয়ে বা প্যাচগুলি প্রেরণ করার জন্য পাঠিয়ে দেয় তবে তাদের মার্জ সম্পর্কে চিন্তা করতে হবে না, কারণ এটি ইতিমধ্যে ঘটেছে because । মার্টিন জালিয়া কাজ করার এই ভাবে ডাকে এলোমেলো ইন্টিগ্রেশন ।
কাঠামো সাবভারশন থেকে আলাদা, পরিবর্তে একটি ডিএজি নিযুক্ত করে, এটি শাখা প্রশাখা এবং মার্জিংকে কেবল সিস্টেমের জন্য নয় কেবল ব্যবহারকারীর জন্যও একটি সহজ পদ্ধতিতে সক্ষম করে তোলে ables