সংস্করণ নিয়ন্ত্রণ কখন খুব বড় হয়? [বন্ধ]

Question

আমি বেশ কয়েকটি জায়গায় শুনেছি "বড়ো বড়ো কমিট করবেন না" তবে আমি আসলে "বড়" প্রতিশ্রুতিটি কখনই বুঝতে পারি নি। যদি আপনি সম্পর্কিত কিছু কিছু ফাইল নিয়ে কাজ করেন তবে এটি কি বড়? আপনি একবারে কোন প্রকল্পের কতগুলি অংশে কাজ করা উচিত?

আমার কাছে আমার "ছোট ছোট কমিট" করার চেষ্টা করতে সমস্যা হয় কারণ আমি ভুলে গেছি বা এমন কিছু তৈরি করি যা অন্যরকম কিছু তৈরি করে যা অন্য কিছু তৈরি করে। তারপরে আপনি এই জাতীয় জিনিসগুলি শেষ করবেন:

কাস্টম আউটগোয়িং সারি তৈরি

বট
-নউ ক্ষেত্রের URL কিউ, যা সিঙ্গলথ্রেডএক্সেক্টর ছাড়া আর কিছুই নয়
বার্তা প্রেরণ না হওয়া পর্যন্ত -SendMsg ব্লক করে এবং বার্তা পাওয়ার পরে অপেক্ষা যোগ করে
প্রেরিত
-ডমিনএক্সিস্ট কলগুলি আপডেট হয়েছে (কন্ট্রোলার দেখুন)
প্রেরণ-পাঠাতে কল রিমুভ করা

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

অ্যাডমিন
নতুন পদ্ধতিগুলি অ্যাপ্রোপিয়েট অবজেক্ট অ্যাডমিন পেতে সার্ভার এবং গেটচ্যানেল পান
অন্তর্গত

BotEvent
-টোস্ট্রিং () এছাড়াও অতিরিক্ত এবং অতিরিক্ত 1 দেখায়

চ্যানেল
-চ্যানেল ক্ষেত্রটির নামকরণ করা হয়েছে
চ্যানেলে ফিক্সড টাইপ (অন্তর্)

সার্ভার
-মুভড অ্যাডমিনএক্সিস্টালারে রয়েছে

PluginExecutor
-মিনার পরীক্ষার যোগ করা হয়েছে, পরে সরিয়ে ফেলা হবে

জেএস প্লাগইনস
ফ্রেমওয়ার্ক পরিবর্তন আপডেট
কন্ট্রোলআরআইনস্ট্যান্স সহ -পরিবর্তিত InstanceTracker.getController ()
-ভিএলসি এখন নিজের ফাইলে কথা বলুন

বিভিন্ন এনবি প্রকল্প আপডেট এবং পরিবর্তন

---

