अगर AI कोड लिखता है, तो क्या सेशन भी commit का हिस्सा होना चाहिए?
(github.com/mandel-macaque)- git-memento एक एक्सटेंशन टूल है जो AI द्वारा बनाए गए कोड सेशन को अपने-आप Git commit में रिकॉर्ड करता है, और हर commit से जुड़े AI बातचीत के इतिहास को git notes के रूप में सहेजता है
- commit करते समय AI session ID देने पर, सारांश
refs/notes/commitsमें और पूरी बातचीतrefs/notes/memento-full-auditमें अलग-अलग सहेजी जाती है, जिससे traceability और privacy दोनों सुनिश्चित होते हैं - यह Codex और Claude जैसे कई AI providers को सपोर्ट करता है, और summary बनाते समय user-defined skills लागू कर commit notes की गुणवत्ता नियंत्रित की जा सकती है
- GitHub Actions के साथ इंटीग्रेशन के जरिए commit notes पर automatic comments, CI gate validation, और merge के समय notes का automatic transfer (merge-carry) जैसी सुविधाएँ मिलती हैं
- Windows/Mac/Linux सपोर्ट. यह AI code generation की transparency बढ़ाने और collaborative environment में AI contributions की auditability सुनिश्चित करने वाला टूल है
git-memento का अवलोकन
git-mementoएक Git एक्सटेंशन टूल है जो AI coding sessions को commit स्तर पर रिकॉर्ड करता है- commit के समय AI session की बातचीत को व्यवस्थित करके Markdown notes के रूप में सहेजता है
- हर commit में AI session का source और conversation context छोड़ता है, जिससे code generation process को ट्रैक किया जा सकता है
- यह डिफ़ॉल्ट रूप से Codex को सपोर्ट करता है, और Claude जैसे अन्य AI models भी कॉन्फ़िगर किए जा सकते हैं
- यह MIT लाइसेंस के तहत उपलब्ध है और NativeAOT आधारित single executable के रूप में वितरित किया जाता है
मुख्य कमांड और फ़ीचर
git memento initसे repository-स्तरीय configuration initialize किया जाता है, और AI provider की जानकारी.git/configमें सहेजी जाती हैgit memento commitकमांड से commit के साथ-साथ session notes भी जोड़े जाते हैं--summary-skillविकल्प का उपयोग करने पर summary और पूरा session अलग-अलग सहेजा जाता है- summary
refs/notes/commitsमें और पूरा logrefs/notes/memento-full-auditमें रिकॉर्ड होता है
git memento amendसे मौजूदा commit में नया session जोड़ा या संशोधित किया जा सकता हैgit memento auditcommit range के भीतर missing notes और metadata validity की जाँच करता हैgit memento doctorconfiguration, note references, और remote sync status की जाँच करता है
notes प्रबंधन और synchronization
git memento share-notesसे notes को remote repository (originआदि) में push किया जाता हैgit memento notes-syncremote notes को सुरक्षित रूप से merge करता है और backup बनाता हैrefs/notes/commitsऔरrefs/notes/memento-full-auditदोनों sync होते हैं
git memento notes-carryrebase या squash के बाद notes को नए commit में ट्रांसफ़र करता हैgit memento notes-rewrite-setupautomatic note transfer configuration को सक्रिय करता है
GitHub Actions इंटीग्रेशन
- repository में reusable GitHub Action शामिल है
mode: comment— commit notes पढ़कर automatic comments बनाता हैmode: gate— CI चरण में missing notes की जाँच, और असफल होने पर build रोक देता हैmode: merge-carry— PR merge के समय notes को merge commit में ट्रांसफ़र करता है
- हर mode
action.ymlमें परिभाषित है, और Marketplace registration artifact (dist/note-comment-renderer.js) भी शामिल है ignore-notesलेबल वाले PR gate check को छोड़ देते हैं और “Notes ignored” comment छोड़ते हैं
notes फ़ॉर्मैट और version management
- notes को
git notes add -f -m ""फ़ॉर्मैट में सहेजा जाता है - multi-session support के लिए version tags(``) और section separators का उपयोग होता है
- user messages को Git username से, और AI responses को provider name से label किया जाता है
- पुराने single-session notes ज़रूरत पड़ने पर अपने-आप upgrade हो जाते हैं, जिससे compatibility बनी रहती है
4 टिप्पणियां
Private project में मैं session export करके commit करता हूँ, और public में अगर लगे कि summary file सच में ज़रूरी है, तभी commit करता हूँ.
आख़िर personal information भी होती है.. और tool के हिसाब से अलग होता है, लेकिन हर session आसानी से 10MB से ऊपर चला जाता है.. तो ऐसे ही बस upload कर देना थोड़ा ठीक नहीं लगता.
लेकिन हम ऐसे दौर में जी रहे हैं जहाँ डिस्क पहले से कहीं ज़्यादा सस्ती हैं!
Hacker News की राय
मैं AI के साथ कोड लिखते समय project.md फ़ाइल से शुरुआत करता हूँ
उसमें मैं मनचाहा परिणाम लिखता हूँ, और AI से उसी के आधार पर plan.md लिखवाता हूँ
उसके बाद plan.md को कई बार संशोधित करता हूँ, और जब मनचाही योजना तैयार हो जाती है, तो एक विस्तृत todo list बनाकर plan.md के अंत में जोड़ देता हूँ
जब मैं पूरी तरह संतुष्ट हो जाता हूँ, तो AI को todo पूरा करने के लिए कहता हूँ, और उसे निर्देश देता हूँ कि बीच में कुछ पूछे बिना अंत तक काम पूरा करे
आखिर में project.md, plan.md, और पूरा कोड commit कर देता हूँ
इससे plan.md एक तरह का पुनरुत्पादित किया जा सकने वाला artifact बन जाता है, जिसे बाद में कोई अधिक उन्नत मॉडल आधार बनाकर संशोधित कर सकता है या उसमें त्रुटियाँ खोज सकता है
design को feature unit के हिसाब से लिखता हूँ, और अनसुलझे सवालों को साफ़ दर्ज करता हूँ
plan को
plan/[feature]/phase-N-[description].mdसंरचना में रखता हूँ, और build या runtime limits से टकराने पर रुक जाता हूँdebug चरण में संभावित कारणों के hypothesis बनाता हूँ, उन्हें logging/tracing से सत्यापित करता हूँ, फिर fix करता हूँ
इस तरीके से नए प्रोजेक्ट और legacy दोनों में लगभग 100% success rate मिला है
कमी बस यह है कि markdown फ़ाइलें बहुत ज़्यादा जमा हो जाती हैं, लेकिन पुराने रिकॉर्ड भविष्य के बदलावों में काम आते हैं, इसलिए अभी तक इसे automate नहीं किया है
GitHub spec-kit देखना उपयोगी हो सकता है
मॉडल से market research और proposal review बार-बार करवाते हुए, मॉडल के लिए खुद समझ आने वाली भाषा में prompt design हो जाता है
हाल में पता चला कि XML Claude के व्यवहार को प्रभावित करता है, इसलिए GuardRails की संरचना पर फिर से सोच रहा हूँ
परिचय लेख लिंक
plan पूरा होने पर “context.md” बनाता हूँ, ताकि बाद में किसी गलत plan को rollback करते समय उसे देख सकूँ
अभी तक असल में उसकी ज़रूरत नहीं पड़ी, लेकिन अवधारणात्मक रूप से उपयोगी लगता है
बस यह तय करना मुश्किल है कि ऐसी फ़ाइलें कहाँ रखी जाएँ, इसलिए अभी repo में शामिल नहीं करता
वैसे जानना चाहूँगा कि लोग ऐसे काम-वार md फ़ाइलें कहाँ स्टोर करते हैं
मेरी नज़र में यह “क्या हर line को commit करना चाहिए?” जैसे सवाल जैसा है
आखिरकार असली बात यह है कि यह रिकॉर्ड किसके लिए है
ज़्यादातर sessions में बहुत शोर होता है, गलत कोशिशें होती हैं, और अनावश्यक जानकारी भी बहुत होती है
अहम चीज़ session का output है, उसका पूरा process नहीं
फिर भी शुरुआती spec या पहला prompt काफ़ी मूल्यवान हो सकता है। उसका सार commit message या markdown फ़ाइल में छोड़ना अच्छा है
पुराने sessions को learning context बनाकर मौजूदा काम आगे बढ़ाया जा सकता है
खासकर मॉडल की सीमाएँ समझने और यह पहचानने में मदद मिल सकती है कि कोड कहाँ user intent से भटक गया
अंततः मुझे लगता है कि सभी मानवीय inputs का रिकॉर्ड open source models के विकास के लिए महत्वपूर्ण है
शुरुआती conditions और noise के बावजूद वही परिणाम आना चाहिए
वरना भविष्य का code maintenance इरादे का अंदाज़ा लगाने का खेल बन जाएगा
संबंधित लेख
मैंने एक हफ़्ते पहले ऐसा ही एक विचार सुझाया था (लिंक)
लेकिन विरोधी राय भी बहुत थीं — AI projects किसी एक input से नहीं बनते, बल्कि वे conversational process होते हैं, इसलिए उन्हें source code की तरह artifact में बदलना कठिन है
फिर भी Show HN में आने वाले generated projects इतने ज़्यादा हो गए हैं कि noise गंभीर हो गया है
उन्हें पूरी तरह बाहर तो नहीं किया जा सकता, लेकिन अभी की स्थिति में रुचि कम हो रही है
सोच रहा हूँ कि community को इस समस्या से कैसे निपटना चाहिए
research.md और plan.md को commit करके architecture और features के living dictionary की तरह इस्तेमाल करता हूँ
feature नाम को filename के prefix के रूप में जोड़ता हूँ, ताकि Claude जल्दी से संबंधित design उठा सके
संदर्भ ब्लॉग
जो projects पहले दिलचस्प लगते थे, अब बहुत आसानी से बन जाते हैं
लोगों से लंबे session logs पढ़वाना इसका हल नहीं है। अब सार निकालने की क्षमता और planning ज़्यादा महत्वपूर्ण हो गई है
vibe coding की असली value कोशिश और नाकामी की प्रक्रिया देखने में है
सिर्फ़ output दिखाने से ज़्यादा दिलचस्प तब होता है जब बनाने की प्रक्रिया और व्याख्या भी साथ हो
इसलिए [Show HN] के अलावा [Creations] जैसी कोई category होनी चाहिए
उदाहरण: साधारण chess engine [Creations] में, लेकिन 1k में बना chess engine [Show HN] में
PerfBoard और Lerc इसके उदाहरण हैं
sessions सिर्फ़ intermediate artifacts हैं, अंतिम परिणाम का हिस्सा होना ज़रूरी नहीं
अगर code बदलाव का कारण महत्वपूर्ण है, तो उसे commit message या documentation में दर्ज करना चाहिए
commit के समय यह पता नहीं होता कि भविष्य का पाठक कौन-सा सवाल पूछेगा
इसलिए मैं session को save करके बाद में सवालों के आधार पर summary generate करने का तरीका पसंद करता हूँ
Git AI यही approach इस्तेमाल करता है
आजकल engineers इतनी तेज़ी से काम करते हैं कि एक हफ़्ते बाद ही भूल जाते हैं कि ऐसा क्यों किया था
research-type prompts का सार होना चाहिए, और code-generation prompts को ज्यों का त्यों रखना बेहतर है
तभी reproducibility और reviewability सुनिश्चित हो पाएगी
क्योंकि plan में error-fixing process भी परिलक्षित हो जाती है, और अगली iteration में वह उपयोगी दस्तावेज़ बन जाती है
हर repo एक-दूसरे को messages भेजते हुए feature requests संभालता है
मूल बातचीत और semantic रूप से compress की गई memory को साथ रखकर, specs और requirements को फिर से व्यवस्थित किया जाता है
session logs ज़्यादातर noise होते हैं
वे गलत कोशिशों और rollback का सिलसिला होते हैं, इसलिए उन्हें commit के साथ रखना browser history सहेजने जैसा है
असली महत्व इरादा और constraints बताने वाले commit message का है
अगर AI ने code लिखा है, तो अहम बात बातचीत नहीं बल्कि आपने उससे ऐसा क्यों कहा है
आखिरकार समस्या session save करने से ज़्यादा, commit messages को हल्के में लेने की आदत हो सकती है
मैं AI का उपयोग करते हुए भी पारंपरिक design process बनाए रखता हूँ
requirements → use cases → class design → constraints definition → AI execution
इससे इंसान की architectural judgment बनी रहती है, और AI repetitive implementation को तेज़ करता है
session logs की जगह ऐसे UML/constraint documents को commit में शामिल किया जाए, तो इरादा और context साफ़ तौर पर बचा रहता है
मुझे लगता है 2026 का developer इसी तरह की गरिमापूर्ण collaboration structure को बनाए रखे
यह कुछ-कुछ commit को squash करना है या नहीं जैसी बहस है
अगर आप squash पसंद करते हैं, तो परिणाम महत्वपूर्ण है और process नहीं बचता
अगर नहीं, तो पूरी यात्रा दर्ज होती है
AI sessions के साथ भी यही बात है; सोच की प्रक्रिया को debug करने में वे उपयोगी हो सकते हैं, लेकिन साफ़-सुथरी history पसंद करने वाले लोगों को वे ज़रूरी नहीं लगेंगे
व्यावहारिक रूप से sessions को repo के बाहर अलग से संभालना बेहतर है
सुना है Mercurial या Fossil में यह बेहतर तरीके से संभव है
vibe-coding में code से ज़्यादा prompts सोच के निशान दिखाते हैं
उन्हें git में डालना या नहीं, वह अलग सवाल है, लेकिन उन्हें सुलभ रखना मूल्यवान है
ऐसे में real-time process देखने की ज़रूरत नहीं
लेकिन अगर code पूरी तरह AI ने लिखा है, तो prompts को सार्वजनिक करना चाहिए
मैंने भी sessions निकालकर देखे हैं
कुछ information loss का जोखिम है, लेकिन readability और accessibility काफ़ी बेहतर हो जाती है
कम से कम session के summary किए गए prompts तो save करने चाहिए, ऐसा मेरा मानना है
AI code review इंसानों की तुलना में कम सख़्त होता है, और इरादा सिर्फ़ prompts में ही मौजूद होता है
वरना वही गलतियाँ बार-बार दोहराई जाएँगी
code review का मूल्य सीखने और सुधार में है, लेकिन AI सीखता नहीं, इसलिए prompt records को वह भूमिका निभानी चाहिए
साथ ही यह prompt skill के मूल्यांकन या junior training के लिए भी ज़रूरी है
हम key inputs, menu clicks, debugging attempts जैसी चीज़ें commit में शामिल नहीं करते
सारी बातचीत save करेंगे तो noise बहुत ज़्यादा होगा
इसलिए इरादे और assumptions वाले दस्तावेज़ तक सीमित रहना ही व्यावहारिक है
यह वैसा ही सवाल है जैसे “क्या Google search history को commits में शामिल करना चाहिए?” — मेरे हिसाब से बिल्कुल नहीं
इसकी बजाय कारण, assumptions, और alternatives का सार बचाकर रखना बेहतर है
उसी तरह, model ने छोटी-मोटी समस्या में कितना भटका, उसके logs भी अनावश्यक हैं
यह टिप्पणी अच्छी लगी