क्या मुझे git कमिट मैसेज में भूत या वर्तमान काल का उपयोग करना चाहिए? [बन्द है]


530

मैंने एक बार पढ़ा कि git प्रतिबद्ध संदेश अनिवार्य वर्तमान काल में होना चाहिए, उदाहरण के लिए "x के लिए परीक्षण जोड़ें"। मैं हमेशा अपने आप को पिछले तनाव का उपयोग करके पाता हूं, उदाहरण के लिए "एक्स के लिए जोड़े गए परीक्षण" हालांकि, जो मुझे बहुत अधिक स्वाभाविक लगता है।

यहाँ हाल ही में जॉन रेजिग ने एक संदेश में दोनों को दिखाया है:

जोड़तोड़ परीक्षणों में कुछ और jQuery के सेट परिणामों को टवीक करें। साथ ही अपेक्षित परीक्षा परिणामों का क्रम तय किया।

फर्क पड़ता है क्या? मुझे कौन सा उपयोग करना चाहिए?


12
इस सवाल को मुख्य रूप से राय-आधारित के रूप में बंद करने की आवश्यकता है । बस पहले से ही आवश्यक और पिछले तनाव के बीच मतभेदों को देखो ! यह कहा जा रहा है, मैं अनिवार्य तनाव के लिए मतदान करता हूं, क्योंकि यह वास्तव में स्पष्ट करता है कि आप अपने इतिहास, चेरी-पिकिंग, पैच लगाने आदि के लिए क्या कर रहे हैं!

इसी तरह के सवाल: stackoverflow.com/questions/1753808/…
wip


यह भी देखें github.com/agis-/git-style-guide
Agis

3
@ ईऑनिल अगर यह राय आधारित होने के लिए बंद है तो यह वहां भी राय आधारित होने के लिए बंद हो जाएगा।
शाफ़्ट

जवाबों:


600

वर्तमान-काल, अनिवार्य-शैली के प्रतिबद्ध संदेशों की प्राथमिकता Git से ही आती है। से प्रलेखन / SubmittingPatches Git में रेपो:

अपने मनोदशा में बदलाव का वर्णन करें, जैसे "[इस पैच] के बजाय" xyzzy do frotz करें "" xyzzy do frotz बनाता है "या" [I] बदलकर xyzzy करें ", जैसे कि आप कोडबेस को इसके बदलने के आदेश दे रहे हैं व्यवहार।

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


89
मुझे लगता है कि यह एक उत्कृष्ट विकल्प है। इस बारे में सोचें कि एक प्रतिबद्ध क्या है, अलग रूप में: पिछले राज्य से एक नए राज्य में जाने के लिए निर्देशों का एक सेट। जैसे कि यह कहता है कि "इस लाइन को यहां जोड़ें, इस लाइन को यहां हटाएं", प्रतिबद्ध संदेश गुणात्मक शब्दों में "यह परिवर्तन करें" कहता है। (हां, git कमिट को केवल एक पेड़ के रूप में मेटाडेटा के साथ संग्रहीत करता है, लेकिन एक मानव के लिए, एक प्रतिबद्ध का महत्वपूर्ण हिस्सा अंतर है।)
Cascabel

124
आप पिछले राज्य से नए राज्य में जाने के लिए निर्देशों के एक सेट के रूप में एक प्रतिबद्ध देख सकते हैं; लेकिन मैं इसे कोड के विकास में चेक-पॉइंट के रूप में अधिक देखता हूं। मेरे लिए, प्रतिबद्ध संदेश उस कोड का एक लॉग है जो पिछली प्रतिबद्ध के बाद से कोड के लिए किया गया है; और एक लॉग के लिए, पिछले तनाव एक बहुत अधिक समझ में आता है। यदि आप वास्तव में सोचते हैं कि प्रतिबद्ध संदेश निर्देशों का एक सेट होना चाहिए, तो अनिवार्य तनाव का रास्ता है। मैं वास्तव में इसके बारे में उस तरह से नहीं सोचता।
कराडोक

10
@oschrenk: फ़ाइल के बाद के संस्करणों ने एक कारण दिया है: "अनिवार्य मनोदशा में अपने बदलावों का वर्णन करें, जैसे '[यह पैच] के बजाय' xyzzy do frotz करें ' ', मानो आप अपने व्यवहार को बदलने के लिए कोडबेस को आदेश दे रहे हैं। "
मिपाडी