প্রভাবিত ফাইল
/Trunk/Quackbot-Core/dist/Quackbot-Core.jar পরিবর্তন করুন
/Trunk/Quackbot-Core/dist/README.TXT পরিবর্তন করুন
/Trunk/Quackbot-Core/nbproject/private/private.properties পরিবর্তন করুন
/Trunk/Quackbot-Core/nbproject/private/private.xML পরিবর্তন করুন
/Trunk/Quackbot-Core/src/Quackbot/Bot.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/Controller.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/LuginExecutor.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/info/Admin.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/info/Channel.java সংশোধন করুন
/Trunk/Quackbot-Core/src/Quackbot/info/Server.java সংশোধন করুন
/Trunk/Quackbot-GUI/dist/Quackbot-GUI.jar পরিবর্তন করুন
/Trunk/Quackbot-GUI/dist/README.TXT পরিবর্তন করুন
/Trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar পরিবর্তন করুন
/Trunk/Quackbot-GUI/nbproject/private/private.properties পরিবর্তন করুন
/Trunk/Quackbot-GUI/nbproject/private/private.xML পরিবর্তন করুন
/Trunk/Quackbot-GUI/src/Quackbot/GUI.java সংশোধন করুন
/Trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java সংশোধন করুন
/Trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java মুছুন
/Trunk/Quackbot-Impl/dist/Quackbot-Impl.jar পরিবর্তন করুন
/Trunk/Quackbot- ইমপ্ল / ডিস্ট / README.TXT পরিবর্তন করুন T
পরিবর্তন করুন / ট্রাঙ্ক / কিউকবট- আইপিএল / ডিসিস্ট / লিবি / ক্যাকবট- কোর.জার
পরিবর্তন করুন / ট্রাঙ্ক / কিউকবট- আইপিএল / ডিসিস্ট / লিবি / ক্যাকবট- জিইউআই.জার
পরিবর্তন করুন / ট্রাঙ্ক / কিউকবট- আইপিএল / ডিসিস্ট / লিবি / ক্যাকবট- প্লাগইনস.জার
/Trunk/Quackbot- আইএমপি / লিব / জাভেরেল.স্ট্যাটগুলি পরিবর্তন করুন
/Trunk/Quackbot-Impl/lib/jrebel.info যোগ করুন
/ ট্রাঙ্ক / কিউকবট- আইপিএল / এনবিপ্রজেক্ট / প্রাইভেট / প্রাইভেট.প্রপ্রেটিস সংশোধন করুন
পরিবর্তন করুন / ট্রাঙ্ক / কিউকবট- ইমপ্ল / এনবিপ্রজেক্ট / প্রাইভেট / প্রাইভেট.এক্সএমএল
/Trunk/Quackbot- আইএমপিএল / এনবিপ্রজেক্ট / প্রজেক্ট.প্রোপার্টি সংশোধন করুন
পরিবর্তন / ট্রাঙ্ক / কিউকবট- ইমপ্ল / প্লাগইনস / সিএমডিএস / অ্যাডমিন / রিলোড.জেএস
যোগ / ট্রাঙ্ক / কোয়াকবট-ইমপ্ল / প্লাগইন / সিএমডি / অপারেটর / হোস্টব্যান
পরিবর্তন / ট্রাঙ্ক / কিউকবট- আইপিএল / প্লাগইনস / সিএমডিএস / অপারেটর / মিউট.জেএস
পরিবর্তন / ট্রাঙ্ক / কিউকবট- আইপিএল / প্লাগইনস / সিএমডিএস / লাইকোফ্রেয়াক / সিআরপ্লেইং.জেএস
পরিবর্তন / ট্রাঙ্ক / কিউকবট- আইপিএল / প্লাগইনস / সিএমডিএস / ক্লিওফোরাক / ফ্লাটমোড.জেএস
/Trunk/Quackbot- ইম্পল / প্লাগইনস / ফ্লাইটারস / ওনজাইন.জেএস সংশোধন করুন
পরিবর্তন / ট্রাঙ্ক / কিউকবট- আইপিএল / প্লাগইনস / প্রকাশক / অনকিউটি.জেএস
/Trunk/Quackbot- ইম্পল / প্লাগইনস / টেস্ট কেস.জেএস সংশোধন করুন
/Trunk/Quackbot- ইম্পল / প্লাগইনস / ইউটিলস / ওয়াটসপ্লেইং.জেএস যোগ করুন
পরিবর্তন করুন / ট্রাঙ্ক / কিউকবট- আইপিএল / এসআরসি / কিউকবট / আইপিএল / স্যান্ডবক্স.জভা
যোগ / ট্রাঙ্ক / কোয়াকবট-ইমপ্ল / ভিএলসি_এইচটিপি
/Trunk/Quackbot- ইম্পল / ভিএলসি_এইচটিটিপি / কর্নার এইচটিএমএল যুক্ত করুন
/Trunk/Quackbot- প্লাগইনস / ডিস্ট / কোয়াকবট- প্লাগইনস.জার সংশোধন করুন
/Trunk/Quackbot- প্লাগইনস / ডিস্ট / README.TXT পরিবর্তন করুন
/Trunk/Quackbot- প্লাগইনস / ডিস্ট / লিবি / ক্যাকবট- কোর.জার পরিবর্তন করুন
/Trunk/Quackbot- প্লাগইনস / এনবিপ্রজেক্ট / প্রাইভেট / প্রাইভেট.প্রপ্রেটিস সংশোধন করুন
/Trunk/Quackbot- প্লাগইনস / এনবিপ্রজেক্ট / প্রাইভেট / প্রাইভেট.এক্সএমএল পরিবর্তন করুন
/Trunk/Quackbot- প্লাগইনস / এসআরসি / কিউকবট / প্লাগইনস / জেএসপি প্লাগইন.জাভা সংশোধন করুন
যোগ / ট্রাঙ্ক / কোয়াকবট-প্লাগইনস / ভিএলসি_এইচটিপি
/Trunk/global-lib/jrebel.jar যোগ করুন

