গিট কমিট বার্তা: 50/72 ফর্ম্যাটিং

310

টিম পোপ তার ব্লগ পোস্টে একটি বিশেষ গিট কমিট বার্তা শৈলীর পক্ষে যুক্তি দেখিয়েছেন: http://www.tpope.net/node/106 ।

এখানে তিনি কী প্রস্তাব দেন তার একটি দ্রুত সংক্ষিপ্তসার এখানে:

প্রথম লাইনটি 50 টিরও কম অক্ষর।
তারপরে একটি ফাঁকা লাইন।
অবশিষ্ট পাঠ্যটি 72২ টি অক্ষরে মোড়ানো উচিত।

তাঁর ব্লগ পোস্টটি এই সুপারিশগুলির যৌক্তিকতা দেয় (যা আমি বংশবৃদ্ধির জন্য "50/72 ফর্ম্যাটিং" বলব):

অনুশীলনে, কিছু সরঞ্জাম প্রথম লাইনটিকে সাবজেক্ট লাইন হিসাবে এবং দ্বিতীয় অনুচ্ছেদে দেহ হিসাবে বিবেচনা করে (ইমেলের অনুরূপ)।
git log মোড়ানো পরিচালনা করে না, সুতরাং লাইনগুলি দীর্ঘ হলে এটি পড়া শক্ত।
git format-patch --stdout প্রতিশ্রুতিগুলিকে ইমেলের রূপান্তর করে - তাই আপনার খেলার কমিটগুলি ইতিমধ্যে সুন্দরভাবে মোড়ানো থাকলে এটি ভাল খেলতে সহায়তা করে।

আমি একটি বিষয় যোগ করতে চাই যে আমি মনে করি টিম এর সাথে একমত হবে:

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

সুতরাং, আমার কাছে আমার প্রশ্নের বেশ কয়েকটি কোণ রয়েছে:

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

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

git

— ডেভিড জে।
সূত্র

11

আমি কেবল লক্ষ্য করেছি যে "প্রোটিপ: গ্রেট কমিটের সংক্ষিপ্তসারগুলি 50 টি অক্ষর বা তার চেয়ে কম।" বর্ধিত বিবরণে অতিরিক্ত তথ্য রাখুন বলে গিথুবের ওয়েব ইন্টারফেস আপনাকে সতর্ক করবে if

— ডেভিড জে।

275

"সারাংশ" লাইনটি (আপনার সূত্রের 50) সম্পর্কিত, লিনাক্স কার্নেল ডকুমেন্টেশনের এই কথাটি রয়েছে :

For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary.  It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.

এটি বলেছিল, দেখে মনে হচ্ছে কার্নেল রক্ষণাবেক্ষণকারীরা 50 টি জিনিসকে প্রায় রাখার চেষ্টা করেন Here এখানে কার্নেলের জন্য গিট লগে সংক্ষিপ্ত রেখাগুলির দৈর্ঘ্যের একটি হিস্টোগ্রাম রয়েছে:

( পূর্ণ আকার দেখুন )

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

আপনি যদি কাঁচা দৈর্ঘ্য দেখতে চান:

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{print length($0)}'

বা একটি পাঠ্য-ভিত্তিক হিস্টোগ্রাম:

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{lens[length($0)]++;} END {for (len in lens) print len, lens[len] }' | sort -n

— mgalgs
সূত্র

17

কৌতূহলের বাইরে আপনি কীভাবে আপনার হিস্টোগ্রাম তৈরি করেছিলেন?

— নৈরাজ্যবাদী

37

অজগর মধ্যে matplotlib । ভালো কিছু এই কিন্তু পরিবর্তে র্যান্ডম তথ্য আমার উত্তর কমান্ড এক থেকে আউটপুট।

— mgalgs

2

GNU AWK ব্যবহার:git shortlog | awk '/^ / {gensub(/[[:space:]]\+$.*$$/, "\\1", ""); print length()}'

— পরবর্তী বিজ্ঞপ্তি না দেওয়া পর্যন্ত

