গিট কমিট বার্তায় আমার কি অতীত বা বর্তমান কাল ব্যবহার করা উচিত? [বন্ধ]


530

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

এখানে একটি সাম্প্রতিক জন রেসিগ প্রতিশ্রুতি দিয়েছিলেন যে তারা দু'জনকে একটি বার্তায় দেখায়:

ম্যানিপুলেশন পরীক্ষায় আরও কিছু জিকুয়েরি সেট ফলাফলের ঝাঁকুনি। প্রত্যাশিত পরীক্ষার ফলাফলের ক্রমও স্থির করে।

এটা কোন ব্যাপার? আমার কোনটি ব্যবহার করা উচিত?


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

একই প্রশ্ন: stackoverflow.com/questions/1753808/...
wip


আরও দেখুন github.com/agis-/git-style-guide
Agis

3
@ ইউনিল যদি এটি এখানে মতামত ভিত্তি করে বন্ধ হয় তবে এটি সেখানেও মতামত থাকার কারণে বন্ধ হয়ে যাবে।
র‌্যাচেট ফ্রিক

উত্তর:


600

বর্তমান কাল, অত্যাবশ্যক-শৈলীর কমিট বার্তাগুলির পছন্দ গীত থেকেই আসে। থেকে নথিপত্র / SubmittingPatches গীত মধ্যে রেপো:

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

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


