Git प्रतिबद्ध संदेश: 50/72 स्वरूपण

Question

टिम पोप अपने ब्लॉग पोस्ट में एक विशेष Git प्रतिबद्ध संदेश शैली के लिए तर्क देते हैं: http://www.tpope.net/node/106 ।

यहाँ एक त्वरित सारांश है कि वह क्या सुझाता है:

• पहली पंक्ति 50 अक्षर या उससे कम की है।
• फिर एक खाली लाइन।
• शेष पाठ को 72 वर्णों पर लपेटा जाना चाहिए।

उनका ब्लॉग पोस्ट इन सिफारिशों के लिए तर्क देता है (जिसे मैं संक्षिप्तता के लिए "50/72 प्रारूपण" कहूंगा):

• व्यवहार में, कुछ उपकरण एक विषय के रूप में पहली पंक्ति और दूसरे पैराग्राफ को एक निकाय के रूप में मानते हैं (ईमेल के समान)।
• git log रैपिंग को हैंडल नहीं करता है, इसलिए यह पढ़ना मुश्किल है कि क्या लाइनें बहुत लंबी हैं।
• git format-patch --stdout धर्मान्तरित ईमेल करने के लिए करता है - तो अच्छा खेलने के लिए अगर आपके commits पहले से ही अच्छी तरह से लिपटे हैं मदद करता है।

एक बिंदु मैं यह जोड़ना चाहूंगा कि मुझे लगता है कि टिम इससे सहमत होंगे:

• आपकी प्रतिबद्धता को संक्षेप में प्रस्तुत करने का कार्य किसी भी संस्करण नियंत्रण प्रणाली में स्वाभाविक रूप से एक अच्छा अभ्यास है। यह दूसरों को (या बाद में आपको) प्रासंगिक कमिट को अधिक तेज़ी से खोजने में मदद करता है।

इसलिए, मेरे पास मेरे प्रश्न के लिए कुछ कोण हैं:

