Git Notes: Git की सबसे शानदार और सबसे कम पसंद की जाने वाली सुविधा (2022)

• Git notes एक शक्तिशाली टूल है जो commits आदि में metadata जोड़ने की सुविधा देता है
• यह फीचर तब पूरक जानकारी संग्रहीत करने में मदद करता है जब commit message को बदला नहीं जा सकता
• इसका उपयोग code review history या test results जैसी विभिन्न जानकारी सहेजने के लिए किया जा सकता है
• इससे distributed code review system तक बनाया जा सकता है, लेकिन इसकी usability और awareness कम है
• GitHub पर इसे निष्क्रिय कर दिए जाने जैसे सीमित support के कारण रोज़मर्रा में इसका अपनाव कम है

---

Git notes क्या है

• Git notes git में track किए जाने वाले किसी भी object (commit, blob, tree) में metadata जोड़ने की सुविधा है
• आम तौर पर एक बार रिकॉर्ड हो जाने के बाद commit message बदला नहीं जा सकता, लेकिन git notes का उपयोग करके commit body बदले बिना नई जानकारी जोड़ी जा सकती है
• उदाहरण के लिए, नीचे की तरह किसी commit में notes जोड़े जा सकते हैं
  • git notes add -m 'Acked-by: <이메일>'
• notes, git log में एक अलग section के रूप में साथ में दिखाई देते हैं

वास्तविक उपयोग के मामले

• git परियोजना स्वयं भी git notes का उपयोग करके commits को mailing list के discussion threads से जोड़ती है
• notes के वास्तविक उपयोग के उदाहरणों में ये शामिल हैं
  • commit या branch के हिसाब से काम के समय को track करना
  • code review और test result logs संग्रहीत करना
  • पूरी तरह distributed code review system डिज़ाइन करना

code review और test results संग्रहीत करना

• code forge या review systems द्वारा code review metadata को offline, यानी स्वयं git में, संग्रहीत करने का समर्थन करने के मामले बढ़ रहे हैं
• Gerrit का reviewnotes plugin git log में reviewer और test execution history को notes के रूप में साथ दिखाता है
  • उपयोगकर्ता अलग से browser खोले बिना local में code review history देख सकते हैं

distributed code review system

• Google द्वारा विकसित git-appraise जैसे उदाहरण मौजूद हैं, जो git notes का उपयोग करके distributed code review को संभव बनाते हैं
• git-appraise code review requests, changes पर comments, review के बाद merge सहित सभी प्रक्रियाएँ git notes में रिकॉर्ड करता है, और online code hosting service से स्वतंत्र रूप से काम करता है
• local environment में पूरा collaboration संभव है, और यह web interface भी प्रदान करता है

कम usability और awareness

• Git notes का interface असुविधाजनक है और सामान्य उपयोगकर्ताओं के लिए सहज नहीं है, इसलिए इसका लगभग उपयोग नहीं होता
• GitHub ने 2014 के बाद commit notes दिखाना बंद कर दिया, जिससे इसके उपयोग के अवसर और कम हो गए
• commits के लिए notes management को git settings से कुछ आसान बनाया जा सकता है, लेकिन blob या tree objects पर notes जोड़ने के लिए git की internal structure (plumbing) की अतिरिक्त समझ चाहिए
• परिणामस्वरूप git notes अब भी एक niche और बहुत कम जानी जाने वाली सुविधा बनी हुई है

open forge से स्वतंत्रता

• git स्वयं distributed version control और code review को support कर सकता है, लेकिन review history जैसी कई अतिरिक्त value GitHub जैसी hosting services पर निर्भर हो जाती है
• Git notes का उपयोग करने से केवल code के बदलावों का इतिहास ही नहीं, बल्कि पूरे project history को भी distributed तरीके से store और distribute करने का रास्ता खुलता है
• इसका पूर्ण distributed development ecosystem और record preservation के लिए महत्वपूर्ण अर्थ है

[GN⁺]

Hacker News राय