হ্যাঁ ....

তাই প্রশ্নের জন্য:

• কোন কমিট যখন খুব বেশি হয়ে যায় তার জন্য কয়েকটি কারণ কী ( অ-স্পষ্ট স্টাফ )?
• কীভাবে আপনি এই ধরনের কমিটগুলি প্রতিরোধ করতে পারেন? দয়া করে বিশদ দিন
• যখন আপনার জিনিসগুলি যখন দ্রুতগতিতে চলেছে তখন আপনি যখন আধা-প্রাথমিক পর্যায়ে বিকাশ করবেন তখন কী হবে? বিশাল কমিট এখনও ঠিক আছে?

Comments

list.madduck.net/pipermail/vcs-home/2010- সেপ্টেম্বর / 2000276.html এমন একটি ক্ষেত্রে বর্ণনা করেছে যেখানে তথ্য ফাইলগুলি নিজেরাই সংগ্রহশালায় কার্যকরভাবে সংরক্ষণ করার জন্য খুব বড়। (তবে আমি নিশ্চিত যে আপনি এখানে যে বিষয়ে কথা বলছেন তা নয়))

— কেন ব্লুম

গঠনমূলক নয় ????? আমি এখানে একটি টন শিখেছি! মোডস, দয়া করে আপনার কঠোর প্রশ্ন বন্ধ করে দিন!

— রিচার্ড

আপনি শত শত ফাইলের সাথে কোন একক প্রতিশ্রুতি কখনও দেখেননি, এর কোনও কাট আপ সংকলন করবে না?

— জোশুয়া

Answer 1

আমার কাছে আমার "ছোট ছোট কমিট" করার চেষ্টা করতে সমস্যা হয় কারণ আমি ভুলে গেছি বা এমন কিছু তৈরি করি যা অন্যরকম কিছু তৈরি করে যা অন্য কিছু তৈরি করে।

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

বড় কমিটের সমস্যা হ'ল:

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

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