• क्या "विचारशील नेताओं" या "अनुभवी उपयोगकर्ताओं" के गंक ने 50/72 प्रारूपण शैली को अपनाया है? मैं यह पूछता हूं क्योंकि कुछ नए उपयोगकर्ता सामुदायिक प्रथाओं के बारे में नहीं जानते या परवाह नहीं करते हैं।
• उन लोगों के लिए जो इस प्रारूपण का उपयोग नहीं करते हैं, क्या एक अलग स्वरूपण शैली का उपयोग करने का एक राजसी कारण है? (कृपया ध्यान दें कि मैं योग्यता पर एक तर्क की तलाश कर रहा हूं, न कि "मैंने इसके बारे में कभी नहीं सुना है" या "मैं ऐसा नहीं करता हूं।"
• अनुभवजन्य रूप से, कितने प्रतिशत Git रिपॉजिटरी इस शैली को गले लगाते हैं? (यदि कोई GitHub रिपॉजिटरी… हिंट, हिंट पर विश्लेषण करना चाहता है।)

यहाँ मेरी बात 50/72 शैली की सिफारिश करने या अन्य शैलियों को शूट करने की नहीं है। (इसके बारे में खुले रहने के लिए, मैं इसे पसंद करता हूं, लेकिन मैं अन्य विचारों के लिए खुला हूं।) मैं सिर्फ इसके लिए तर्क प्राप्त करना चाहता हूं कि लोग विभिन्न Git प्रतिबद्ध संदेश शैलियों को पसंद या विरोध क्यों करते हैं। (उन बिंदुओं को सामने लाने के लिए स्वतंत्र महसूस करें, जिनका उल्लेख नहीं किया गया है।)

Comments

मैंने अभी देखा कि गितुब का वेब इंटरफ़ेस आपको चेतावनी देगा कि क्या आपकी पहली पंक्ति "ProTip: Great प्रतिबद्ध सारांश 50 वर्ण या उससे कम है" कहकर विस्तृत वर्णनों में अतिरिक्त जानकारी रखें।

— डेविड जे।

Answer 1

"सारांश" लाइन (आपके सूत्र में 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 के आसपास चीजों को रखने की कोशिश करते हैं। यहां कर्नेल के लिए गिट लॉग में सारांश लाइनों की लंबाई का एक हिस्टोग्राम है:

( पूर्ण आकार देखें )

ऐसे कमानों की एक चापलूसी है जिसमें सारांश रेखाएं हैं जो इस भूखंड की तुलना में लंबी (कुछ अधिक लंबी) हैं जो एक एकल रेखा की तरह दिलचस्प भाग को बनाए बिना पकड़ सकती हैं। (यहाँ उस डेटा को शामिल करने के लिए कुछ फैंसी सांख्यिकीय तकनीक है लेकिन ओह अच्छी तरह से ... :-)

यदि आप कच्ची लंबाई देखना चाहते हैं:

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

Comments

जिज्ञासा से बाहर निकलकर आपने अपना हिस्टोग्राम कैसे उत्पन्न किया?

— अराजकतावादी

अजगर में matplotlib की तरह कुछ इस लेकिन बजाय यादृच्छिक डेटा मेरा उत्तर में से कोई एक आदेश से उत्पादन के साथ।

— मंगल

GNU AWK का उपयोग करना:git shortlog | awk '/^ / {gensub(/[[:space:]]\+\(.*\)$/, "\\1", ""); print length()}'

— अगली सूचना तक

तो क्या संक्षिप्तता को प्रोत्साहित करने के लिए ५० सिर्फ एक मनमाना मार्गदर्शक है, लेकिन a२ एक नियम है जो उत्पादन के साथ फिटिंग के लिए तकनीकी विचार को पूरा करता है?

— TafT

गितुब 70 वें चरित्र के बाद प्रतिबद्ध संदेश पाठ छिपा देगा।

— पेटर कोक

Answer 2

"विचारशील नेताओं" के बारे में: लाइनस सशक्त रूप से अधिवक्ताओं को पूर्ण वचन संदेश के लिए लपेटते हैं:

[...] हम वर्ड-रैपिंग के लिए 72-वर्ण कॉलम का उपयोग करते हैं, उद्धृत सामग्री को छोड़कर, जिसमें एक विशिष्ट लाइन प्रारूप होता है।

अपवाद मुख्य रूप से "गैर-गद्य" पाठ को संदर्भित करता है, अर्थात्, वह पाठ जो प्रतिबद्ध के लिए मानव द्वारा टाइप नहीं किया गया था - उदाहरण के लिए, संकलक त्रुटि संदेश।

Comments

"गद्य" और "गैर-गद्य" के बीच अंतर लाने के लिए +1। और "उद्धृत सामग्री को छोड़कर, जिसमें एक विशिष्ट रेखा प्रारूप है"। अंगूठे का उत्कृष्ट नियम।

— ऐलिस महालड

Answer 3

प्रस्तुति और डेटा का पृथक्करण मेरे प्रतिबद्ध संदेशों को यहाँ चलाता है।

आपके कमिट मैसेज को किसी भी कैरेक्टर काउंट पर हार्ड-रैप नहीं किया जाना चाहिए और इसके बजाय लाइन ब्रेक का इस्तेमाल डेटा के हिस्से के रूप में विचारों, पैराग्राफ आदि को अलग करने के लिए किया जाना चाहिए, न कि प्रेजेंटेशन के तौर पर। इस मामले में, "डेटा" वह संदेश है जिसे आप पार करने की कोशिश कर रहे हैं और "प्रस्तुति" है कि उपयोगकर्ता कैसे देखता है।

मैं शीर्ष पर एकल सारांश लाइन का उपयोग करता हूं और मैं इसे छोटा रखने की कोशिश करता हूं लेकिन मैं खुद को एक मनमानी संख्या तक सीमित नहीं करता हूं। यह बेहतर होगा यदि Git ने वास्तव में संदेश से अलग इकाई के रूप में सारांश संदेशों को संग्रहीत करने का एक तरीका प्रदान किया है, लेकिन चूंकि इसमें मुझे एक को हैक करने की आवश्यकता नहीं है और मैं सीमांकक के रूप में पहली लाइन ब्रेक का उपयोग करता हूं (सौभाग्य से, कई उपकरण समर्थन करते हैं इसका मतलब है कि डेटा को अलग करना)।

मैसेज के लिए खुद न्यूलाइन्स डेटा में कुछ सार्थक संकेत देते हैं। एक सिंगल न्यूलाइन एक सूची में एक शुरुआत / ब्रेक को इंगित करता है और एक डबल न्यूलाइन एक नए विचार / विचार को इंगित करता है।

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.

यहां एक दर्शक में ऐसा दिखता है कि पाठ को नरम लपेटता है।

यह एक सारांश रेखा है, इसे छोटा रखने की कोशिश करें और एक पंक्ति विराम के साथ समाप्त करें।

यह एक विचार है, शायद मैंने मानव पठनीय प्रारूप में क्या किया है, इसका स्पष्टीकरण। यह कई वाक्यों से जटिल और लंबा हो सकता है जो निबंध प्रारूप में मेरे काम का वर्णन करते हैं। यह तय करना मेरे लिए नहीं है कि (लेखक के समय पर) उपयोगकर्ता इस डेटा का उपभोग कैसे करने जा रहा है।

दो रेखाएं इन दो विचारों को अलग करती हैं। उपयोगकर्ता इसे एक फोन या एक विस्तृत स्क्रीन मॉनिटर पर पढ़ सकता है। क्या आपने कभी एक उपकरण पर 72 वर्ण लिपटे पाठ को पढ़ने की कोशिश की है जो केवल 60 वर्णों को प्रदर्शित करता है? यह वास्तव में दर्दनाक अनुभव है। इसके अलावा, इस पैराग्राफ का प्रारंभिक वाक्य (निबंध शैली प्रारूप मानकर) पैराग्राफ में एक परिचय होना चाहिए, ताकि यदि कोई उपकरण चुनता है तो वह ऑटो-रैप नहीं करना चाहे और आपको प्रत्येक पैराग्राफ की शुरुआत देखने दे। फिर, यह प्रस्तुति उपकरण पर निर्भर करता है कि मैं नहीं (इतिहास के किसी बिंदु पर एक यादृच्छिक लेखक) अपने विशेष स्वरूप को हर किसी के गले में उतारने की कोशिश करने के लिए।

एक उदाहरण के रूप में, यहां बिंदुओं की एक सूची है:
* प्वाइंट 1.
* प्वाइंट 2.
* प्वाइंट 3।

मेरा संदेह यह है कि आपके द्वारा लिंक किए गए Git प्रतिबद्ध संदेश अनुशंसा के लेखक ने कभी ऐसा सॉफ़्टवेयर नहीं लिखा है जो सॉफ़्टवेयर / कंप्यूटिंग के विकास में इस बिंदु से पहले (यानी, एक वेबसाइट) पर विभिन्न उपकरणों पर अंत-उपयोगकर्ताओं की एक विस्तृत सरणी द्वारा उपभोग किया जाएगा। यह अच्छी तरह से ज्ञात है कि हार्ड-कोडित प्रस्तुति जानकारी के साथ अपने डेटा को संग्रहीत करना एक बुरा विचार है जहां तक ​​उपयोगकर्ता अनुभव जाता है।

Comments

वाह, यह प्रतिबद्ध संदेश एसओ जैसे वेबपेज पर भी पढ़ने के लिए दर्दनाक है। मुझे उत्तरदायी प्रतिबद्ध संदेशों की आवश्यकता नहीं है , लेकिन ऐसा कुछ जो अच्छी तरह से काम करता है tig, git logया gitkशायद जीथब भी।

— बेंजामिन बैनिएर

यह संदेश किसी भी दर्शक के साथ पढ़ना आसान होगा, जो शब्द लपेटता है। मैंने इसे एक गैर-रैपिंग कोड ब्लॉक में एक उदाहरण के रूप में रखा।

— मीका ज़ोल्टू

एक अलग दृष्टिकोण के लिए धन्यवाद। सिद्धांत रूप में, आपका उत्तर ठीक लगता है। व्यवहार में, मुझे वर्तमान कमांड लाइन टूल के लिए लाइन ब्रेक पसंद है।

— डेविड जे।

चरित्र अनुक्रम \n\nएक विचारक विभाजक है। \n* एक सूची आइटम संकेतक है। उन का प्रतिपादन कैसे किया जाता है यह देखने तक है। कृत्रिम रेखा टूटने के साथ समस्या यह है कि वे प्रस्तुति के अलावा कुछ भी नहीं के साथ जुड़े हुए हैं । 70 वर्णों पर एक पंक्ति विराम लगाकर कोई डेटा-संबंधित जानकारी प्रेषित नहीं की जा रही है। मेरी पसंद \n\nऔर \n* क्योंकि यह डेटा है कि यह भी एक सादा पाठ दृश्य में कुछ हद तक उचित देखने के लिए होता है एन्कोडिंग का एक रूप है, के रूप में क्यों Markdown यह चुना है एक ही है।

— मीका झोलटु

छोटे स्क्रीन (मोबाइल) वाले उपकरणों पर हार्ड रैप को पढ़ना मुश्किल है। संदेश को पढ़ने में मुश्किल होगी, चाहे आप कुछ भी करें। मैं इसके बजाय विरासत के सॉफ्टवेयर को पूरा करने की तुलना में आधुनिक सर्वोत्तम प्रथाओं का पालन करूंगा जिसमें कुछ सबसे बुनियादी प्रतिपादन क्षमताएं नहीं हैं।

— मीका झोलटु

Answer 4

मैं सहमत हूँ कि काम करने की एक विशेष शैली का प्रस्ताव करना दिलचस्प है। हालांकि, जब तक मुझे स्टाइल सेट करने का मौका नहीं मिलता है, मैं आमतौर पर निरंतरता के लिए क्या किया जाता है का पालन करता हूं।

लिनक्स कर्नेल कमिट्स पर एक नज़र डालते हुए, यदि आपको पसंद है, तो यह परियोजना शुरू हो गई है, जैसे कि http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git=a=commit; = bca476139d2ded86be146dae09b06e22548b67f3 , वे 50/72 नियम का पालन नहीं करते हैं। पहली पंक्ति 54 वर्णों की है।

मैं कहूंगा कि स्थिरता मायने रखती है। उन उपयोगकर्ताओं की पहचान करने का उचित साधन सेट करें जिन्होंने कमिट (user.name, user.email - विशेष रूप से आंतरिक नेटवर्क पर। उपयोगकर्ता @ OFFICE-1-PC-10293982811111 एक उपयोगी संपर्क पता नहीं है)। प्रोजेक्ट के आधार पर, कमिटमेंट में उपयुक्त विवरण उपलब्ध कराएं। यह कहना मुश्किल है कि क्या होना चाहिए; यह एक विकास प्रक्रिया में पूर्ण होने वाले कार्य हो सकते हैं, फिर जो कुछ बदला है उसका विवरण।

मुझे विश्वास नहीं है कि उपयोगकर्ताओं को एक तरह से गिट का उपयोग करना चाहिए क्योंकि कुछ इंटरफेस के लिए कुछ निश्चित तरीकों से व्यवहार करना चाहिए।

मुझे यह भी ध्यान रखना चाहिए कि आवागमन खोजने के अन्य तरीके हैं। एक शुरुआत के लिए, git diffआपको बताएगा कि क्या बदल गया है। आप git log --pretty=format:'%T %cN %ce'विकल्पों को प्रारूपित करना भी पसंद कर सकते हैं git log।

Comments

संदर्भ के लिए वह कहते हैं "जैसा कि उदाहरण से संकेत मिलता है, आपको लगभग 50 वर्णों के लिए शूट करना चाहिए (हालांकि यह एक कठिन अधिकतम नहीं है"), लेकिन मुझे लगता है कि आपके पास एक बिंदु है जिसमें आपको अपने टूल के आसपास काम नहीं करना चाहिए।

— ओमनी

Answer 5

क्या अधिकतम अनुशंसित शीर्षक लंबाई वास्तव में 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" का अर्थ केवल "49 से अधिक नहीं" हो सकता है।

Comments

दूसरी ओर, डिफ़ॉल्ट हाइलाइटिंग पहले 50 वर्णों को उजागर करता है। यह एक विसंगतिपूर्ण विसंगति प्रतीत होती है।

— अगस्त जनसे