44
प्रतिबद्ध संदेश अत्यावश्यक होना चाहिए, तनावग्रस्त होना चाहिए क्योंकि आपके या किसी अन्य व्यक्ति के साथ ऐसा करने से rebaseया cherry-pickउस स्थिति में, प्रतिबद्ध का उपयोग उसके मूल संदर्भ के बाहर किया जा सकता है। परिणामस्वरूप, किसी भी आसपास के प्रतिबद्ध संदेशों को देखने के लिए पाठक की अपेक्षा किए बिना प्रतिबद्ध संदेश को स्टैंडअलोन लिखा जाना चाहिए। जब आप चेरी पिकिंग पैच होते हैं, तो "फिक्स्ड एस्कॉर्ट एल्गोरिथ्म" या "सॉर्टिंग: प्रदर्शन में सुधार" "फिक्स्ड बग # 124" या "प्रदर्शन को बेहतर बनाने के लिए संशोधित छंटाई" के बजाय इसे लागू करने के लिए अधिक समझ में आता है।
मिको रानाल्टेन

5
जिस तरह से मैं इस बारे में सोचता हूं वह यह है कि संदेश मुझे यह बताना चाहिए कि अगर मैं अपनी शाखा में इस प्रतिबद्ध को लागू करने के लिए चुनूं तो क्या बदल जाएगा। मैं इसे एक लॉग के रूप में नहीं सोचता, लेकिन यह बताता हूं कि मैं आगे बढ़ सकता हूं और मुझे यह जानना होगा कि जब मैं किसी विशेष राज्य का चयन करूंगा तो क्या होगा।
स्टीवनबोट

357

आपकी परियोजना को लगभग हमेशा भूत काल का उपयोग करना चाहिए । किसी भी मामले में, परियोजना को हमेशा स्थिरता और स्पष्टता के लिए एक ही तनाव का उपयोग करना चाहिए।

मैं वर्तमान काल का उपयोग करने के लिए बहस करने वाले कुछ अन्य तर्क समझता हूं, लेकिन वे आमतौर पर लागू नहीं होते हैं। निम्नलिखित बुलेट पॉइंट वर्तमान काल में लिखने के लिए सामान्य तर्क हैं, और मेरी प्रतिक्रिया है।

  • वर्तमान काल में लिखना किसी को बताता है कि आपने जो किया था, उसके बजाय वह क्या करेगा

यह सबसे सही कारण है जो वर्तमान काल का उपयोग करना चाहता है, लेकिन केवल परियोजना की सही शैली के साथ। सोचने का यह तरीका सभी परिवर्तनों को वैकल्पिक सुधारों या विशेषताओं के रूप में मानता है, और आप यह तय करने के लिए स्वतंत्र हैं कि कौन सा रखना है और कौन से अपने विशेष भंडार में अस्वीकार करना है।

यह तर्क काम करता है यदि आप वास्तव में वितरित परियोजना के साथ काम कर रहे हैं। यदि आप किसी वितरित प्रोजेक्ट के साथ काम कर रहे हैं, तो आप शायद एक ओपन सोर्स प्रोजेक्ट पर काम कर रहे हैं। और यह शायद एक बहुत बड़ी परियोजना है अगर यह वास्तव में वितरित किया जाता है। वास्तव में, यह शायद लिनक्स कर्नेल या गिट है। चूंकि लिनक्स संभावना है कि जीआईटी का प्रसार और लोकप्रियता में वृद्धि हुई है, इसलिए यह समझना आसान है कि लोग इसकी शैली को प्राधिकरण क्यों मानते हैं। हाँ, शैली उन दो परियोजनाओं के साथ समझ में आता है। या, सामान्य तौर पर, यह बड़े, खुले स्रोत, वितरित परियोजनाओं के साथ काम करता है ।

यह कहा जा रहा है, स्रोत नियंत्रण में अधिकांश परियोजनाएं इस तरह से काम नहीं करती हैं। यह आमतौर पर अधिकांश रिपॉजिटरी के लिए गलत है। यह एक कमिट के बारे में सोचने का एक आधुनिक तरीका है: तोड़फोड़ (एसवीएन) और सीवीएस रिपॉजिटरी, रिपॉजिटरी चेक-इन की इस शैली का मुश्किल से समर्थन कर सकते हैं। आमतौर पर एक एकीकरण शाखा ने खराब चेक-इन को छानने का काम संभाला, लेकिन उन लोगों को आमतौर पर "वैकल्पिक" या "अच्छा-से-सुविधाएँ नहीं" माना जाता था।

