বিরোধী চিহ্নিতকারীদের চেক-ইন কোডে রেখে যাওয়ার কি যুক্তি আছে?

Question

বিবাদ চিহ্নিতকারী বিবেচনা করুন। অর্থাৎ,

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

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

স্বভাবতই যদিও, আমি সত্যিই এটি নিয়ে আপত্তি নিয়েছি, তবে শয়তানরা আমার পক্ষে উকিল হওয়ায় আমি দেখতে পাচ্ছি তিনি কেন এটি করেছেন have

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

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

আমার নিজের তাত্ক্ষণিক উদ্বেগটি হ'ল এটি যদি স্পষ্টভাবে বিরক্ত হত তবে আমি যদি সম্পর্কিত যে কোনও একটি ফাইল সম্পাদনা করতাম, পরিবর্তনগুলি টানতাম, প্রকৃত বিবাদ পেতাম, তবে মন্তব্য করা বিষয়গুলিতেও টানতাম। তারপর আমি সত্যিই একটি খুব অগোছালো ফাইল আছে। ভাগ্যক্রমে তা ঘটে নি।

Comments

এটি কোন সংস্করণ নিয়ন্ত্রণ ব্যবস্থা?

— c69

আপনি কি নিশ্চিত যে এগুলি ভুল করে ফেলেছিলেন? হতে পারে যে কেউ মতবিরোধ দেখতে যান এবং সংঘাতগুলি একত্রিত করে ডাব্লু / ও সংরক্ষণ করেছেন। আমি স্মার্টএসভিএন এর সাথে এর আগেও দেখেছি

— ক্যামেলব্লিউজ

Git। দুঃখিত, আমি ট্যাগ করিনি কারণ আমি অনুভব করি নি যে প্রকৃত ভিসিএসটি প্রাসঙ্গিক। এগুলি বেশ কয়েকটি ফাইলের মধ্যে ইচ্ছাকৃতভাবে পরীক্ষা করা হয়েছিল। আমি একমত যে দুর্ঘটনাটি একবার বা দু'বার ক্ষমাযোগ্য।

— বেনিডিক্ট

"যদি আমি সম্পর্কিত ফাইলগুলির মধ্যে একটি সম্পাদনা করতাম, পরিবর্তনগুলি টানতাম, প্রকৃত দ্বন্দ্ব পেতাম, তবে মন্তব্যগুলিতেও টানতাম। তবে আমার সত্যিই খুব অগোছালো ফাইল হত।" মতামত মত অনেকটা সমান // MatrixFrog 10/25/2011: Updated this function to fix bug #1234। আমি যদি এ জাতীয় জিনিস দেখতে পাই, তবে আমার মনে হয়, "কী? এটাই কি git blame!"

— ম্যাট্রিক্সফ্রোগ

Answer 1

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

Answer 2

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

Answer 3

আমি মনে করি মন্তব্যগুলি সেখানে থাকা কোডকে বোঝাতে হবে, অতীতে ছিল এমন কোডের প্রতি নয়, কোডের সাথে অতীতে ঘটেছিল এমন ঘটনার সাথেও নয়, অথবা কোডটি একটি সমান্তরাল মহাবিশ্বের (অন্য একটি শাখা) বিদ্যমান ছিল to গত। আপনার দলের সদস্য যেভাবে করেছেন তাতে চিহ্নিতকারীদের ফেলে রাখা কমপক্ষে তিনটি সমস্যা তৈরি করে:

1. মূল কোডটি সম্ভবত এর মতো কিছু ছিল blah blah nullএবং বাগ রিপোর্টটি বলেছিল "সেখানে নাল ব্যবহার করতে পারবেন না, এই বা এটিটি বা যা কিছু ব্যবহার করুন।" সুতরাং দু'জন ব্যক্তি স্বাধীনভাবে বাগটি স্থির করে এবং যখন সংশোধনগুলি একত্রিত করা হয়, তখন বিরোধ দেখা দেয়। এখন মন্তব্য দস্তাবেজগুলি কী সমস্যা ছিল এবং কী স্থির হয়েছিল তা স্থির করে নি, কেবল অতীতে দুটি পর্যায়ে দুটি পৃথক ফিক্স ছিল। এটি খুব সহায়ক নয়। মত একটি মন্তব্য //blah blah needs a non-null argumentকমপক্ষে কি পরিবর্তিত হয়েছে একটি ইঙ্গিত দেয় (এবং এমনকি তথ্য সংস্করণ নিয়ন্ত্রণ সিস্টেমের কমিট মন্তব্য থেকে আরও সহজেই উপলব্ধ)।
2. মার্জ করা সংস্করণটি এমনকি মূল লাইনের একটির মতো দেখাবে না। হতে পারে আপনি যদি চান এবং এইটিকে নিতে চান তবে সঠিক রূপটি blah blah (this,that)আরও জটিল কিছু form সেক্ষেত্রে বিরোধের বার্তাটি একটি মন্তব্য হিসাবে রেখে দেওয়া অবশ্যই পরবর্তী সময়ে কোডটি পড়ার চেষ্টা করে যে কেউ বিভ্রান্ত করবে।
3. বেশিরভাগ সংস্করণ নিয়ন্ত্রণ ব্যবস্থা আপনাকে প্রকল্পের ইতিহাসে অ্যাক্সেস দেয়। উদাহরণস্বরূপ, আমিগ্রহণের (এসএনএন সহ) একটি ফাইলের ডানদিকে ক্লিক করতে পারি, "ইতিহাস দেখান ..." বলুন এবং তারপরে "বর্তমানের সাথে তুলনা করুন ..." এবং পার্থক্যটি হাইলাইট করে এমন একটি পৃথক উইন্ডো পেতে পারেন। তথ্যটি উপায় ভিন্ন ভিন্ন হাইলাইটগুলিতে প্রকৃত পার্থক্য থাকলে এবং তাদের চারপাশের মন্তব্যগুলিতে না থাকলে আঁকাবাঁকা করা সহজ non কোডের প্রতিটি বিট-অ-কার্যকরী পরিবর্তন যা পড়ার পক্ষে তা আরও শক্ত করে তোলে।

Answer 4

চেক-ইন কোডে সংঘাতের চিহ্নিতকারীরা কতটা বিরক্তিকর?

তাই বিরক্তিকর।

Comments

আমি দুঃখিত তবে এই উত্তরটি আসলে কিছুই যুক্ত করে না। এটি সেরা মন্তব্য করা উচিত ছিল।

— অ্যাডাম শিখুন