क्या संदेश में बग / समस्या का संदर्भ अच्छा व्यवहार माना जाता है?

Question

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

मैं इस अभ्यास के लिए केवल कुछ डाउनसाइड देख सकता हूं। यदि भविष्य में कभी-कभी स्रोत कोड बग ट्रैकिंग सॉफ़्टवेयर से अलग हो जाता है (या रिपोर्ट किए गए बग / मुद्दे किसी तरह खो जाते हैं)। या जब कोई कमिट के इतिहास में दिख रहा है, लेकिन हमारे बग ट्रैकर तक पहुंच नहीं है।

मेरा प्रश्न है कि क्या प्रतिबद्ध संदेश में बग / समस्या का संदर्भ अच्छा व्यवहार माना जाता है? क्या कुछ अन्य डाउनसाइड हैं?

Answer 1

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

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

Answer 2

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

फिक्स बग # 123: लॉगिन के बाद ऐप क्रैश हो गया

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

Comments

हम वास्तव में ऐसा करते हैं, इसलिए हमें हर बार कमिट के इतिहास के माध्यम से ब्राउज़ करते समय बग ट्रैकर पर स्विच करने की आवश्यकता नहीं है।

— क्रिश्चियन पी

ठीक है, तो मैं इसे वैसे ही छोड़ दूँगा। IMO, यह सबसे अच्छा तरीका है कि आप इसे कैसे कर सकते हैं!

— क्रिश्चियन स्पैक्ट

हाँ, अच्छी बात है। यह मेरी धारणा वैसे भी थी। बस बग / समस्या आईडी अकेले मेरे अनुभव में पर्याप्त नहीं है। कमिट लॉग को देखकर आप अभी भी यह देखना चाहते हैं कि प्रत्येक कमिटमेंट क्या था, जैसे कि इस कोड परिवर्तन का व्यापक कारण क्या था। कभी-कभी प्रतिबद्ध संदेश तकनीकी पक्ष पर अधिक होता है जबकि बग ट्रैकिंग सिस्टम के लिए पाठ सॉफ्टवेयर के उपयोगकर्ताओं की ओर अधिक सक्षम होता है।

— मैनफ्रेड

यह आमतौर पर मानक अभ्यास है जहां मैंने भी काम किया है, मुझे लगता है कि यह करने का सही तरीका है।

— कार्सन63000

+1 हमेशा ऐसा करें! मैंने सिर्फ एक परियोजना के रखरखाव पर काम किया है, जो "5423 बग का कारण हो सकता है" जैसे रत्नों से भरा है। हमारे पास उनके बग ट्रैकर तक पहुंच नहीं है।

— क्रिप्टिक

Answer 3

यह बहुत आम बात है, और मैंने इसे बेहद सुविधाजनक पाया है। मैं टीआरएसी का उपयोग करता हूं, इसलिए मैं कोड इतिहास पढ़ सकता हूं और उस कार्य पर नेविगेट कर सकता हूं जिसने परिवर्तन को हटा दिया है, या कार्य इतिहास पढ़ सकता है और कोड परिवर्तनों पर नेविगेट कर सकता है।

"यदि भविष्य में कभी ..." यदि आप बग ट्रैकर से कोड को अलग करते हैं, तो पुराना संशोधन इतिहास शायद आगे की रुचि का नहीं होगा।

Answer 4

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