अधिकांश परिदृश्यों में, जब आप स्रोत रिपॉजिटरी में कमिट कर रहे होते हैं, तो आप एक जर्नल प्रविष्टि लिख रहे होते हैं, जो यह बताता है कि इस अपडेट के साथ क्या बदलाव आया है, ताकि भविष्य में दूसरों के लिए यह समझना आसान हो सके कि एक बदलाव क्यों किया गया। यह आम तौर पर एक वैकल्पिक परिवर्तन नहीं है - परियोजना में अन्य लोगों को या तो विलय या उस पर छूट देने की आवश्यकता होती है। आप इस तरह के रूप में एक डायरी प्रविष्टि लिख सकता हूँ नहीं "प्रिय डायरी, आज मैं पूरा एक लड़का और वह कहते हैं मेरे लिए नमस्ते।", लेकिन इसके बजाय आप लिखते हैं "मैं मुलाकात एक लड़का और वह कहा मुझे करने के लिए नमस्ते।"

अंत में, इस तरह की गैर-वितरित परियोजनाओं के लिए, 99.99% समय एक व्यक्ति को एक प्रतिबद्ध संदेश पढ़ने के लिए होगा जो इतिहास पढ़ने के लिए है - इतिहास पिछले तनाव में पढ़ा जाता है। 0.01% समय यह तय करेगा कि उन्हें इस प्रतिबद्ध को लागू करना चाहिए या इसे अपनी शाखा / भंडार में एकीकृत करना चाहिए या नहीं।

  • संगति। यही कारण है कि यह कई परियोजनाओं में है (स्वयं गिट सहित)। इसके अलावा कमिट उत्पन्न करने वाले git टूल (जैसे git मर्ज या git रीवर्ट) करते हैं।

नहीं, मैं आपको गारंटी देता हूं कि संस्करण नियंत्रण प्रणाली में कभी लॉग इन की गई अधिकांश परियोजनाएं पिछले इतिहास में अपना इतिहास रखती हैं (मेरे पास संदर्भ नहीं हैं, लेकिन शायद यह सही है, वर्तमान तनाव के तर्क को देखते हुए गिट के बाद से नया है)। वर्तमान तनाव में "संशोधन" संदेश या प्रतिबद्ध संदेश केवल सही मायने में वितरित परियोजनाओं में समझ बनाने लगे - ऊपर पहला बिंदु देखें।

  • लोग न केवल "इस कोडबेस के साथ क्या हुआ" यह जानने के लिए इतिहास पढ़ते हैं, बल्कि "जब मैं इस कमेंट को चुनता हूं तो क्या होता है" जैसे सवालों के जवाब देने के लिए, या "इन कमेंट्स की वजह से मेरे कोड बेस के लिए किस तरह की नई चीजें होंगी?" मैं भविष्य में विलीन हो सकता हूं या नहीं ”।

पहला बिंदु देखें। किसी व्यक्ति द्वारा प्रतिबद्ध संदेश पढ़ते समय 99.99% इतिहास पढ़ने के लिए होगा - इतिहास पिछले काल में पढ़ा जाता है। 0.01% समय यह तय करेगा कि उन्हें इस प्रतिबद्ध को लागू करना चाहिए या इसे अपनी शाखा / भंडार में एकीकृत करना चाहिए या नहीं। 99.99% बीट 0.01% है।

  • यह आमतौर पर छोटा होता है

मैंने कभी भी एक अच्छा तर्क नहीं देखा है जो कहता है कि अनुचित तनाव / व्याकरण का उपयोग करें क्योंकि यह छोटा है। आप शायद मानक 50 वर्ण संदेश के लिए औसतन केवल 3 वर्णों को बचाएंगे। कहा जा रहा है कि, वर्तमान में औसतन कुछ वर्ण छोटे होंगे।

  • आप अपने अंक / सुविधा ट्रैकर में टिकटों के शीर्षक के साथ अधिक लगातार नाम रख सकते हैं (जो भूतकाल का उपयोग नहीं करते हैं, हालांकि कभी-कभी भविष्य में)

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

इतिहास (यानी संदेशों प्रतिबद्ध) कुछ है कि अतीत में किया गया था (जैसे समस्या के रूप में लिखा है था निर्धारित)।


79
मैंने पहली बार आज अनिवार्य शैली के लिए आवश्यक वरीयता के बारे में सुना। मेरे लिए, यह इतना अस्वाभाविक और विचित्र लग रहा था कि मैंने कुछ और राय लेने का फैसला किया। मुझे यह देखकर प्रसन्नता हुई कि मैं केवल वही नहीं हूं जो यह सोचता है कि पिछले संदेशों के लिए अधिक तनावपूर्ण है। :)
कराडोक

