मेरा पसंदीदा Git commit (2019)
एक छोटे, एक-अक्षर वाले fix ने—जिसने config file से एक non‑ASCII whitespace हटाया—Git commit messages पर इस बड़े debate को जन्म दिया कि developers को उन पर कितना प्रयास करना चाहिए। कई लोगों का मानना है कि भविष्य की debugging, code archaeology, और reviews के लिए समृद्ध, सुव्यवस्थित messages बेहद मूल्यवान हैं, खासकर जब issue trackers या wikis गायब हो जाएँ या उन्हें खोजना कठिन हो; दूसरी ओर, कुछ लोग कहते हैं कि लंबे, narrative messages शायद ही पढ़े जाते हैं, उन्हें अलग documentation या PRs में होना चाहिए, और ऐसे tools से कमजोर पड़ जाते हैं जो केवल पहली line दिखाते हैं। चर्चा में “smart” Unicode characters से tooling के टूटने, squash merges और खराब history hygiene के असर, और ऐसे बेहतर interfaces की ज़रूरत जैसे मुद्दे भी शामिल हैं जो historical context को ढूँढना और उपयोग करना आसान बनाएं।
स्मार्ट quotes, Unicode, और “gremlin” characters
- कई लोग config या source files में smart quotes और non‑ASCII whitespace से हुई टूट‑फूट का वर्णन करते हैं (अक्सर Outlook, macOS editors, TextEdit, Notes के जरिए)।
- कुछ लोगों का तर्क है कि typographic quotes और अलग whitespace language और typography के लिए अलग code points होने चाहिए; अन्य कहते हैं कि over‑semantic Unicode एक design mistake है और style को fonts द्वारा संभाला जाना चाहिए।
- इस पर बहस है कि software को smart quotes को auto-convert करना चाहिए या नहीं, क्योंकि localized quoting rules और language detection इसे कठिन बनाते हैं।
- कई users अब IDE highlighting, pre-commit hooks, keyboard remapping, या editor configs पर निर्भर करते हैं ताकि इन characters को रोका जा सके या उजागर किया जा सके।
विस्तृत commit messages का value और style
- कई लोग उदाहरण commit की प्रशंसा करते हैं: समृद्ध context, subtle bug की स्पष्ट व्याख्या, और debugging process का रिकॉर्ड।
- अन्य इसे अत्यधिक “wall of text” मानते हैं; वे एक संक्षिप्त summary चाहते हैं (खासकर पहली line), आदर्श रूप से BLUF/TL;DR शैली में, और नीचे वैकल्पिक विवरण।
- अक्सर सुझाई गई संरचना: problem और scope समझाने वाला छोटा subject, फिर current behavior, cause, और new behavior पर paragraphs।
Commit messages बनाम अन्य documentation
- एक पक्ष commit messages को key, durable documentation मानता है—खासकर वर्षों बाद
blame/history spelunking करते समय या जब Jira/Confluence जैसे systems गायब हो जाते हैं। - दूसरा पक्ष deep design rationale को issues, PR descriptions, या markdown docs में रखना पसंद करता है, क्योंकि commit messages immutable होते हैं और उन्हें collaboratively refine करना कठिन होता है।
- व्यापक सहमति है कि commit messages को “what” से अधिक “why” document करना चाहिए; diff पहले ही code changes दिखा देता है।
Tooling, workflows, और discoverability
- कई लोग ध्यान देते हैं कि आम tools और hosted forges केवल पहली line दिखाते हैं, इसलिए लंबे bodies का कम उपयोग होता है।
- कुछ का तर्क है कि Git और GUIs history exploration को बहुत tedious बना देते हैं, जिससे commit messages पर निर्भरता कम हो जाती है; दूसरे जवाब देते हैं कि अच्छे editor/CLI tools (blame, log, magit, IDE integrations) इसे काफी usable बनाते हैं।
- Squash-merging और लंबे समय तक चलने वाली, गंदी branches की आलोचना की जाती है क्योंकि वे उपयोगी history नष्ट करती हैं और “checkpoint” commits को बढ़ावा देती हैं।
- invalid encodings के लिए खराब error messages और कमजोर validation को लेकर frustration है; बेहतर tooling इस bug को पूरी तरह रोक सकती थी।
उल्लेखित व्यावहारिक सुझाव
- गैर‑ASCII whitespace को flag करने के लिए editor configs, syntax highlighting, या hooks का उपयोग करें।
- atomic, अच्छी तरह scoped commits और meaningful messages को प्राथमिकता दें; commit messages को “future you के लिए notes” समझें।
- केवल external trackers या PRs पर निर्भर न रहें; उन्हें link करें, लेकिन essential context को code के पास या history में रखें।