(আর একটি বিষয় হ'ল আপনি যখন প্রাথমিক আমদানি করেন তবে এটি উপরে তালিকাভুক্ত সমস্যাগুলির দৃষ্টিকোণ থেকে সমস্যাযুক্ত নয়))

Comments

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

— ডা হ্যানিবাল লেেক্টর

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

— দ্রুত_

এছাড়াও, পিআরএম-এর প্রতিশ্রুতি প্রতিশ্রুতি দ্বারা পর্যালোচনা করা লোকদের জন্য ছোট কমিটস = ছোট পার্থক্য

— পিটার

Answer 2

একক দায়িত্বের নীতি।

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

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

Comments

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

— রিভনফল

Answer 3

কল্পনা করুন যে ক্লায়েন্টটি একটি নির্দিষ্ট পরিবর্তন আনতে বলেছে - উদাহরণস্বরূপ একটি বিধি যুক্ত করতে যে "যাই হোক না কেন" তারিখের দু'দিনের মধ্যে কিছু বা অন্য কিছু করা যায় না। তারপরে, আপনি পরিবর্তনটি করার পরে, তারা তাদের মন পরিবর্তন করে। আপনি আপনার প্রতিশ্রুতি ফিরে পেতে চাইবেন। যদি এটি সম্পর্কিত হয় না সম্পর্কিত সম্পর্কযুক্ত প্রতিবেদনের সাজানোর ক্রম পরিবর্তন সম্পর্কে কিছু বিষয় নিয়ে, তবে আপনার জীবন একটি দুঃখজনক।

একটি কাজের আইটেম, একটি পরিবর্তন। ক্লায়েন্টের কাছ থেকে একটি অনুরোধ, একটি পরিবর্তন একটি জিনিস আপনি নিজের মন পরিবর্তন করতে পারেন, একটি পরিবর্তন। কখনও কখনও এর অর্থ এটি কোডের একক লাইন। কখনও কখনও এটি ডাটাবেস স্কিমা সহ দশটি ভিন্ন ফাইল। সেটা ঠিক আছে.

Comments

"1 লাইন / 10 ফাইল" এর সাথে সম্পূর্ণ সম্মত হন। আইনগুলির একটি সেট সেট দ্বারা এই প্রশ্নের উত্তর দেওয়ার জন্য অনেকগুলি ভেরিয়েবল রয়েছে

— পুলক আগরওয়াল

কেবলমাত্র আমি যুক্ত করব তা হ'ল "এক অনুরোধ, একটি পরিবর্তন" এর চেয়েও ছোট হয়ে যাওয়া বোধগম্য। বৃহত্তর অনুরোধগুলি ছোট, বর্ধিত পরিবর্তনসমূহে বিভক্ত করা উচিত। (অন্য উত্তরে উল্লিখিত হিসাবে, একটি শাখার বিকাশ এটিকে সহজতর করতে পারে) অবশেষে, আমি পূর্বোক্ত মন্ত্রগুলি যেমন: "একটি অনুরোধ, একটি (বা আরও!) চেঞ্জসেটগুলি" রূপান্তর করতে পারি।

— রিনোগো

Answer 4

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

আপনি যা সমাপ্ত করছেন সে অনুযায়ী প্রতিরোধ কমিট করে। উপরের উদাহরণে আমি নিয়ামক যুক্তির পরে, ডাটাবেস কাজের পরে এবং স্ক্রিপ্টগুলির পরে প্রতিশ্রুতিবদ্ধ। প্রতিশ্রুতিবদ্ধতা বন্ধ করবেন না কেবল কারণ আপনি জানেন কী পরিবর্তন হয়েছে। অন্যান্য ব্যক্তিরা আপনার "পরিবর্তিত স্টাফ" লগ বার্তার প্রতিশ্রুতিবদ্ধ এবং আপনি কী ধূমপান করছিলেন তা অবাক করে দেবে।

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

Answer 5

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

Answer 6

এই উদাহরণটি এমন একটি প্রতিশ্রুতি দেখায় যা খুব বড়।

থাম্বের নিয়ম হিসাবে, একটি বাক্যে বা পাঠ্যের একটি লাইনের পরিবর্তনের বর্ণনা দিন। (এই নিয়মের ভিত্তিতে, প্রতিশ্রুতিটি 10-15 টি ছোট ছোট করে ভাগ করা উচিত)) আপনি যদি এক লাইনে কমিটের পক্ষে পর্যাপ্ত মন্তব্য করতে না পারেন তবে এটি ইতিমধ্যে খুব বড়।

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

Comments

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

— কেন ব্লুম