56
git का स्वतः जनरेट किया गया मर्ज और रिबास कमिट मैसेज अत्यावश्यक है और वर्तमान तनाव ("मर्ज", "मर्ज"; "रिबेस" नहीं "रीबेड") है, इसलिए आप इसे अपने खुद के कमिट मैसेज में मेल कर सकते हैं।
mjs

13
लगता है कि अंतर के परिवर्तन पर ध्यान देने के बीच है सॉफ्टवेयर - "फिक्स्ड एक्स बाई वाई" - या रिपॉजिटरी - "एक्स को ठीक करने के लिए वाई करें।" एक अच्छे तर्क के लिए +1, लेकिन मुझे लगता है कि रेपो को आमतौर पर परिणामी सॉफ़्टवेयर के बजाय स्वयं पर ध्यान केंद्रित करना चाहिए।
l0b0

28
बात यह है कि बड़ी परियोजनाओं (जैसे लिनक्स) के लिए जरूरी वर्तमान, तनावपूर्ण कार्यों का उपयोग करना, इसलिए यह स्पष्ट रूप से तराजू है। इसके अलावा, इसमें पिछले तनाव की तुलना में बहुत अधिक शून्य प्रयास की आवश्यकता होती है। परिणाम के रूप में, मुझे कोई कारण नहीं दिखता है ("पुराने लोगों के अलावा अन्य लोगों का उपयोग अतीत के तनाव में प्रतिबद्ध संदेश लिखने के लिए किया जाता है") कुछ और लेकिन अनिवार्य, वर्तमान काल का उपयोग करने के लिए। यदि आप git कमांड सेट सीख सकते हैं, तो आप अनिवार्य, वर्तमान काल में लेखन सीख सकते हैं।
मिको रानाल्टेन

35
इम्पीरियल "गिट के बाद से नया" नहीं है। ChangeLog git से बहुत पहले से मौजूद था, और GNU प्रोजेक्ट में अनिवार्य शैली का उपयोग हमेशा से ही अनुशंसित शैली रही है। gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
ADL

81

मैंने 365 वाँ पर पूर्ण विवरण लिखा ।

अनिवार्य, वर्तमान काल का उपयोग वह होता है जिसका उपयोग करने में थोड़ा समय लगता है। जब मैंने इसका उल्लेख करना शुरू किया, तो इसे प्रतिरोध के साथ मिला। आमतौर पर "प्रतिबद्ध संदेश रिकॉर्ड करता है कि मैंने क्या किया है" की तर्ज पर। लेकिन, Git एक वितरित संस्करण नियंत्रण प्रणाली है जहां से परिवर्तन प्राप्त करने के लिए संभावित रूप से कई स्थान हैं। संदेशों को लिखने के बजाय यह कहें कि आपने क्या किया है; इन संदेशों पर विचार करें कि क्या कमिटमेंट लागू होगा। शीर्षक के साथ प्रतिबद्ध होने के बजाय:

Renamed the iVars and removed the common prefix.

इस तरह से एक है:

Rename the iVars to remove the common prefix

जो किसी को बताता है कि आप क्या करते हैं, इसके बजाय प्रतिबद्ध क्या करेगा। इसके अलावा, यदि आप अपने रिपॉजिटरी इतिहास को देखते हैं, तो आप देखेंगे कि Git जेनरेट किए गए संदेश इस तनाव में भी लिखे गए हैं - "मर्ज" नहीं "मर्ज किया गया", "रिबेस" नहीं "रीबेड" इसलिए उसी टेंशन में लिखना चीजों को लगातार बनाए रखता है। यह पहली बार में अजीब लगता है, लेकिन यह समझ में आता है (आवेदन पर उपलब्ध प्रशंसापत्र) और अंततः स्वाभाविक हो जाता है।

यह सब कहने के बाद - यह आपका कोड है, आपका भंडार है: इसलिए अपने स्वयं के दिशानिर्देश स्थापित करें और उनसे चिपके रहें।

यदि, हालांकि, आप इस तरह से जाने का निर्णय लेते हैं, तो फिर git rebase -iसे देखने के विकल्प के साथ एक अच्छी बात होगी।


