উত্তর:
সংস্করণ নিয়ন্ত্রণ সরঞ্জামগুলি ব্যক্তিটিকে কী ফাইলগুলি সংশোধন করা হয়েছে এবং কোন পদ্ধতিগুলি যুক্ত করা হয়েছিল তা দেখার জন্য যথেষ্ট শক্তিশালী। এর অর্থ হ'ল সাধারণভাবে, লগ বার্তাগুলি যা ইতিমধ্যে বিদ্যমান তা স্পষ্টভাবে সদৃশ করে লগটিকে দূষিত করছে।
আপনি somefuncএকটি প্রয়োজনীয়তা পূরণের জন্য পদ্ধতি যুক্ত করেছেন , অর্থাত:
এর অর্থ হ'ল আপনার লগ বার্তাগুলিতে অবশ্যই বৈশিষ্ট্যগুলি / বাগগুলি প্রভাবিত হয়েছিল বা রিফ্যাক্টরিংয়ের উদ্দেশ্য কী ছিল তা ব্যাখ্যা করতে হবে।
টিকিট / ইস্যু সংখ্যা যুক্ত করতে ভুলবেন না ।
আপনার যদি টিকিট # বা ইস্যু # সহ কোনও বৈশিষ্ট্য বা ইস্যু ট্র্যাকিং সিস্টেম থাকে তবে সেই আইডি # কমিটের মধ্যে অবশ্যই রাখবেন। এটি আপনাকে যে বৈশিষ্ট্য বা সমস্যা নিয়ে কাজ করছে সে সম্পর্কে আরও জানতে চাইলে যে কেউ সহায়তা করবে।
আমার শেষ প্রজেক্টে, একটি ম্যাক্রো ছিল যা মন্তব্যটির প্রথম 7 টি সংখ্যা পরিষ্কার অনুসন্ধান (আমাদের ইস্যু / বৈশিষ্ট্য ট্র্যাকিং সিস্টেম) থেকে একটি বৈধ ইস্যু নম্বর ছিল তা নিশ্চিত করার জন্য তৈরি করা হয়েছিল।
আমি প্রতিশ্রুতিবদ্ধ যখন আমি এই ধরনের জিনিস যেমন একাধিক ফাইলের পরিবর্তন প্রয়োজন যে একটি ত্রুটির জন্য ঠিক করা। এটি চেঞ্জসেটে পৃথক ফাইলগুলি না দেখে আসলে কী বদলেছে তা বলা কিছুটা সহজ করে তোলে।
একক ফাইল চেঞ্জসেটের জন্য, এটি অপ্রয়োজনীয়।
প্রথম লাইনটি সর্বদা ত্রুটি বা ব্যবহারকারী গল্পের লিঙ্কের মতো চেঞ্জসেটের একটি উচ্চ-স্তরের বর্ণনা।
যদি এটি প্রতিশ্রুতি বার্তার বর্ণনায় প্রাসঙ্গিক তথ্য হয় তবে হ্যাঁ, এটি অন্তর্ভুক্ত করুন। যদি তথ্যটির একমাত্র বিট ফাইলের নাম নিজেই হয়, তবে না।
উদাহরণস্বরূপ এটি বোধগম্য করুন: "বিল্ড_ফু () ফাংশনটি fooutil.c থেকে foobase.c এ সরানো হয়েছে, যেহেতু বিল্ড_ফু () ব্যবহার করতে চান এমন বেশিরভাগ প্রোগ্রাম ইতিমধ্যে foobase.c সহ অন্তর্ভুক্ত রয়েছে"
এটির কোনওটি নয়: "বার পরামিতি নিতে fooutil.c এ বিল্ড_ফু () আপডেট হয়েছে।"
আমি এখানে একটি ভিন্ন দৃষ্টিভঙ্গি যুক্ত করতে চাই।
আমার উত্তর হ্যাঁ বা না, তবে সাধারণত আমি হ্যাঁ বলি।
সংস্করণ নিয়ন্ত্রণ প্রকৃতপক্ষে যথেষ্ট পরিমাণে জানার জন্য কোন ফাইলটি আপডেট হচ্ছে। কিন্তু, আমরা যখন করি
$ git log
আমরা কেবল প্রতিশ্রুতি বার্তা দেখতে পাই। বেশিরভাগ মানুষ যা করেন।
লগতে নিজেই তাকিয়ে। এটি এতে অতিরিক্ত প্রসঙ্গ যুক্ত করে। উদাহরণ স্বরূপ:
readme.md: Fix typo detected by language tool
বেশী ভালো
Fix typo detected by language tool
যাইহোক, যদি পরিবর্তনগুলি একাধিক ফাইলের স্প্যান করে, তবে কমপক্ষে সম্পাদনা হচ্ছে এমন উপাদানটি উল্লেখ করুন।
API: Fix reset password not sent email to user
এটি পড়ে, আমরা জানি যে ত্রুটিটি সংশোধন করা হচ্ছে এটি API উপাদানটিতে রয়েছে এবং এটি সম্ভবত কোড বেসে API ডিরেক্টরিতে রয়েছে under
আমরা যাইহোক করতে পারে
$ git show COMMIT_ID --name-only
তবে এটি কেবল ফাইলগুলি পেতে আরও পদক্ষেপ যুক্ত করে।
একমাত্র ফাইলের চেকইনের জন্য আমি কেবল এটিই কার্যকর হতে দেখতে পেলাম যদি আপনি ফাইলের মধ্যে অনেক জায়গায় ব্যবহৃত একটি ফাংশনে পরিবর্তন করে থাকেন যে ফলাফলটি বিশৃঙ্খলাবদ্ধ হয়। তারপরেও আমি পরিবর্তন ট্র্যাকারটিকে # এবং পরিবর্তনের প্রথমে একটি স্পষ্ট পাঠ্য বিবরণ রেখেছি।
আমি মনে করি এখানে আসল প্রশ্নটি আপনার কমিটগুলি কতটা সীমাবদ্ধ? যদি আপনি একটি প্রতিশ্রুতিবদ্ধভাবে একসাথে বিভিন্ন সম্পর্কযুক্ত পরিবর্তন করার অপেক্ষায় থাকেন তবে কী উদ্দেশ্যে কোন ফাইলগুলি পরিবর্তন করা হয়েছিল তা নির্দিষ্ট করে দেওয়ার প্রয়োজন বোধ করতে পারেন।
তবে, আপনি যদি আরও ঘন ঘন আরও সংকীর্ণ প্রতিশ্রুতিবদ্ধ হন, তবে একটি একক প্রতিশ্রুতি দ্বারা ব্যাখ্যা করা হবে যে কোন ফাইলগুলি সংশোধন করা হয়েছে এবং আপনি বার্তায় কী কী উদ্দেশ্যটি বর্ণনা করেছিলেন তা কেবল বর্ণনা করতে পারেন।
আরও কমিট, আরও প্রায়শই। আপনি নিজের বার্তাগুলিতে এত ভার্বোজ হওয়া এড়াতে পারেন।