তাহলে কি 50 টি কেবল ব্রেভিটি উত্সাহিত করার জন্য একটি স্বেচ্ছাসেবক গাইড কিন্তু গিট আউটপুট ফিট করার জন্য প্রযুক্তিগত বিবেচনার জন্য 72 বিধি একটি নিয়ম?

— TafT

4

গিথুব 70 তম চরিত্রের পরে প্রতিশ্রুত বার্তা পাঠাতে হবে।

— পিটার কোক

63

"চিন্তিত নেতাদের" সম্পর্কে: লিনাস দৃ commit়ভাবে পূর্ণ প্রতিশ্রুতি বার্তার জন্য লাইন মোড়কের পক্ষে:

[…] আমরা শব্দ-মোড়কের জন্য -২-চরিত্রের কলামগুলি ব্যবহার করি, নির্দিষ্ট রেখার বিন্যাসে উদ্ধৃত উপাদান বাদে।

ব্যতিক্রমগুলি মূলত "অ-গদ্য" পাঠ্যকে বোঝায়, এটি এমন পাঠ্য যা কোনও প্রতিশ্রুতিবদ্ধতার জন্য কোনও টাইপ করেনি - উদাহরণস্বরূপ, সংকলক ত্রুটি বার্তা।

— leonbloy
সূত্র

17

"গদ্য" এবং "অ-গদ্য" এর মধ্যে পার্থক্য আনার জন্য +1। এবং "একটি নির্দিষ্ট রেখার ফর্ম্যাট রয়েছে এমন উদ্ধৃত উপাদান ব্যতীত"। থাম্বের দুর্দান্ত নিয়ম।

— অ্যালোস মাহডাল

38

উপস্থাপনা এবং ডেটা পৃথক করা আমার প্রতিশ্রুতি বার্তাগুলি এখানে চালিত করে।

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

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

বার্তার জন্য নিজেই নিউলাইনগুলি ডেটাতে অর্থপূর্ণ কিছু নির্দেশ করে। একটি একক নিউলাইন একটি তালিকার শুরু / বিরতি এবং একটি ডাবল নিউলাইন একটি নতুন চিন্তা / ধারণা নির্দেশ করে।

This is a summary line, try to keep it short and end with a line break.
This is a thought, perhaps an explanation of what I have done in human readable format.  It may be complex and long consisting of several sentences that describe my work in essay format.  It is not up to me to decide now (at author time) how the user is going to consume this data.

Two line breaks separate these two thoughts.  The user may be reading this on a phone or a wide screen monitor.  Have you ever tried to read 72 character wrapped text on a device that only displays 60 characters across?  It is a truly painful experience.  Also, the opening sentence of this paragraph (assuming essay style format) should be an intro into the paragraph so if a tool chooses it may want to not auto-wrap and let you just see the start of each paragraph.  Again, it is up to the presentation tool not me (a random author at some point in history) to try to force my particular formatting down everyone else's throat.

Just as an example, here is a list of points:
* Point 1.
* Point 2.
* Point 3.

দর্শকের মতো দেখতে দেখতে এটি দেখতে এখানে টেক্সটটি নরম করে দেয়।

এটি একটি সারসংক্ষেপ রেখা, এটি সংক্ষিপ্ত রাখার চেষ্টা করুন এবং লাইন বিরতি দিয়ে শেষ করুন।

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

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

উদাহরণ হিসাবে, এখানে পয়েন্টগুলির একটি তালিকা রয়েছে:
* পয়েন্ট 1.
* পয়েন্ট 2.
* পয়েন্ট 3 3

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

— মিকাহ জোল্টু
সূত্র

51

বাহ, সেই প্রতিশ্রুতি বার্তাটি এসও এর মতো কোনও ওয়েবপৃষ্ঠায় পড়তেও বেদনাদায়ক। আমার কাছে প্রতিক্রিয়াশীল কমিট বার্তা প্রয়োজন নেই , তবে এমন কিছু যা ভালভাবে কাজ করে tig, git logবা gitk, এবং গিথুবও হতে পারে।