7
ठीक है, आपने दो अलग-अलग दिशानिर्देशों को मिलाया है: गिट ओपन सोर्स प्रोजेक्ट, और गिट का नियमित उपयोग। प्रदान की गई लिंक में तनाव का जिक्र नहीं है । आधिकारिक Git doc में केवल 50 char सीमा का उल्लेख है। Git एक वितरित VCS है, जहां से परिवर्तन प्राप्त करने के लिए कई स्थान हैं ... इन संदेशों पर विचार करें कि प्रतिबद्ध लागू करने के लिए निर्देश क्या हैं। यह केवल कुछ परियोजनाओं पर लागू होता है जो वास्तव में वितरित परियोजनाएं हैं। 99.999% गिट कमिट को कभी भी इस तरह से मैन्युअल रूप से लागू नहीं किया जाएगा। अधिकांश परियोजनाओं में, इतिहास एक परिवर्तन लॉग है, जो पिछले काल में होना चाहिए।
मैट क्विगले

4
"और पूर्ण विराम छोड़ देना चाहिए"
ताकेशिन

30

वर्तमान तनाव की स्थिति से चिपके रहना चाहिए

  • एक मानक होना अच्छा है
  • यह बग ट्रैकर में टिकटों से मेल खाता है जो स्वाभाविक रूप से "कुछ को लागू करें", "कुछ ठीक करें", या "कुछ का परीक्षण करें" है।

16

आप किसके लिए संदेश लिख रहे हैं? और क्या पाठक आम तौर पर इस संदेश को पूर्व या बाद के स्वामित्व को पढ़ रहा है?

मुझे लगता है कि दोनों दृष्टिकोणों से यहां अच्छे उत्तर दिए गए हैं, मैं शायद सुझाव देने में कमी कर दूंगा कि हर परियोजना के लिए सबसे अच्छा जवाब है। विभाजित वोट जितना सुझाव दे सकता है।

संक्षेप में प्रस्तुत करने के लिए:

  • क्या संदेश मुख्य रूप से अन्य लोगों के लिए है, आमतौर पर कुछ बिंदु पर पढ़ने से पहले वे परिवर्तन मान चुके हैं: परिवर्तन का एक प्रस्ताव उनके मौजूदा कोड को क्या करेगा।

  • क्या संदेश मुख्य रूप से अपने आप को (या अपनी टीम को) एक पत्रिका / रिकॉर्ड के रूप में है, लेकिन आम तौर पर बदलाव होने और जो हुआ उसकी खोज करने के लिए वापस खोज के परिप्रेक्ष्य से पढ़ रहा है।

शायद यह आपकी टीम / परियोजना के लिए प्रेरणा का मार्ग प्रशस्त करेगा।


10

फर्क पड़ता है क्या? लोग आम तौर पर संदेशों को सही ढंग से व्याख्या करने के लिए पर्याप्त स्मार्ट होते हैं, अगर वे नहीं हैं, तो शायद आपको उन्हें अपने भंडार तक पहुंचने नहीं देना चाहिए!


27
करने के लिए कुछ लोगों को , उस बात के काफ़ी तरह बातें।
वेस्ले मर्च

2
@ लिंक वर्तमान और अतीत के बारे में कोई बयान नहीं देता है।
छत

2
अगर प्रोजेक्ट बड़े पैमाने पर करता है तो कोड रिव्यू और बग हंटिंग करने वाले लोग बहुत सारे कमिटमेंट देखेंगे कि उन्हें आपकी और मेरी मदद की जरूरत है। भविष्य में एक उचित संदेश नहीं लिखने के लिए भविष्य में प्रमुख सिरदर्द पैदा करने के लिए अब कुछ सेकंड बचाने का कोई मतलब नहीं है।
मिको रानाल्टेन

मैं यह नहीं कह रहा हूँ कि एक अच्छा वचन न लिखें। मैं कह रहा हूं कि अगर आप भूतकाल या वर्तमान काल का उपयोग करते हैं तो इससे कोई फर्क नहीं पड़ता।
माइकल बाल्ड्री

1
आपको कैसे पता चलेगा, कि जिस व्यक्ति को आपके प्रतिबद्ध संदेश की व्याख्या करने में सक्षम नहीं किया जा रहा है, क्या वह उस व्यक्ति के लिए पर्याप्त सक्षम नहीं है, या आप एक अच्छा प्रतिबद्ध संदेश लिखने में सक्षम नहीं हैं?
हरिस

7

यह आप पर निर्भर है। अपनी इच्छानुसार कमिट मैसेज का उपयोग करें। लेकिन यह आसान है अगर आप समय और भाषाओं के बीच स्विच नहीं कर रहे हैं।

और यदि आप एक टीम में विकसित होते हैं - तो इस पर चर्चा की जानी चाहिए और इसे निर्धारित किया जाना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.