কেন্দ্রীভূত সংস্করণ নিয়ন্ত্রণে, প্রায়শই আপডেট করা কি সর্বদা ভাল?


9

ধরে নিচ্ছি যে:

  • আপনার দলটি কেন্দ্রীভূত সংস্করণ নিয়ন্ত্রণ ব্যবহার করছে।
  • আপনি একটি বৃহত্তর বৈশিষ্ট্যটিতে কাজ করছেন যা সম্পূর্ণ হতে বেশ কয়েক দিন সময় নেবে এবং আপনি এর আগে প্রতিশ্রুতি রাখতে সক্ষম হবেন না কারণ এটি বিল্ডটি ভেঙে দেবে।
  • আপনার দলের সদস্যরা প্রতিদিন কিছু না কিছু করে যা আপনি কাজ করছেন এমন কিছু ফাইল পরিবর্তন করতে পারে।

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

আপনি যদি প্রতিশ্রুতি দেওয়ার আগে ঠিক একবার আপডেট করেন তবে আপনার সতীর্থদের দ্বারা অন্য অনেক পরিবর্তনের কারণে প্রচুর দ্বন্দ্ব হতে পারে যা একসাথে সমাধানের জন্য ব্যথার জগত হতে পারে।

অথবা, আপনি প্রায়শই আপডেট করতে পারেন এবং দিনের পর দিন সমাধানের জন্য কয়েকটি বিবাদ থাকলেও এটি করা সহজতর হওয়া উচিত little

আপনি প্রায়শই আপডেট করা সর্বদা একটি ভাল ধারণা থাকবেন?


16
আপনি যদি ব্রাঞ্চিং না করে থাকেন তবে আপনি কোনও সংস্করণ নিয়ন্ত্রণ সিস্টেমের বৃহত্তম সুবিধাগুলির কোনও গ্রহণ করছেন না ।
গাহোয়া

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


@gnat প্রশ্ন কত ঘন ঘন আপডেট করা হয়, কমিট না
জেনোস

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

উত্তর:


24

ব্যক্তিগতভাবে, আমি আমার স্থানীয় সংস্করণগুলি প্রতিদিন আপডেট করি।

আপনি যে দৃশ্যের বর্ণনা দিয়েছেন তাতে আমি অতিরিক্ত মাইল এগিয়ে যাব

  • নতুন, দীর্ঘ বৈশিষ্ট্যের জন্য একটি শাখা তৈরি করা হচ্ছে।
  • মূল লাইন থেকে এই নতুন শাখায় প্রায়শই মার্জ করুন।

এই পথে,

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

আমি যেমন দেখছি ত্রুটিগুলি হ'ল

  • প্রধান থেকে মার্জ করা ম্যানুয়ালি করতে হবে (বা স্ক্রিপ্ট)
  • এটি আরও "প্রশাসন" লাগে

2
আপনি ঠিক বলেছেন যে ট্রাঙ্কের পরিবর্তে বৈশিষ্ট্য শাখাগুলিতে কাজ করা সর্বদা ভাল। সমস্যাটি হ'ল বেশিরভাগ সিভিসিএস মার্জ করার সময় একটি দুর্বল কাজ করে, তাই আমি সিভিসিএসে জানি বেশিরভাগ প্রোগ্রামার বেশিরভাগ সময়ই একটি একক শাখায় লেগে থাকেন। প্রশ্নটি হল, আপনি কি তাদের বলতে পারেন যে সাধারণভাবে প্রায়শই প্রায়শই আপডেট করা ভাল?
জানস

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

6

হ্যাঁ, প্রায়শই আপডেট করা ভাল ধারণা। আপনি হার্ড মার্জ সংঘাত এড়াতে প্রায়শই আপডেট করেন এবং এটি বিভিন্ন পরিবর্তনগুলির সমস্যা সহ সফ্টওয়্যার কনফিগারেশন ম্যানেজমেন্ট (এসসিএম) জ্ঞানের মূল বিষয়গুলি।

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

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

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