— বেনজামিন ব্যানিয়ার

28

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

— মিকাহ জোল্টু

16

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

— ডেভিড জে

16

চরিত্রের ক্রমটি \n\nএকটি চিন্তার বিভাজক। \n* একটি তালিকা আইটেম সূচক। এগুলি কীভাবে রেন্ডার করা হয় তা দেখার বিষয়। কৃত্রিম লাইন বিরতিতে সমস্যাটি হ'ল তারা উপস্থাপনা ব্যতীত অন্য কোনও কিছুর সাথে যুক্ত নয় । 70 টি অক্ষরে লাইন ব্রেক রেখে কোনও ডেটা-সম্পর্কিত তথ্য প্রেরণ করা হচ্ছে না। আমার পছন্দ \n\nএবং \n* মার্কডাউন কেন এটিকে বেছে নিয়েছে তার সমান, কারণ এটি এমন একটি এনকোডিং ডেটা যা কোনও সরল পাঠ্য দৃষ্টিতে কিছুটা যুক্তিসঙ্গত মনে হয়।

— মাইকা জোল্টু

14

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

— মাইকা জোল্টু

5

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

লিনাক্স কার্নেল কমিটিগুলি একবার দেখুন, আপনার পছন্দ মতো প্রকল্পটি গিট শুরু করেছে, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git ;a=commit ; h = bca476139d2ded86be146dae09b06e22548b67f3 , তারা 50/72 বিধি অনুসরণ করে না। প্রথম লাইনটি 54 টি অক্ষর।

আমি ধারাবাহিকতার বিষয়টি বলব। কমিটস (ইউজার নাম, ইউজারআল ইমেইল - বিশেষত অভ্যন্তরীণ নেটওয়ার্কগুলিতে) ব্যবহারকারীদের সনাক্ত করার উপযুক্ত উপায় সেট আপ করুন User ব্যবহারকারী @ OFFICE-1-PC-10293982811111 একটি দরকারী যোগাযোগের ঠিকানা নয়)। প্রকল্পের উপর নির্ভর করে কমিটে উপযুক্ত বিশদটি সরবরাহ করুন। কী হওয়া উচিত তা বলা শক্ত; এটি কোনও উন্নয়ন প্রক্রিয়াতে সম্পন্ন কাজগুলি হতে পারে, তারপরে কী পরিবর্তন হয়েছে তার বিশদ।

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

কমিটগুলি সন্ধান করার অন্যান্য উপায় রয়েছে তাও আমার নোট করা উচিত। শুরু করার জন্য, git diffআপনাকে কী বলা হয়েছে তা বলবে। আপনি git log --pretty=format:'%T %cN %ce'বিকল্পগুলির ফর্ম্যাট করতে পছন্দ মতো কাজও করতে পারেন git log।

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

— ওমনি

3

সর্বাধিক প্রস্তাবিত শিরোনাম দৈর্ঘ্য 50?

আমি বছরের পর বছর ধরে এটি বিশ্বাস করেছিলাম, তবে আমি যেমন "গিট কমিট" এর ডকুমেন্টেশনটি লক্ষ্য করেছি তা আসলে উল্লেখ করেছে

$ git help commit | grep -C 1 50
      Though not required, it’s a good idea to begin the commit message with
      a single short (less than 50 character) line summarizing the change,
      followed by a blank line and then a more thorough description. The text

$  git version
git version 2.11.0

যে কেউ তর্ক করতে পারে যে "50 এর কম হলে 50" অর্থ কেবল "49 এর বেশি নয়" হতে পারে।

— গেন্টার ব্রুনথেলার
সূত্র

3

অন্যদিকে, ডিফল্ট হাইলাইটিং প্রথম 50 টি অক্ষর হাইলাইট করে। এটি একটি অনিচ্ছাকৃত তাত্পর্য বলে মনে হয়।

— আগস্ট জানসে