@ কেন: আমার লক্ষ্য এখানে প্রশ্নটি জিজ্ঞাসা করা ব্যক্তিকে সহায়তা করা, বিশ্বের সমস্ত বিদ্যমান বিদ্যমান সোর্স কোড সংগ্রহস্থলগুলিকে কভার করার নিয়ম না নিয়ে আসা।

— আজহেগ্লোভ

Answer 7

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

1. 3 মাস আগে থেকে মডেল চালান
2. বাগ যদি এখনও আউটপুট থেকে থাকে তবে 4.5 মাস আগে মডেলটি চালান
3. ... যতক্ষণ না আমি খারাপ আউটপুটে ফলন করে এমন প্রতিশ্রুতি না পাওয়া পর্যন্ত পুনরাবৃত্তি করুন

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

আমি আপনার সমস্যাটি ছোট ছোট কাজগুলিতে বিভক্ত করার পরামর্শ দেব (আদর্শভাবে প্রতিটি কাজকে একটি বাগ ট্র্যাকারে রেখে দিন)। আপনি প্রতিটি কাজ শেষ করার সাথে সাথে একটি প্রতিশ্রুতিবদ্ধ করুন (এবং আপনার বাগ ট্র্যাকারে সেই বাগ / বৈশিষ্ট্যটি বন্ধ করুন)।

Comments

কমিটের মধ্যে মাসগুলি বেশিরভাগ আধুনিক পদ্ধতিতে হুবহু কমিটের মতো শোনা যায় ...

— রিগ

Answer 8

এটি যে প্রতিশ্রুতিটি সত্য তা গুরুত্বপূর্ণ নয়, এটি পরিবর্তনের সুযোগ যা আপনার প্রতিশ্রুতিগুলি কীভাবে সংগঠিত হয় তা নির্ধারণ করা উচিত।

আপনি, উদাহরণস্বরূপ প্রতিটি উদাহরণের পরিবর্তন করতে পারে __macro1থেকে __macro2বৃহৎ কোড বেস, যা 200 ফাইল পরিবর্তন। 200 প্রতিশ্রুতি সেই ক্ষেত্রে মীমাংসিত হবে না।

আপনি যা শেষ করতে চান তা কোনও একক সংশোধনীতে ভান্ডারটি টানতে সক্ষম হবেন এবং বিল্ডিংয়ের কাজ করে যাবেন। আপনার কাছ থেকে পরিবর্তন হয়নি libfooকরতে libbar? আমি আশা করি পরিবর্তনের সাথে সাথে আপনার বিল্ড স্ক্রিপ্টগুলি এবং মেকফিলগুলিও আপডেট করা (বা যা প্রযোজ্য তা) অন্তর্ভুক্ত রয়েছে।

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

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

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

Answer 9

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

তার না, তাই একটি প্রশ্ন "বৃহৎ করে না" হিসাবে না ছোট করে তৈরি করেন - আদর্শ ছোট স্ব কমিট হচ্ছে পরিবর্তন রয়েছে।

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

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

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

আরও একটি বিষয় - যদি আপনার কাজের মাঝে এমন কিছু আসে যা আরও তাত্ক্ষণিক মনোযোগের প্রয়োজন হয় তবে আপনাকে এটিকে পৃথকভাবে পরিবর্তন করতে হবে (আদর্শভাবে ফোল্ডারগুলির সম্পূর্ণ স্বতন্ত্র সেটে) এবং এটি আলাদাভাবে প্রতিশ্রুতিবদ্ধ।

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

Answer 10

খুব কমপক্ষে, আপনি যখনই নিজেকে নিজেকে ভাবেন তখন প্রতিশ্রুতিবদ্ধ হওয়ার জন্য প্রশিক্ষণ দিন "আমি আমার এতোদিনের অগ্রগতি পছন্দ করি এবং আমি যে পরিবর্তনগুলি করতে যাচ্ছি তা কোনও বিপর্যয় হলে আমি এটিকে হারাতে চাই না।" তারপরে কোনও সমস্যা সমাধানের জন্য আপনি যে কোনও মৃত প্রান্তটি চেষ্টা করেছেন বা বিশেষ ডিবাগিং কোডটি আপনি যুক্ত করেছেন তা দূরে সরিয়ে দেওয়ার জন্য ভিসিএসের সুবিধা নেওয়ার বিকল্প রয়েছে। (যেমন git reset --hardবা এর সাথে rm -rf *; svn update)