4

প্রশ্নের তৃতীয় বুলেট পয়েন্টটি কেবল ভুল :

  • আপনি একটি নতুন বৈশিষ্ট্যে কাজ করছেন যা অবশ্যই বেশ কয়েক দিন সময় নেবে এবং আপনি এর আগে প্রতিশ্রুতি রাখতে সক্ষম হবেন না কারণ এটি বিল্ডটি ভেঙে দেবে।

আপনি যদি জানেন যে আপনি এমন কিছু নিয়ে কাজ করছেন যা আপনি কিছু সময়ের জন্য প্রতিশ্রুতিবদ্ধ না করতে পারেন তবে এটি শাখা ব্যবহারের জন্য পাঠ্যপুস্তকের উদাহরণ।

আপনার অনেক পরিবর্তন মুলতুবি থাকা অবস্থায় নিজেকে এমন অবস্থায় রাখবেন না। যদি আপনি জানেন যে আপনি কিছু সময়ের জন্য আপনার প্রকল্পের প্রধান শাখায় প্রতিশ্রুতিবদ্ধ করতে পারবেন না, তবে অন্য একটি শাখায় কাজ করুন। এবং সেখানে, প্রায়শই প্রতিশ্রুতিবদ্ধ

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

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


2

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

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


1

আমি স্থানীয়ভাবে বিতরণকৃত সংস্করণ নিয়ন্ত্রণ ব্যবহার করা আরও সুবিধাজনক বলে মনে করি। এটি হ'ল আমি গিটটি সাবভার্সন ক্লায়েন্ট হিসাবে ব্যবহার করি। এটির সুবিধাগুলি যা:

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

0

আপনি যদি কোনও নতুন বৈশিষ্ট্য যুক্ত করছেন, আপনি কি নতুন একটি একক উত্স ফাইল (এবং একটি মিলের বাহ্যিক ইন্টারফেস শিরোনাম ফাইল) তৈরি করতে পারবেন?

আমি উদ্বিগ্ন যে একটি "নতুন বৈশিষ্ট্য" এর ব্যাপক প্রভাব রয়েছে? অবজেক্ট ওরিয়েন্টেশন আর একবারের মতো এটি হতে পারে বাজওয়ার্ড না, তবে সেই দৃষ্টান্তে যোগ্যতা রয়েছে।

এইভাবে আপনি ফ্রেমওয়ার্কটি তৈরি করতে পারেন (বাহ্যিক ইন্টারফেস, প্লাস স্টাব ফাংশন) এবং প্রতিশ্রুতিবদ্ধ হন যে তারপরে ন্যূনতম তৃতীয় পক্ষের প্রভাব থাকতে হবে, আপনি নিজের বিকাশটি শেষ করলেও?

আপনি যে পরিস্থিতিতে বর্ণনা করেছেন তাতে আমি মনে করি কম, বড় ফাইলের চেয়ে আরও বেশি ছোট উত্স ফাইল থাকা ভাল।


0

কোনও বিতরণকৃত সংস্করণের চেয়ে কেন্দ্রীভূত সংস্করণ নিয়ন্ত্রণের জন্য এটি কীভাবে আলাদা?

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

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

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


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

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

সিভিসিএসে আপডেট অপারেশনটি কম নিরাপদ কারণ আপনি ডিভিসিএসে মার্জ করার জন্য আপনি যেভাবে রোল করতে পারেন সেভাবে এটি রোল করতে পারবেন না। এই কারণেই সিভিসিএস অংশটি তাৎপর্যপূর্ণ, এবং ডিভিসিএসে এই প্রশ্নটি সামান্যই অর্থপূর্ণ হবে।
জানুস

অপেক্ষা করা অসুবিধা বা ঝুঁকি হ্রাস করতে পারে না, তাই আপনি আরও ঘন ঘন আপডেটের জন্য তর্ক করছেন।
এপ্রোগ্রামার

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

0

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.