89
আমি মনে করি এটি একটি দুর্দান্ত পছন্দ। পৃথক আকারে প্রতিশ্রুতিবদ্ধতা কী তা সম্পর্কে ভেবে দেখুন: কীভাবে পূর্বের অবস্থা থেকে নতুন রাজ্যে যেতে হয় তার জন্য নির্দেশাবলীর একটি সেট। যেমন পার্থক "এই লাইনটি এখানে যুক্ত করুন, এই লাইনটি এখানে সরিয়ে দিন" ঠিক তেমনই প্রতিশ্রুতিবদ্ধ বার্তাটি গুণগত দিক থেকে বলেছে "এই পরিবর্তন করুন"। (হ্যাঁ, গিটটি কেবল মেটাডেটা সহ একটি গাছ হিসাবে প্রতিশ্রুতি রাখে, কিন্তু একটি মানুষের কাছে,
কমিটের

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

10
@ ওসরেঙ্ক: ফাইলের পরবর্তী সংস্করণগুলির একটি কারণ রয়েছে: "অপরিহার্য মেজাজে আপনার পরিবর্তনগুলি বর্ণনা করুন, উদাহরণস্বরূপ '' জাইজজি ডো ফ্রটজ করুন 'এর পরিবর্তে' [এই প্যাচ] জাইজি কে ফ্রটজ করুন 'বা' [আমি] ফ্রুটজ করতে জাইজি পরিবর্তন করেছেন ', যেন আপনি কোডবেসটির আচরণ পরিবর্তন করার জন্য আদেশ দিচ্ছেন। "
মিপাদি

44
প্রতিশ্রুতিবদ্ধ বার্তাটি আবশ্যকীয়, বর্তমান কাল হওয়া উচিত কারণ গিটের সাহায্যে আপনি বা অন্য কারও কাজ শেষ হতে পারে rebaseবা cherry-pickসেক্ষেত্রে কমিটটি তার মূল প্রসঙ্গে বাইরে ব্যবহার করা যেতে পারে। ফলস্বরূপ, প্রতিশ্রুতিবদ্ধ বার্তাটি পাঠকের আশেপাশের কোনও প্রতিশ্রুতি বার্তা দেখার প্রত্যাশা ছাড়াই স্বতন্ত্র লেখা উচিত written আপনি যখন চেরি বাছাই প্যাচগুলি ব্যবহার করেন তখন "ফিক্স কুইকোর্টোর্ট অ্যালগরিদম" বা "বাছাই করা: পারফরম্যান্স উন্নত করুন" পরিবর্তে "ফিক্সড বাগ # 124" বা "পারফরম্যান্সের উন্নতির জন্য পরিবর্তিত বাছাই করা" প্রয়োগ করা আরও বোধগম্য হয়।
মিক্কো রেন্টালাইনেন

5
আমি এটি সম্পর্কে যেভাবে ভাবছি তা হ'ল বার্তাটি আমাকে বলবে যে আমি যদি আমার শাখায় এই প্রতিশ্রুতি প্রয়োগ করতে চান তবে কী পরিবর্তন হবে। আমি এটিকে লগ হিসাবে ভাবি না তবে হিসাবে উল্লেখ করেছি যে আমি চলে যেতে পারি এবং যখন আমি একটি নির্দিষ্ট রাজ্যটি বেছে নেব তখন কী ঘটবে তা আমার জানতে হবে।
স্টিনিবোট

357

আপনার প্রকল্পের প্রায় সর্বদা অতীত কাল ব্যবহার করা উচিত । যাই হোক না কেন, প্রকল্পটি সর্বদা ধারাবাহিকতা এবং স্বচ্ছতার জন্য একই উত্তেজনা ব্যবহার করা উচিত।

আমি বর্তমান কালকে ব্যবহার করার জন্য যুক্তিযুক্ত অন্যান্য কিছু যুক্তি বুঝতে পারি তবে সেগুলি সাধারণত প্রয়োগ হয় না। নিম্নলিখিত বুলেট পয়েন্টগুলি বর্তমান কালে লেখার জন্য সাধারণ যুক্তি এবং আমার প্রতিক্রিয়া।

  • বর্তমান কালকে লেখার মাধ্যমে কাউকে বলে যে প্রতিশ্রুতি প্রয়োগ করা তার পরিবর্তে আপনি যা করেছেন তা করবেন।

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

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

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

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

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

  • সমন্নয়। এটি অনেক প্রকল্পে (গিট নিজেই সহ) এইভাবেই হয়। এছাড়াও গিট সরঞ্জামগুলি যা কমিট তৈরি করে (যেমন গিট মার্জ বা গিট রিভার্ট) এটি করে।

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

  • লোকেরা কেবল "এই কোডবেজের সাথে কী ঘটেছিল" তা জানতে ইতিহাস পড়েন না, "এই প্রতিশ্রুতিটি চেরি-বাছাইয়ের পরে কী হয়", বা "এই কোডের কারণে আমার কোড বেসে কী ধরণের নতুন জিনিস ঘটবে" এর মতো প্রশ্নের উত্তর দিতে পারে People আমি ভবিষ্যতে একীভূত হতে পারি বা নাও পারি "।

প্রথম পয়েন্ট দেখুন। একজন ব্যক্তি প্রতিশ্রুতি বার্তা পড়ার সময় 99.99% ইতিহাস পড়ার জন্য - ইতিহাসটি অতীত কাল থেকে পড়া হয়। 0.01% সময় সিদ্ধান্ত নেবে যে তারা এই প্রতিশ্রুতি প্রয়োগ করতে হবে বা তাদের শাখা / ভান্ডারগুলিতে এটি সংহত করবে কিনা। 99.99% 0.01% মারধর করে।

  • এটি সাধারণত খাটো হয়

আমি কখনও ভাল যুক্তি দেখিনি যা বলেছে যে অনুপযুক্ত কাল / ব্যাকরণ ব্যবহার করুন কারণ এটি খাটো। মানক 50 টি অক্ষরের বার্তার জন্য আপনি সম্ভবত গড়ে 3 টি অক্ষর সংরক্ষণ করবেন। বলা হচ্ছে, বর্তমানে বর্তমান সময়টি সম্ভবত কয়েকটি অক্ষর সংক্ষিপ্ত হবে।

  • আপনি আপনার ইস্যু / বৈশিষ্ট্য ট্র্যাকারের টিকিটের শিরোনামের সাথে আরও ধারাবাহিকভাবে নাম লেখাতে পারেন (যা অতীতের কালকে ব্যবহার করে না, যদিও মাঝে মাঝে ভবিষ্যত হয়)

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

ইতিহাস (যেমন প্রতিশ্রুতিবদ্ধ প্রতিশ্রুতি) এমন কিছু হিসাবে রচিত যা অতীতে করা হয়েছিল (যেমন সমস্যাটি স্থির ছিল )।


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

56
গিটের স্বয়ংক্রিয়ভাবে উত্পাদিত মার্জ এবং রিবেস প্রতিশ্রুতি বার্তা হ'ল আবশ্যক এবং বর্তমান কাল ("মার্জ", "মার্জ" নয়; "রিবেস", "রিবেসড" নয়), সুতরাং আপনি সামঞ্জস্যতার জন্য নিজের প্রতিশ্রুতি বার্তাগুলিতে এটি মিলিয়ে দেখতে চাইতে পারেন।
এমজেএস

13
মনে হচ্ছে পার্থক্যটি সফ্টওয়্যারটির পরিবর্তনের উপর দৃষ্টি নিবদ্ধ করা - "ওয়াই করে ফিক্সড এক্স" - বা সংগ্রহশালা - "এক্স এক্স ঠিক করার জন্য ড।" একটি ভাল যুক্তির জন্য +1, তবে আমি মনে করি ফলাফলগুলি সাধারণত সফটওয়্যারটির চেয়ে রেপোকে নিজের দিকে ফোকাস করে।
l0b0

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

35
জরুরী "গিট থেকে নতুন" নয়। চেঞ্জলগ গিটের অনেক আগে থেকেই ছিল এবং জিএনইউ প্রকল্পে আবশ্যকীয় ব্যবহার সর্বদা প্রস্তাবিত স্টাইল। gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
ADL

81

আমি 365git এ পূর্ণ বিবরণ লিখেছি

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

Renamed the iVars and removed the common prefix.

এটির মতো একটি রাখুন:

Rename the iVars to remove the common prefix

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

এগুলি সব বলেছিলেন - এটি আপনার কোড, আপনার সংগ্রহশালা: তাই আপনার নিজের নির্দেশিকা সেট আপ করুন এবং সেগুলিকে আটকে দিন।

তবে, আপনি যদি এই পথে যাওয়ার সিদ্ধান্ত নেন তবে পুনরায় শব্দ git rebase -iবিকল্পের সাথে সন্ধান করা ভাল জিনিস।


7
ভাল, আপনি দুটি পৃথক নির্দেশিকা মিশ্রিত করেছেন: গিট ওপেন সোর্স প্রকল্প এবং গিটের নিয়মিত ব্যবহার usage প্রদত্ত লিঙ্কটি মোটেই উত্তেজনার কথা উল্লেখ করে না । অফিসিয়াল গিট ডকটি কেবল 50 চর সীমা উল্লেখ করে। গিট একটি বিতরণ করা ভিসিএস যেখানে পরিবর্তনের জন্য অনেক জায়গা রয়েছে ... এই বার্তাগুলি কমিট প্রয়োগের জন্য নির্দেশাবলী হিসাবে বিবেচনা করুন। এটি কেবলমাত্র কয়েকটি প্রকল্পের ক্ষেত্রে প্রযোজ্য যা আসলে বিতরণ করা প্রকল্প। 99.999% গিট কমিট ম্যানুয়ালি এ জাতীয়ভাবে প্রয়োগ করা হবে না। বেশিরভাগ প্রকল্পে, ইতিহাস একটি পরিবর্তন লগ, যা অতীত কাল হওয়া উচিত।
ম্যাট কুইগলি

4
"এবং পুরো স্টপ এড়িয়ে যাওয়া উচিত"
তাকেশিন

30

বর্তমান কাল অত্যাবশ্যক সঙ্গে স্টিক কারণ

  • এটি একটি মান আছে ভাল
  • এটি বাগ ট্র্যাকারের টিকিটের সাথে মেলে যা প্রাকৃতিকভাবে "কিছু প্রয়োগ করে", "কিছু ঠিক করুন", বা "কোনও কিছুর পরীক্ষা" ফর্ম রয়েছে।

16

আপনি কার জন্য বার্তা লিখছেন? এবং যে পাঠক সাধারণত বার্তাটি পড়েন প্রাক-বা মালিকানার পরে তাদের প্রতিশ্রুতিবদ্ধ হয়?

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

অর্থ সংক্ষেপে:

  • এই বার্তাটি কি অন্য ব্যক্তির পক্ষে মূলত পরিবর্তনটি গ্রহণ করার আগে কিছু সময় পড়তে হয়: পরিবর্তন কী গ্রহণ করবে তা একটি প্রস্তাব তাদের বিদ্যমান কোডে কি করবে?

  • বার্তাটি মূলত নিজের কাছে (বা আপনার দলের কাছে) একটি জার্নাল / রেকর্ড হিসাবে রয়েছে তবে সাধারণত পরিবর্তনটি ধরে নিয়ে কী ঘটেছিল তা আবিষ্কার করার জন্য সাধারণত অনুসন্ধানটি গ্রহণ করার দৃষ্টিকোণ থেকে পড়া।

সম্ভবত এটি আপনার দল / প্রকল্পের জন্য যে কোনও উপায়ে প্রেরণা জাগ্রত করবে।


10

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


27
করার কিছু লোক , যে বিষয়টি বেশ একটু ভালো জিনিস।
ওয়েসলি মার্চ

2
@ লিঙ্কটি মোগ করুন বর্তমান এবং অতীত সম্পর্কে কোনও বক্তব্য দেয় না।
সিভ করা

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

আমি বলছি না একটি ভাল প্রতিশ্রুতি বার্তা লিখবেন না। আমি বলছি আপনি অতীত বা বর্তমান কাল ব্যবহার করেন কিনা তা বিবেচ্য নয়।
মাইকেল বাল্ড্রি

1
আপনি কীভাবে জানবেন যে ব্যক্তি আপনার প্রতিশ্রুতি বার্তাটি ব্যাখ্যা করতে সক্ষম হচ্ছে না, সে সেই ব্যক্তির পক্ষে যথেষ্ট সক্ষম নয়, বা আপনি একটি ভাল প্রতিশ্রুতি বার্তা লেখার পক্ষে যথেষ্ট সক্ষম নন?
হারিস

7

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

এবং যদি আপনি একটি দলে বিকাশ করেন - তবে এটি আলোচনা করা উচিত এবং সেট করা ঠিক করা উচিত।

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