मैं TXR परियोजना पर एकमात्र कमिट्रेटर रहा हूं, और इस परियोजना में काफी पहले से एक विस्तृत चेंजलॉग रखा है। यह 11,000 लाइनों के करीब लंबी और बढ़ती है:
http://www.kylheku.com/cgit/txr/tree/ChangeLog
(रेपो में प्रतिबद्ध संदेश केवल चेंजलॉग में जाने वाली एक प्रति है।)
[२०१६ संपादित करें: २०१५ के मध्य तक, मैं अब ChangeLog फ़ाइल को बनाए नहीं रख सकता; हालाँकि, प्रतिबद्ध संदेश एक प्रारूप में लिखे जाते हैं जो उसी समय Git और ChangeLog सम्मेलनों के अनुरूप होते हैं। विस्तार का एक ही स्तर है, एक तरह से जो मर्ज की समस्या पैदा नहीं करता है। चेंजलॉग फ़ाइल को इन टिप्पणियों से यंत्रवत् पुन: निर्मित किया जा सकता है।]
हां, एक से अधिक बार मैं एक पुराने प्रतिबद्ध संदेश में एक बदलाव से जुड़ा हुआ हूं, जो कुछ टूट गया (जिसकी मदद से खुला git bisect)। संदेश ने मुझे यह समझने में मदद की कि मैं क्या कर रहा था।
चेंजलॉग में आप बता सकते हैं कि फंक्शन, टाइप, मैक्रो या ग्लोबल वैरिएबल को पहली बार कब पेश किया गया था और बाद में इसे बदलावों द्वारा छुआ गया था।
लेकिन अपने द्वारा काम करते समय इन जैसे विस्तृत प्रतिबद्ध संदेश लिखने का मुख्य कारण यह है: ऐसा करते समय आपको कीड़े मिलते हैं ।
एक विस्तृत प्रतिबद्ध संदेश लिखने के लिए किसी और द्वारा आपकी प्रतिबद्ध की कोड समीक्षा के समान लाभ हैं। एक प्रतिबद्ध समीक्षा में मूल्य इतना नहीं है कि कोई आपके कोड की जांच कर रहा है, बल्कि यह कि आपको दूसरे डेवलपर को अपने परिवर्तनों को समझाना होगा।
जब आप चीजों को समझाने की कोशिश करते हैं, तो आप कभी-कभी पाते हैं कि उनका कोई मतलब नहीं है।
एक और कारण: आप एक बेकार बदलाव करते हुए खुद को पकड़ सकते हैं । एक विस्तृत प्रतिबद्ध टिप्पणी लिखकर, आप जो कर रहे हैं उसके उच्च स्तर के दृश्य को कैप्चर करते हैं, और फिर कभी-कभी आप इस तथ्य से सामना करते हैं कि यह एक अच्छा बदलाव नहीं है।
मैंने कभी-कभी परिवर्तन किए हैं, जब चेंजलॉग प्रविष्टि लिखने के बीच में मैंने महसूस किया कि यह एक git reset --hard(इन बेकार परिवर्तनों को दूर फेंकने के बजाय) होने जा रहा था git commit -a।