Answer 11

এখানে কোন কঠোর এবং দ্রুত নিয়ম নেই, বিভাজক রেখার অতীত নেই যা আপনার প্রতিশ্রুতিবদ্ধতা অনেক বড়।

সেখানে হয় তবে, একটি গাইডলাইন যে ছোট করে আরও ভাল হয় কারণ মধ্যে (অর্থাত যে লাইন সংগঠনের probaby অত্যধিক যায়)।

আমি এই ধরণের নির্দেশিকাগুলি মাথায় রাখি:

• একটি একক প্রতিশ্রুতিতে মাত্র একটি বাগ ফিক্সের জন্য পরিবর্তনগুলি অন্তর্ভুক্ত করা উচিত
• একটি একক প্রতিশ্রুতি অর্ধ দিনের বেশি কাজ অন্তর্ভুক্ত করা উচিত নয়
• একটি একক প্রতিশ্রুতি বিল্ড ব্রেক করা উচিত নয়

অবশ্যই - এগুলি আমি মনে রাখি - ওয়াইএমএমভি। বিভিন্ন বিকাশকারী বিভিন্ন স্তরের গ্রানুলারিটির পক্ষে।

Answer 12

প্রতিশ্রুতি যত কম ছোট, কোনও সম্ভাব্য রিগ্রেশনটি কোথা থেকে এসেছে তা ঠিক খুঁজে পাওয়া সহজ।

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

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

মূলটি হ'ল প্রতিবার পারমাণবিক পরিবর্তন করার সময় আপনার "ব্যক্তিগত" শাখায় প্রতিশ্রুতিবদ্ধ হওয়া এবং তারপরে আপনি নিয়মিতভাবে আপনার শাখাটি মার্জ করতে পারেন, উদাহরণস্বরূপ প্রতি সপ্তাহে।

একটি ডিভিসিএস ব্যবহার করে, আপনার কর্মপ্রবাহটি দেখতে দেখতে এমন হতে পারে:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

একটি কেন্দ্রীয় ভিসি ব্যবহার করে:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Answer 13

আপনি সম্ভবত উক্তিটি শুনেছেন যে যখন আপনি আরও কিছু দূরে নিতে না পারেন তখনই পরিপূর্ণতা। কমিট আকারের জন্য এটি আপনার মানকেও বর্ণনা করে describe

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

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

Answer 14

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

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

Comments

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

— TheLQ

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

— কেন ব্লুম

@ দ্য এলকিউ, এইভাবে জিনিসগুলি আমাদের পক্ষে ভালভাবে কাজ করে। মনে রাখবেন, আপনার " কোথাও " কোথাও থাকা দরকার ...

Answer 15

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

git citool আপনাকে কোনও ফাইলের (বা কোন নির্দিষ্ট লাইনগুলি) নির্দিষ্ট কোন প্রতিশ্রুতিবদ্ধ করতে হবে তা নির্দিষ্ট নির্বাচনের অনুমতি দিতে পারে, যাতে আপনি একই ফাইলটিতে করা (অ-ওভারল্যাপিং) পরিবর্তনগুলি বেশ কয়েকটি কমিটে ভেঙে ফেলতে পারেন।

(দেখে মনে হচ্ছে আপনি সাবভারশন ব্যবহার করেছেন Sub সাবভার্সনের জন্য এটি এমন কোনও সরঞ্জাম সম্পর্কে আমি জানি না, তবে আপনি git-svnগিটের জন্য সাবভার্সন অ্যাডাপ্টার ব্যবহার করতে পারেন যা আপনার জীবনকে পরিবর্তন করে দেবে))

