जवाबों:
संस्करण नियंत्रण उपकरण काफी शक्तिशाली हैं कि व्यक्ति को यह देखने के लिए कि फाइलों को संशोधित किया गया था, और क्या तरीके जोड़े गए थे। इसका मतलब यह है कि सामान्य रूप से, लॉग संदेश जो पहले से मौजूद है को स्पष्ट रूप से डुप्लिकेट करते हैं जो लॉग को प्रदूषित कर रहे हैं।
आपने somefuncआवश्यकता पूरी करने के लिए विधि जोड़ी , अर्थात:
इसका मतलब यह है कि आपके लॉग संदेशों को यह स्पष्ट करना चाहिए कि क्या सुविधाएँ / बग प्रभावित हुए थे या फिर क्या करना था।
TICKET / ISSUE NUMBER जोड़ना न भूलें ।
यदि आपके पास कोई सुविधा है या # # टिकट जारी करने वाली ट्रैकिंग प्रणाली है , तो उस आईडी को कमिट में रखना सुनिश्चित करें। जो भी उस सुविधा या समस्या के बारे में अधिक जानना चाहता है जो आप काम कर रहे थे।
मेरी अंतिम परियोजना में, एक मैक्रो था जिसे यह सुनिश्चित करने के लिए विकसित किया गया था कि टिप्पणी के पहले 7 अंक स्पष्ट खोज (हमारा मुद्दा / सुविधा ट्रैकिंग सिस्टम) से एक वैध अंक संख्या थी।
मैं उस प्रकार का काम करता हूं जब मैं कमिट करता हूं जैसे कि एक दोष के लिए फिक्स जो कई फाइलों में परिवर्तन की आवश्यकता होती है। इससे यह बताना थोड़ा आसान हो जाता है कि परिवर्तन में व्यक्तिगत फ़ाइलों को देखे बिना वास्तव में क्या बदल गया है।
एकल फ़ाइल परिवर्तन के लिए, यह अनावश्यक है।
पहली पंक्ति हमेशा परिवर्तन का एक उच्च-स्तरीय वर्णन है, जैसे कि दोष या उपयोगकर्ता कहानी का लिंक।
यदि यह प्रतिबद्ध संदेश की कथा में प्रासंगिक जानकारी है, तो हाँ, इसे शामिल करें। यदि जानकारी का एकमात्र बिट फ़ाइल नाम ही है, तो नहीं।
उदाहरण के लिए यह समझ में आता है: "build_foo () फ़ंक्शन को fooutil.c से foobase.c पर ले जाया गया, क्योंकि अधिकांश प्रोग्राम जो build_foo () का उपयोग करना चाहते हैं, वे पहले से ही foobase.c सहित हैं।"
यह एक नहीं है: "बार पैरामीटर लेने के लिए fooutil.c में build_foo () अपडेट किया गया।"
मैं यहां एक अलग परिप्रेक्ष्य जोड़ना चाहता हूं।
मेरा उत्तर हां या नहीं है, लेकिन आम तौर पर मैं हां कहूंगा।
संस्करण नियंत्रण वास्तव में काफी शक्तिशाली है यह जानने के लिए कि किस फ़ाइल को अपडेट किया जा रहा है। लेकिन, जब हम करते हैं
$ 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
इसे पढ़ने से, हम जानते हैं कि तय की जा रही त्रुटि एपीआई घटक पर है, और यह शायद कोड आधार पर एपीआई निर्देशिका के तहत है।
हम हालांकि कर सकते थे
$ git show COMMIT_ID --name-only
लेकिन यह केवल फ़ाइलों को प्राप्त करने के लिए और अधिक कदम जोड़ता है।
मुझे लगता है कि यहां असली सवाल यह है कि आपके कमिटमेंट कितने सीमित हैं? यदि आप एक बार में एक साथ कई प्रकार के असंबंधित परिवर्तन करने की प्रतीक्षा करते हैं, तो आपको यह निर्दिष्ट करने की आवश्यकता महसूस हो सकती है कि किस उद्देश्य के लिए फाइलें बदली गई थीं।
हालाँकि, यदि आपने बस अधिक बार कम संकीर्ण किए हैं, तो एक एकल कमिट समझाएगा कि कौन सी फाइलें संशोधित की गई थीं और आप केवल यह बता सकते हैं कि संदेश में क्या उद्देश्य था।
अधिक कमिट्स, अधिक बार। यही कारण है कि आप अपने संदेशों में इस तरह की क्रिया से बच सकते हैं।