• कम-ज्ञात Git trailers फीचर मौजूद है—जानकारी साझा करते हुए बताया गया कि trailers कमिट बनाते समय key-value रूप में metadata जोड़ सकते हैं, और Gerrit में Change-Id जोड़ने के लिए इसका उपयोग होता है। संबंधित लेख लिंक

  • PostgreSQL में COMMENT नाम का एक मिलता-जुलता फीचर है—जानकारी साझा करते हुए बताया गया कि COMMENT डेटाबेस ऑब्जेक्ट्स में टेक्स्ट जोड़ सकता है, और इच्छा जताई गई कि PostgreSQL key-value रूप में structured metadata एडिट करने की सुविधा भी दे। संबंधित दस्तावेज़ लिंक

  • open source upstream पर काम करते समय, unit test पूरे हो चुके कमिट्स को चिह्नित करने के लिए git notes इस्तेमाल करने का अनुभव साझा किया गया; git rebase -i से branch को व्यवस्थित करते समय यह उपयोगी था, लेकिन अब trailers बेहतर तरीका लगते हैं। अगर Change-Id जैसी सुविधा खुद git में शामिल हो जाए तो tools इसे बेहतर समझ पाएंगे। commit message से कमिट पहचानना थोड़ा नाज़ुक है; commit id की uniqueness अच्छी है, लेकिन वही बदलाव किसी दूसरे commit के ऊपर ले जाने पर उसकी पहचान के रूप में उपयोगिता घट जाती है। सुधार: trailers कमिट का हिस्सा होते हैं, इसलिए वे notes को पूरी तरह replace नहीं कर सकते।

  • हाल में पता चला कि GitHub [skip ci] की जगह अलग trailer का उपयोग करता है; शायद इसलिए कि उसे commit message से आसानी से अलग किया जा सके। GitHub सिर्फ आख़िरी trailer ही क्यों मांगता है, यह स्पष्ट नहीं; अनुमान है कि शायद regex processing की वजह से। संबंधित दस्तावेज़ लिंक

  • trailers फीचर के बारे में पहली बार पता चला। Conventional Commits के प्रशंसक के रूप में लगा कि इस तरह का metadata जोड़ने के लिए trailers बेहतर होंगे। यह जिज्ञासा भी जताई गई कि commit message में इसे manually जोड़ना और --trailer फ्लैग का उपयोग करना, कार्यात्मक रूप से एक जैसा है या नहीं।

  • स्वाभाविक रूप से issue tracking system के साथ integration करना चाहेंगे, लेकिन trailers जैसी जगह पर उसे डालना अक्षम लगता है क्योंकि वह issue tracker से बहुत दूर है। issue trackers trends के पीछे चलते हैं और कई फीचर्स देर से जोड़ते हैं। ticket नाम से निकले branch नाम को PR title के रूप में अनिवार्य रूप से इस्तेमाल करने का नियम असुविधाजनक बताया गया। इच्छा है कि किसी और metadata से commits और issues को जोड़ा जाए ताकि PR title अधिक सार्थक बने। यह आसानी से बदला जाने वाला मसला नहीं, इसलिए इंटरनेट पर ही भड़ास निकालने वाला विषय बन जाता है।

• जानकारी साझा की गई कि Forgejo ने इस साल जनवरी में जारी version 10 से trailers सपोर्ट शुरू किया। release notes pull request

• git notes और history rewrite (amend, rebase आदि) के बीच interaction को लेकर जिज्ञासा जताई गई—क्योंकि notes commit/tree/blob ID से जुड़े होते हैं, तो जब किसी commit को नए commit से replace किया जाता है, तब notes copy होते हैं या गायब हो जाते हैं? interactive rebase से कई commits को squash करने पर क्या होता है? यह भी साझा किया गया कि notes का file/directory के "content" से जुड़ना अपेक्षा से अलग लगता है। उदाहरण के लिए, अगर "Hello world!" string वाले blob पर note लगाया जाए, तो क्या वही note उसी content वाले सभी files पर लगेगा? और file बदलने पर क्या notes खो जाएंगे?

  • बताया गया कि git rebase आदि में notes की copying को default रूप से copy होने के लिए configure किया जा सकता है; git-config(1) में notes.rewrite option देखें।

• मौजूदा कार्यस्थल पर git notes का सक्रिय उपयोग किया जा रहा है। उद्देश्य है internal code review के रिकॉर्ड्स को commit messages को जटिल बनाए बिना या हर बदलाव के लिए PR बनाए बिना संभालना। हर commit किस ticket से mapped है, कौन-सी infra constraints थीं, fix होने की स्थिति में incident thread का link क्या है—ऐसा context branch में छोड़ा जाता है। यह जानकारी repo में रखने से slack या jira खोजे बिना यह समझना आसान हो जाता है कि कोई line क्यों बदली गई। बड़े पैमाने पर इसका उपयोग platform UI की ज़रूरत को सचमुच कम कर सकता है। राय दी गई कि reproducibility सिर्फ build के लिए नहीं, बल्कि ‘intent’ के लिए भी ज़रूरी है।

  • पूछा गया कि क्या ऐसी जानकारी commit message में होना बेहतर नहीं होगा, या फिर उद्देश्य “इस commit ने bug #123 पैदा किया” जैसी भविष्य-दिशा वाली जानकारी तक link करना है?