Comments

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

— TheLQ

@ দ্য এলকিউ: ঠিক আছে, আপনি যদি আপনার প্রতিশ্রুতিগুলি যৌক্তিক অংশগুলিতে সংগঠিত করতে চান তবে আপনাকে তা করতে হবে: হয় তাড়াতাড়ি প্রতিশ্রুতিবদ্ধ হওয়া এবং প্রায়শই প্রতিশ্রুতিবদ্ধ হওয়া সম্পর্কে খুব শৃঙ্খলাবদ্ধ হন (এবং git rebaseসত্যিকার অর্থেই এর অংশ হিসাবে প্রতিশ্রুতিতে যোগ দিতে ভয় পাবেন না পুনর্বিবেচনা) বা git citoolআপনি দিন শেষে প্রতিশ্রুতিবদ্ধ করতে প্রস্তুত থাকাকালীন জিনিসগুলিকে যৌক্তিক অংশগুলিতে বিভক্ত করার জন্য সূক্ষ্ম দন্তযুক্ত চিরুনি দিয়ে সঠিকভাবে শিখুন ।

— কেন ব্লুম

Answer 16

যত বড় কমিট, ততই সম্ভবত আপনি বিল্ডটি ভেঙে ফেলবেন এবং আপনার দলের বাকী অংশের দ্বারা অর্থ প্রদান করতে পারবেন। আমি দিনে দুবার পরিবর্তন করার চেষ্টা করি। দুপুরের খাবারের আগে এবং বাসায় যাওয়ার আগে। সুতরাং @ 12 টা এবং 4:30 pm আমি চেষ্টা করি সবকিছু কাজ করার জন্য এবং প্রতিশ্রুতি দেওয়ার জন্য প্রস্তুত। আমি অনুশীলন আমার জন্য কাজ করে।

Answer 17

আপনার প্রশ্নের উত্তর দিতে:

1) আমার কাছে মানক প্রতিশ্রুতিটিকে বড় হিসাবে বিবেচনা করা হয় যদি এটি একাধিক জিনিস করে। জিনিস হিসাবে আমি একটি বাগ সংশোধন বা একটি বৈশিষ্ট্য যুক্ত মানে।

২) এ জাতীয় অঙ্গীকারকে অভ্যাস এবং যখনই আপনি কিছু শেষ করেন প্রতিশ্রুতিবদ্ধ করে প্রতিরোধ করুন।

৩) বিকাশের আধা-প্রাথমিক পর্যায়ে, আমি কমিটদের ফাইলগুলির প্রথম তৈরিটি অন্তর্ভুক্ত করার অনুমতি দেব যা পরে ব্যবহৃত হবে।

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

হ্যাঁ, এটি প্রচুর পরিমাণে কমিট তৈরি করে, তবে এটি আপনাকে পরিবর্তনের একটি বৃহত ধারাবাহিকটি আবার রোল করার পরিবর্তে ঠিক কী ঘটেছে তা রোলব্যাক করতে দেয় যা একই সময়ে প্রতিশ্রুতিবদ্ধ হয়েছিল যেখানে কেবলমাত্র পরিবর্তনের মধ্যে একটি সমস্যার কারণ হয়ে দাঁড়িয়েছে।

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

Answer 18

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

সমস্যাটি হ'ল ক্লায়েন্টটি একটি ভাগ করা সার্ভারে রয়েছে, এসএনএন ক্লায়েন্টকে মেরে ফেলা হয় (বা অন্য কোনও সফ্টওয়্যার) যদি এটি আরও এক মিনিট চালায় তবে।

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

আমার আগে বিকাশকারী কখনও কোনও সংস্করণ নিয়ন্ত্রণ ব্যবস্থা ব্যবহার করেনি।

Answer 19

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