• राय दी गई कि git notes वास्तव में तभी उपयोगी हैं जब commit के बाद अतिरिक्त जानकारी की ज़रूरत पड़े। Acked-By, mailing list discussion link जैसी चीज़ें तो commit के समय ही ज्ञात होती हैं, इसलिए उन्हें commit message में जोड़ देना चाहिए। बल्कि git note का असली फायदा बाद में reverted commits जैसी चीज़ों पर अतिरिक्त स्पष्टीकरण जोड़ने में है।

  • अक्सर commit message दावा करता है कि bug fix हो गया, जबकि वास्तव में नहीं हुआ होता। इससे एक के बाद एक bug पैदा होते हैं, और सहकर्मी मूल intent को नज़रअंदाज़ करके बस आगे बढ़ जाते हैं। नाराज़ ग्राहकों और bug के दोबारा लौटने के अनुभव के बाद bug fix के मामले में अधिक सावधान रहने की ज़रूरत महसूस हुई। कभी-कभी एक साथ कई bugs ठीक होते हैं, या refactor से performance improvement और नए features के अवसर भी खुलते हैं।

  • Acked-By, reviews, discussions तो स्वाभाविक रूप से commit के बाद भी जारी रह सकते हैं; commit के समय वे पहले से ज्ञात नहीं होते। revert किए गए commit के मामले में, उल्टा commit message में जोड़ना अधिक उपयोगी हो सकता है, क्योंकि blame फीचर सबसे हाल का बदलाव दिखाता है और इस तरह reverted commit का trace भी स्वाभाविक रूप से मिलता है।

  • commit के बाद भी discussions लंबे समय तक चलती रहती हैं।

• यह भी कहा गया कि code agents को अतिरिक्त context देने के उद्देश्य से notes फीचर को explore करना एक दिलचस्प दिशा हो सकती है।

• इसे ज्ञान की कमी नहीं, बल्कि UI समस्या बताया गया—अगर GitHub UI notes को अच्छी तरह दिखाए, तो लोग तुरंत इसका अधिक उपयोग करने लगेंगे।

  • GitHub में notes support आने की इच्छा जताई गई।

• कहा गया कि git में bisect, pickaxe, reflog, range-diff, archive, annotated tags जैसी कई ‘सबसे शानदार लेकिन कम पसंद की जाने वाली’ features हैं, लेकिन ज़्यादातर लोग git को सिर्फ google drive की तरह समझते हैं, इसलिए उनका उपयोग नहीं करते।

  • जवाब में कहा गया कि git notes फिर भी कुछ हद तक duplicate लगते हैं, क्योंकि feature, roadmap जैसे non-technical context को अलग project management tools (जैसे Jira) में track किया ही जाता है; Unix philosophy के अनुसार हर tool को अपनी भूमिका पर केंद्रित रहना चाहिए।

  • pickaxe का नाम पहली बार सुना गया, और यह अप्रत्याशित लगा; लगा कि ज़्यादा आत्मविश्वासी नहीं होना चाहिए।

  • यह नज़रिया भी रखा गया कि ऐसे सजावटी फीचर्स अक्सर उतने उपयोगी नहीं होते; वे मूल बात के आसपास की सहायक तरकीबें भर हैं।

• राय दी गई कि git notes वास्तव में कोई ‘शानदार’ unloved feature नहीं, बल्कि सिर्फ कुछ बहुत सीमित स्थितियों में काम आने वाली चीज़ है। वास्तव में ज़रूरी जानकारी अगर commit message में रखी जाए और दूसरे systems (जैसे JIRA) से refer की जाए, तो वही पैटर्न अधिक उपयोगी है। JIRA जैसे systems non-developer stakeholders—जैसे business analysts या support staff—के साथ संवाद का माध्यम होते हैं। यह भी तर्क दिया गया कि non-developers के पास repo और code access न होना कई बार उचित होता है। कई services/repos को एक साथ संभालने वाली परिस्थितियों में notes जैसी चीज़ों से feature references संभालना व्यावहारिक नहीं; external systems के साथ integration ज़रूरी है।

  • इस पर कहा गया कि business analysts का code या repo access न होना ही अक्षम है; कई बार सिर्फ code की एक line देखकर बात समझी जा सकती है, लेकिन हर बार सवालों का जवाब देना पड़ता है। यह भी माना गया कि तकनीकी क्षमता वाले analysts मौजूद होते हैं, लेकिन संस्कृति को बदलना आसान नहीं।

• man page के ज़रिए 2020 के आसपास पहली बार notes के बारे में पता चला। मूल रूप से notes सिर्फ local repo पर लागू होते हैं, इसलिए उनका वास्तविक उपयोग का अनुभव नहीं रहा। team स्तर पर इस्तेमाल करने के लिए pushing/fetching को अलग से configure करना पड़ता है, लेकिन मेरी team ने उसे अपनाया नहीं।