Conventional Commits का इस्तेमाल बंद करें

 (sumnerevans.com)
4 पॉइंट द्वारा GN⁺ 2026-06-06 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Conventional Commits <type>[optional scope]: <description> फ़ॉर्मैट से commit message को अर्थ देने की कोशिश करता है, लेकिन change type को आगे रखकर और scope को optional बनाकर वह वास्तविक खोजबीन के लिए ज़रूरी जानकारी को पीछे धकेल देता है
  • contributor, debugger और incident responder commit log में उस code area को खोजते हैं जिसे बदलाव ने छुआ है; bug किसी भी तरह के change में आ सकता है, इसलिए scope type से ज़्यादा महत्वपूर्ण है
  • fix(compiler): prevent namespaced SVG <style> elements from being stripped जैसे उदाहरण में description से ही bug fix होना स्पष्ट है, और refactor(core): Update webmcp support to use document.modelContext जैसे commit fix, refactor और feature addition—तीनों पर फैल सकते हैं; इसलिए type दोहरावपूर्ण और सीमित है
  • automatic CHANGELOG generation और semantic version bump का निर्णय इस वजह से भटक सकता है कि commit log और changelog के पाठक अलग होते हैं, और revert, accidental breaking changes, या बाद में breakage के समाधान के कारण नतीजे बदल सकते हैं
  • scope prefix commit message बदलाव के विषय को पहले दिखाते हैं, और build/deploy conditions को title type के बजाय git diff में बदली गई files के आधार पर तय करना बेहतर है

गलत प्राथमिकता

  • Conventional Commits का लक्ष्य commit message को अर्थपूर्ण बनाना है ताकि developer और end user बदलावों को समझ सकें
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
  • title line fix, feat, chore, docs, refactor जैसे <type>, optional scope, और description से बनती है
  • इसकी मूल खामी यह है कि यह change के subject यानी scope की तुलना में change category यानी type को प्राथमिकता देता है
  • scope को optional रखने से commit की सबसे महत्वपूर्ण जानकारी छूट सकती है, और type को title की शुरुआत में रखकर प्राथमिकता उलट दी जाती है

scope, type से ज़्यादा महत्वपूर्ण क्यों है

  • contributor commit log इसलिए पढ़ते हैं कि वे अपनी पिछली contribution के बाद हुए बदलाव, project के overall flow, और pull या rebase के दौरान ongoing work से टकरा सकने वाले commits को ढूंढ सकें
  • debugger उस बदलाव को खोजते हैं जिसने उस area को छुआ हो जो सामने आए bug वाले component से जुड़ा है; bug किसी भी type के change से आ सकता है, इसलिए type की जानकारी मददगार नहीं होती
  • incident responder outage के आसपास के commit log को स्कैन करके समस्या पैदा करने वाले area को ढूंढते हैं; inbound API errors में अचानक उछाल के समय auth scope वाला commit एक मजबूत कारण-उम्मीदवार बन जाता है
  • commit log पढ़ने वाले व्यक्ति के लिए अहम बात यह नहीं है कि बदलाव किस प्रकार का था, बल्कि यह है कि उसने किस area को प्रभावित किया

type की दोहरावपूर्ण और सीमित प्रकृति

  • fix(compiler): prevent namespaced SVG <style> elements from being stripped में description से ही पता चल जाता है कि यह bug fix है, इसलिए fix type दोहरावपूर्ण है
  • commit title line में जगह सीमित होती है, इसलिए description से समझ आने वाली type जानकारी पर अक्षर खर्च करना उपयोगी नहीं है
  • refactor(core): Update webmcp support to use document.modelContext core component की webmcp feature को update करता है ताकि वह document.modelContext और navigator.modelContext दोनों को support करे
  • इस change को एक साथ bug fix, refactor, और new feature माना जा सकता है, लेकिन वास्तव में महत्वपूर्ण बात यह है कि यह core/webmcp component में बदलाव है

automation के वादे की सीमाएँ

  • git-cliff या conventional-changelog जैसे tools से commits से automatic CHANGELOG बनाना इस समस्या से जूझता है कि commit log और changelog के पाठक अलग होते हैं
  • CHANGELOG user के लिए होता है और versions के बीच functional तथा business-level अंतर समझाने पर केंद्रित रहता है
  • commit log developer के लिए होता है और यह समझने पर केंद्रित रहता है कि codebase समय के साथ कैसे बदला और scope के नज़रिए से उसका flow क्या रहा
  • मध्यम या उससे अधिक जटिलता वाले project में एक meaningful feature अक्सर कई commits में आती है; developer के लिए implementation process उपयोगी होता है, लेकिन end user के लिए नई feature ही महत्वपूर्ण होती है
  • revert commit developer के लिए commit log के flow में महत्वपूर्ण होते हैं, लेकिन end user के लिए revert किया गया change ऐसा है मानो वह बना ही नहीं
  • commit type पर आधारित semantic version bump ऐसी समस्याएँ पैदा कर सकता है जहाँ breaking change revert हो जाने के बाद भी major version बढ़ जाए, या breakage बाद में पता चले तो version minor/patch के रूप में गलत बढ़े, या बाद के commits के साथ मिलकर breakage खत्म हो जाए लेकिन फिर भी उसे breaking माना जाए
  • ऐसी स्थिति में rebase से history सुधारी जा सकती है, लेकिन workflow इसे रोक सकता है या तोड़ सकता है, और commit log द्वारा बताए गए flow की विश्वसनीयता घट जाती है
  • अगर build/deploy process commit title type से trigger किया जाए, तो docs: fix typos शीर्षक वाला commit authentication subsystem में vulnerability डालकर automated tools को bypass कर सकता है
  • build/deploy conditions को commit title की बजाय git diff से बदली गई files पहचानकर तय करना बेहतर है

अपनाने की समस्या और विकल्प

  • Conventional Commits projects को अपना type set define करने देता है, लेकिन कई projects commitlint के default types सीधे उठा लेते हैं, जो project-विशेष की जरूरतों से मेल नहीं भी खा सकते
  • Conventional Commits specification तकनीकी रूप से सिर्फ fix और feat को define करती है और बाकी types project पर छोड़ती है
  • enterprise environment में change management और audit requirements के कारण हर commit message में ticket number डालना पड़ सकता है; अगर <scope> उसी ticket number के लिए इस्तेमाल हो जाए तो उपयोगी metadata गायब हो जाता है
  • Linux, FreeBSD, Git, Go, NixOS, Node.js जैसे projects अपने project के अनुसार scope-prefix commit messages इस्तेमाल करते हैं
प्रोजेक्ट फ़ॉर्मैट उदाहरण
Linux subsystem: description i2c: virtio: mark device ready before registering the adapter
FreeBSD prefix: Description linuxulator: Return EINVAL for invalid inotify flags
Git area: description gitlab-ci: update macOS image
Go package: description net/http/cookiejar: add godoc links
nixpkgs pkg-name: description xwayland: 24.1.11 -> 24.1.12
Node.js subsystem: description stream: fast-path stateless transform flush results
  • Linux kernel में subsystem, Go project में package path, और microservice architecture में microservice का नाम स्वाभाविक scope बन जाता है
  • scopedcommits.com commit message में scope-केंद्रित फ़ॉर्मैट की ओर लौटने और CHANGELOG generation को commit log management से अलग करने की दिशा सुझाता है
  • Conventional Commits के कथित फायदे वास्तविक लाभ में नहीं बदले, और open source projects में इसकी लोकप्रियता तथा AI की default पसंद ने anti-pattern मिले-जुले commit messages के प्रसार को बढ़ाया है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2026-06-07
Hacker News की राय

  • लगता है प्रोग्रामर हमेशा tabs बनाम spaces जैसी छोटी-छोटी बातों पर भी सबसे अच्छी setting क्या है, इस पर बहस और शिकायत करते रहते हैं
    इसका मतलब यह नहीं कि Conventional Commits commit messages को व्यवस्थित करने के लिए कोई ईश्वरीय या अंतिम समाधान है, लेकिन मेरा मानना है कि एक तय structure होना और commit messages से जुड़ी अपेक्षाओं को एक जैसा रखना कहीं ज़्यादा प्रभावी और महत्वपूर्ण है
    लेखक इस बात पर बहुत ज़ोर देता है कि scope, type से ज़्यादा महत्वपूर्ण है, लेकिन fix(compiler) और compiler fix के बीच का फर्क जान देने लायक मुद्दा नहीं लगता
    tech industry में बहुत सी चीज़ें ऐसी हैं जो optimal नहीं हैं, फिर भी standard बन चुकी हैं; उदाहरण के लिए, अगर JSON को शुरू से फिर बनाया जाता, तो बहुत से लोग मानते कि उसमें comments, ज़्यादा स्पष्ट number formats वगैरह का support होना चाहिए
    फिर भी वह पहले की चीज़ों से कई संदर्भों में बेहतर था, इसलिए standard बन गया; Conventional Commits से थोड़ा अलग कोई बेहतर format हो सकता है, लेकिन वह commit message structure के लिए एक और प्रतिस्पर्धी तरीका खड़ा करने जितना बेहतर नहीं लगता

    • परिभाषित structure अपने आप में quality नहीं है
      commit message ढीले structure में भी बदलाव की प्रकृति को अच्छी तरह बता सकता है, और इसके उलट बहुत structured होकर भी उलझाऊ या बेकार जानकारी वाला हो सकता है
      कुल मिलाकर मैं लेखक से सहमत हूँ: Conventional Commits, खराब commit messages की मूल समस्या को हल नहीं करता
    • standardization अपने आप में ठीक है, लेकिन उसी तर्क से किसी भी दूसरे दर्जे की यथास्थिति को लगातार सही ठहराया जा सकता है
      XML भी काफ़ी अच्छा है और standard है, SOAP भी काफ़ी अच्छा है और standard है
      बात यह कही जा रही है कि Conventional Commits काफ़ी अच्छे हैं और काफ़ी standardize हो चुके हैं, इसलिए किसी दूसरे structure पर सोचने की ज़रूरत नहीं; लेकिन वह “ज़रूरत” अपने आप में subjective है
      अगर आप रोज़ commits करते हैं और PRs पढ़ते हैं, तो Conventional Commits format से पैदा होने वाली छोटी friction भी जमा हो सकती है; इसे कोई प्राकृतिक नियम मानने के बजाय विकल्प खुले रखना, पसंद करने वाली teams के लिए मददगार हो सकता है
      वैसे भी ज़्यादातर teams changelog generate नहीं करतीं
    • मैं इस बहस में निजी तौर पर ज़्यादा invested नहीं हूँ, लेकिन मूल लेख का rebuttal खोखला लगता है
      scope महत्वपूर्ण है, यह सही है, लेकिन क्या उसे commit content से निकाला नहीं जा सकता?
      diff review करते समय छुए गए paths को देखना एक महत्वपूर्ण sanity check है, और “test” diff को production authentication code नहीं बदलना चाहिए
      फिर भी अगर आप इसे --oneline में देखना चाहते हैं, तो feat(auth): मुझे feat: से बेहतर लगता है
      मैं इस दावे से सहमत नहीं कि target audience ग़लत है
      feat commits को सच में product-level बदलाव समझाना चाहिए, और बेमतलब refactoring changes को पहले साफ़-सुथरे ढंग से जमा करके उसके ऊपर छोटे नए feature changes रखने चाहिए
      diff explanation में डालने के लिए यही सबसे उपयोगी चीज़ है, और “algorithm X क्यों चुना गया” जैसे technical context को खोने से बचाने के लिए comments या DECISIONS.md में रखना चाहिए
      तेज़ी से चलने वाली company में commit history में इस तरह के उबाऊ कामों का ध्यान शायद सिर्फ़ जुनूनी लोग रखें, लेकिन open source projects में commit messages में context छिपाकर रखना कहीं ज़्यादा महत्वपूर्ण लगता है
    • असली बात यह नहीं कि scope, type से ज़्यादा महत्वपूर्ण है, बल्कि यह है कि natural language उन बातों पर ज़ोर दे सकती है जिन्हें आप महत्वपूर्ण मानते हैं, जबकि हर चीज़ को किसी तय format में ठूँस देने से वह जानकारी गायब हो जाती है
      Markdown और plain text जैसे formats मौजूद हैं, सिर्फ़ JSON नहीं, इसके पीछे एक कारण है
    • मुझे Conventional Commits एक अच्छा विचार इसलिए लगता है क्योंकि tools के ज़रिए लोगों को कम से कम commit messages पर थोड़ा-बहुत सोचने के लिए मजबूर किया जा सकता है
      मैंने बहुत ज़्यादा ऐसे commits review किए हैं जिनका शीर्षक small fix था, जबकि असल में वे बिल्कुल छोटे fixes नहीं थे

  • असली निष्कर्ष यह है कि हर project की requirements अलग होती हैं
    30 साल से ज़्यादा source control इस्तेमाल करते हुए, मैंने कभी भी description में component (जिसे लेख में scope कहा गया है) को किसी standardized तरीके से डालना उपयोगी काम नहीं पाया
    सिर्फ़ affected files source tree में कहाँ हैं, यह देखकर भी साफ़ हो जाता है कि कौन-सा component बदला है, और bug, fix, feature भी कोई खास उपयोगी value नहीं जोड़ते
    अगर वह महत्वपूर्ण न होता, तो check-in ही नहीं किया जाता
    मुझे सिर्फ़ एक ही चीज़ उपयोगी लगी है, जिसका लेख में बिल्कुल ज़िक्र नहीं है: संबंधित change request link या ID
    commit में क्या बदला है, इसकी जानकारी पहले से होती है, और जो चीज़ गायब होती है वह है यह संदर्भ कि क्यों बदला गया
    personal projects में भी मैं description के आगे square brackets के अंदर JIRA reference डालता हूँ, और अगर development के दौरान संयोग से कुछ ठीक करने का फैसला किया हो, तब भी एक छोटी 1-line JIRA बनाकर उसकी ID लेता हूँ और उसमें कारण लिखता हूँ

    • “क्यों” वही चीज़ है जो git commit message में होनी चाहिए
      “क्यों” को capture करना ही उस message का पूरा उद्देश्य है, और बाहर किसी ऐसे resource का link जोड़ देना जो कभी भी गायब हो सकता है, उसका अच्छा विकल्प नहीं है
    • JIRA इस्तेमाल करते समय हम भी ऐसा ही करते थे
      GitHub issue हो तो commit से PR discussion तक वापस जाया जा सकता है, और उस PR में linked issue और दूसरे pointers होने चाहिए
      बेशक, GitHub issues पर जाते हुए हमने JIRA लगभग छोड़ दिया था, और कुछ साल बाद instance बंद होकर delete भी हो गया
      अब वे सारे JIRA tags पूरी तरह बेकार हैं
      इसलिए उल्टा मुझे लगता है कि issue tracker और git repository के बीच मज़बूत coupling चाहिए
      असल में जो चाहिए वह portability है, लेकिन मज़बूत coupling के बिना वह कैसे मिलेगी, यह मुझे नहीं पता
      आदर्श रूप से कोई open standard format होना चाहिए, लेकिन व्यवहार में GitHub ही format तय करने वाला विशाल gorilla है, और अगर GitLab जैसे clones GitHub project metadata या कम से कम PR import कर सकें, तो वह व्यावहारिक रूप से उसके काफ़ी करीब होगा
      वैसे भी, 5 साल बाद शायद इस्तेमाल में भी न रहने वाले किसी Atlassian product के लिए fixed immutable pointer छोड़ने वाली policy अच्छी नहीं है
      मैं तो इससे बेहतर यह policy मानूँगा कि git commit पूरी तरह अपने दम पर खड़ा हो और बदलाव के “क्यों” की सारी जानकारी commit message या source comments में समा जानी चाहिए
      हालाँकि मुझे लगता है कि वह भी विफल होता है, क्योंकि लोग git commit में बहुत छोटा लिखते हैं, issue को summarize करते हुए जानकारी खो देते हैं, और PR discussion की आगे-पीछे की बातचीत में बदलाव के कारणों के बारे में किसी एक व्यक्ति की आवाज़ में लिखे summary से ज़्यादा उपयोगी बातें होती हैं
    • release notes का automatic generation करना हो तो यह उपयोगी है
      नई features को पहले और उसके बाद bug fixes को रखा जाए, तो non-technical users के लिए पढ़ना थोड़ा आसान हो जाता है
    • सही बात
      commit messages changelog generation के लिए नहीं, बल्कि future developers के लिए होते हैं
      वह developer commit message मुख्य रूप से तब पढ़ता है जब उसे समझ नहीं आता कि वह commit अस्तित्व में क्यों है
      सवाल यह नहीं होता कि क्या बदला गया, बल्कि यह होता है कि किसी खास line का उद्देश्य क्या है
      इसलिए वह blame चलाकर commit देखता है, मूल developer शायद कंपनी छोड़ चुका होता है, पुराना JIRA भी गायब हो चुका हो सकता है, और एकमात्र सुराग commit message ही होता है
      https://dev.to/splix/the-why-behind-the-code-2bb1
    • अलग source इस्तेमाल करने का फ़ायदा क्या यह है कि उसमें image जैसी चीज़ें डाली जा सकती हैं, या मैं कुछ चूक रहा हूँ?
      context को commit body में डाल देना काफ़ी नहीं है क्या?

  • Conventional Commits इस्तेमाल करने वाले बहुत से लोगों का chore शब्द मुझे हमेशा खटकता रहा है
    निजी तौर पर मैं यहाँ भी सौभाग्य से उल्लेख की गई linux kernel style commit titles को पसंद करता आया हूँ
    [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

    • पूरी तरह सहमत
      chore जो रवैया imply करता है, वह बेहद अप्रिय लगता है
      ऐसा लगता है जैसे बाकी सबको fun या indifferent के रूप में label करना चाहिए, और ऐसे भावनात्मक judgments का commit message में कोई स्थान नहीं है
    • मुझे एक वैकल्पिक शब्द मिला: upkeep
      मतलब वही है, लेकिन उसमें तिरस्कार वाला nuance नहीं है
    • Rich का यह लेख भी आपको पसंद आ सकता है: https://richvdh.org/conventional-commits-considered-harmful....
    • यह सही है कि terminology खराब है
      इसके अलावा यह ऐसा दिखावा भी है जैसे आपको पहले से commit का overall impact पता हो, जबकि असल में पता नहीं होता
      Conventional Commits आ जाने पर team members और LLM दोनों को उस बेवकूफ़ naming scheme को गढ़ने में समय और tokens खर्च करने पड़ते हैं

  • Conventional Commits के बारे में मेरी मुख्य शिकायत यह थी कि commit title में issue number शामिल नहीं होता
    standard document में इसका ज़िक्र optional चीज़ के रूप में भी नहीं है
    मेरे लिए commit message में यह लगभग सबसे महत्वपूर्ण जानकारी होती है
    पिछले 15 सालों में न जाने कितनी बार मैंने पुराने commits द्वारा refer किए गए issue descriptions से मिलान करके बदलाव का पूरा context समझा है
    मुझे लगा था कि यह आदत एक तरह का standard है, लेकिन Conventional Commits के बारे में जानने के बाद ही पता चला कि ऐसा नहीं है
    मुझे बिल्कुल समझ नहीं आया कि यह लोकप्रिय क्यों है

    • निजी तौर पर मैं issue को git trailer के रूप में डालना पसंद करता हूँ
      fix thing in foo

      Issue: ABC-123

Git में ऐसे trailers को parse और format करने के लिए बहुत-सी built-in सुविधाएँ हैं, इसलिए inline देखने या CI में इस्तेमाल करने के लिए custom git log alias आसानी से बनाया जा सकता है

  • अगर आप पहले से ही character limit वाले changelog को देख रहे हैं, तो main commit message में XYZ-999999 होना खास दिलचस्प नहीं लगता
    trailer के रूप में tag करना ठीक है, लेकिन Jira issue number से कहीं ज़्यादा मैं यह देखना चाहूँगा कि commit ने किया क्या है

  • मुझे यह तभी समस्या लगती है जब issue key को title की बिल्कुल शुरुआत में रखना अनिवार्य किया जाए
    वह भी readability के लिए खराब है
    समझ नहीं आता कि उसे Conventional Commits के उस बिखरे हुए format में कहीं जोड़ देना क्यों नहीं चल सकता
    issue key को वैसे भी alphanumeric prefix के बाद आने वाले number जैसे regex से निकाला जा सकना चाहिए, इसलिए ऐसे “standard” के लिए अलग जगह बनाने की ज़रूरत लगभग नहीं है
    व्यक्तिगत रूप से, मैं Conventional Commits के बिना, अगर commit उस issue से संबंधित हो तो अंत में उसे parentheses में डाल देता हूँ
    अगर रिश्ता ज़्यादा मजबूत हो, जैसे issue को fix करना, तो message में Fixes trailer भी जोड़ता हूँ

  • दिलचस्प है
    हम अब तक fix(ABC-123): some message here जैसा लिखते आए हैं, और यह अच्छी तरह link भी हो जाता है और auto release notes में बहुत अच्छा render होता है

  • वह standard नहीं बल्कि convention है
    टीम के भीतर यह standard तय कर लो कि ticket ID को commit message में शामिल करना है

  • अगर आप इसे machine-readable बनाना चाहते हैं, तो footer/trailer का इस्तेमाल कर सकते हैं
    Conventional Commits के बारे में अच्छी बात कहना मुश्किल है
    यह format message के सबसे ज़्यादा पढ़े जाने वाले हिस्से की जगह घेर लेता है, और category या type में जानकारी बहुत कम होती है
    title में सीधे-सादे English verb को एक sentence की तरह लिख देने से वही काम हो जाता है, और :, (), ! जैसे तीन तरह के punctuation की बजाय सामान्य वाक्य कहीं बेहतर पढ़ा जाता है
    title में “area” जैसा कुछ हो तो वह मैं सह सकता हूँ, और वह भी इस convention से पहले से मौजूद था
    काम पर हम non-technical users के लिए web app बनाते हैं, और ऐसे users के लिए changelog को Norwegian में अच्छी तरह लिखा जा सकता है
    commit message का users से कोई लेना-देना नहीं है, और यह माँगना कि हर commit इतना अच्छा हो कि उसे end-user changelog में डाल दिया जाए, हमारे यहाँ फिलहाल होने वाला नहीं है
    इसकी जगह footer/trailer इस्तेमाल किया जा सकता है

  • Conventional Commits सच में जहाँ मददगार है, वह है continuous deployment
    हर बार main में merge होते ही आप अपने-आप SemVer tag लगाकर deploy कर सकते हैं, क्योंकि tagging और versioning के लिए ज़रूरी निर्णय developer commit message लिखते समय पहले ही कर चुका होता है
    Linux kernel जैसे बहुत बड़े project के लिए यह उपयुक्त नहीं है, यह बात मैं पूरी तरह मानता हूँ
    लेकिन 99% projects में Conventional Commits और SemVer को मिलाने से मौजूदा release process की तुलना में बड़ा सुधार होता है और automation आसान हो जाती है

    • continuous deployment के हालात में भी मुझे git tags पर निर्भर रहने वाला तरीका पसंद है
      git describe अक्सर continuous deployment versioning के लिए काफ़ी होता है, और v1.2.3-4-gabcdef किसी commit को Git की नज़र में जितना सटीक चाहिए उतना describe करते हुए SemVer जैसा भी दिखता है, इसलिए expectations सेट हो जाती हैं
      यह खास तौर पर तब सही लगता है जब नए git tags केवल इंसानी निर्णय से जोड़े जाते हों, जैसे यह breaking change है इसलिए अब नया major tag करना चाहिए
      git describe format वाले version number में असली बहस बस इतनी होती है कि SemVer expectations से बेहतर मेल के लिए पहले dash को plus में बदला जाए या नहीं, और अगर package manager में version को सही क्रम में sort कराने जैसी SemVer expectations लागू करने में मूल्य है, तो इसे एक आसान regex से बदला जा सकता है
      git describe CD automation को आसान बनाता है, लेकिन commit history के magic keyword से अनुमान लगाने के बजाय version number तय करने का काम इंसान के पास git tag selection या GitHub Releases के ज़रिए रह सकता है
    • मैं अपने open source project में SemVer bump को automate करने के लिए यही तरीका इस्तेमाल करता हूँ और यह वाकई अच्छा है
      काम पर हम इस बात के अनुसार “tags” भी अनिवार्य करते हैं कि बदलाव में रुचि किसे है
      यहाँ tag का मतलब git tag नहीं बल्कि PR title के भीतर की string है, और उन्हीं “tags” के आधार पर हर team के लिए changelog बनाया जाता है
    • लेख में समझाया गया है कि यह ठीक से क्यों काम नहीं करता
    • लेकिन उसे title में डालना क्यों ज़रूरी है?
      अगर आप versioning का ऐसा अजीब तरीका अपनाना ही चाहते हैं, तो commit body में कोई magic phrase डाल दीजिए
      तब वह एक शब्द तक सीमित भी नहीं रहेगा

  • मुझे इस तरह का title style काफ़ी नापसंद है
    “Stop something” जैसे expression बहुत लोकप्रिय लगते हैं, लेकिन उनका लहजा हुक्म देने वाला होता है और “मैं निश्चित रूप से सही हूँ” जैसा भाव देता है
    समझ नहीं आता कि “In favour of something” या “A case against something” जैसा क्यों नहीं लिखा जाता

    • समझ नहीं आता कि कोई अपनी पसंदीदा स्थिति को साफ़-साफ़ सीधे तौर पर क्यों न रखे
      आपको उस स्थिति से सहमत होने की ज़रूरत नहीं है, लेकिन उसकी भाषा को नरम करने की माँग करना कमज़ोर प्रतिक्रिया है
    • यह considered harmful जितना बुरा नहीं है, लेकिन फिर भी थोड़ा toxic है
      लगता है असल बात यह है कि किसी मनमानी निजी पसंद, जैसे A और B का क्रम बदलना चाहना, को वास्तविकता से ज़्यादा बड़ा दिखाया जाए
    • जब कोई कथन हमारी worldview को चुनौती देता है, तो उसमें दिलचस्पी बढ़ जाती है
      बहुत लोगों को यह असभ्य लगेगा, लेकिन attention economy ऐसे तरीकों को इनाम देती है
      संशोधन: लगता है title को कम उकसाने वाला बना दिया गया है
      यह अच्छा किया
    • मैं भी कुछ ऐसा ही कहने आया था
      मुझे Conventional Commits बहुत पसंद नहीं हैं, लेकिन लोगों को जो चाहिए वह इस्तेमाल करने देना चाहिए
    • https://knowyourmeme.com/memes/stop-doing-math
      इस तरह के title genre के कुछ हिस्सों को प्रभावित करने वाला एक meme है

  • अजीब है
    इस तरह के commit message लिखने की मुख्य वजह CI/CD automation है
    सुधार: पहली बार पढ़ते समय मैं लेख में यह हिस्सा नहीं देख पाया, लेकिन इसमें इसे कवर किया गया था
    माफ़ी
    commit type सबसे आगे आता है क्योंकि वह automated workflow को बताता है कि commit को कैसे प्रोसेस करना है
    उदाहरण के लिए, अगर आप CD करते हैं, तो सिर्फ कई fix: commits होने पर semantic version का केवल patch नंबर बढ़ता है
    feat: commit करने पर minor version बढ़ता है, और feat! major version बढ़ने का संकेत है
    भले ही आप release के लिए CD का उपयोग न करें, semantic commit messages का उपयोग changelog generation को automate करने के लिए भी किया जाता है
    बेशक changelog में आम तौर पर Git commit message को ज्यों का त्यों नहीं डालना चाहिए
    वह message users के लिए नहीं, developers के लिए होता है

    • लेख में इन दोनों बातों को काफ़ी स्पष्ट रूप से कवर किया गया है
      semantic versioning rollback में टूट जाती है, और automated changelog का target audience गलत होता है
    • मैंने इस style को version bump के लिए इस्तेमाल किया है और यह अच्छा लगा, इसलिए चाहता था कि लेख कोई काम करने वाला विकल्प सुझाए
      आजकल मैं SemVer की जगह CalVer इस्तेमाल करता हूँ, इसलिए यह अब समस्या नहीं है, लेकिन smart automatic version bump का विचार मुझे पसंद है
    • तो फिर git trailer में कौन-सी convention इस्तेमाल करनी चाहिए
      commit title में fix या feat होने से log देखने वाले व्यक्ति को कोई उपयोगी जानकारी नहीं मिलती
    • नहीं नहीं
      बात तो यह है कि AI के लिए commit बनाना आसान करने हेतु Conventional Commits को हटाया जाना चाहिए

  • अगर क्रम उलट दिया जाए तो मेरी मुख्य झुंझलाहट वास्तव में दूर हो जाती है
    आखिर feature है क्या?
    refactor(core): Update webmcp support to use document.modelContext

    जैसा लेखक कहता है, fix, improvement और सामान्य cleanup के बीच की सीमाएँ धुंधली हैं, और हर semantic change को अलग commit में बाँटना वैसे भी बाद में squash हो सकता है, इसलिए यह बस ऐसा काम पैदा करता है जिससे किसी को फ़ायदा नहीं होता
    मुझे लगता है Conventional Commits सीधे किसी और समस्या को हल करने के बजाय SemVer automation की कोशिश से पैदा हुआ एक उप-उत्पाद है
    मुझे नहीं लगता कि changelog को वैसे भी automate करना चाहिए
    अगर सूची चाहिए तो git log देख सकते हैं
    changelog व्यापक पाठक-वर्ग को यह बताने का मौका है कि अंदर वास्तव में क्या हुआ

  • “changelog का पाठक commit log के पाठक से पूरी तरह अलग होता है”
    “changelog users के लिए होता है”

    लगता है वह जहाज़ तो पहले ही निकल चुका है
    ज़्यादातर कंपनियाँ “Bug Fixes & Performance Improvements” पर ही संतुष्ट हैं
    कम से कम अगर वे मेहनत नहीं करने वाले हैं, तो generated changelog, बिना changelog के होने से बेहतर है

    • हर हफ़्ते update होने वाले auto-update software में मैंने जो सबसे अच्छा तरीका इस्तेमाल किया, वह था user-visible commits के आगे uv: लगाना
      फिर हर हफ़्ते मैं उन्हें खोजकर वही text इस्तेमाल करता था या थोड़ा-सा संपादित कर देता था
      इसे product के Help/Release-notes menu में भी डालता था
      किसी को यह कहना कि वह वह काम करना बंद करे जो मैं न सिर्फ करता हूँ बल्कि जिसके बारे में सुन भी चुका हूँ, थोड़ा मज़ेदार है
      आम तौर पर special prefix सिर्फ database schema migration या दूसरी महत्वपूर्ण चीज़ों के लिए लगाया जाता है
    • वह changelog और release notes को गड़बड़ा रहा है
      लगता है वह commit names भी ठीक से नहीं रख पाता, शायद symbol names भी नहीं रख पाएगा
      यह skill की समस्या है, और वह इस पर सार्वजनिक रूप से दुखी हो रहा है, इसलिए इसे नज़रअंदाज़ किया जा सकता है
 
GN⁺ 2026-06-06
Lobste.rs की राय

  • conventional commits के खिलाफ सिर्फ सहज नापसंदगी नहीं बल्कि तर्क के साथ बात रखने वाला लेख देखकर अच्छा लगा
    मुझे क्यों नापसंद है, इस पर मैंने गहराई से नहीं सोचा था, और शायद इसे LLM द्वारा जनरेट किए गए code से जोड़कर देखने लगा था। खासकर chore: सबसे बुरा लगता है; काश Hungarian notation को फिर से ईजाद न किया जाता। इसे शुरुआत में बनना ही नहीं चाहिए था

    • खासकर chore: अब Angular commit style guide में भी नहीं है, और शायद उन्हें समझ आ गया कि यह बहुत अस्पष्ट है, इसलिए इसे build: में समाहित कर दिया गया
      Angular style में रहने के दौर में भी chore: का विवरण काफी विशिष्ट उपयोग बताता था, लेकिन कुछ open source projects में इसे सचमुच ऐसे कामों पर माहौल के हिसाब से चिपका दिया जाता है जो बस करने में उबाऊ लगते हैं

  • मुझे conventional commits पसंद नहीं हैं, लेकिन प्रस्तावित विकल्प scope के वैकल्पिक होने की वजह को छोड़ देता है
    जिन छोटे projects में स्पष्ट modules ज़्यादा नहीं होते, वहाँ “scope” की अवधारणा बहुत उपयोगी नहीं होती। एक उपयोगी प्रथा जो दोनों से छूट गई है, वह यह है कि commit title में issue या ticket number डालने से बदलाव का अतिरिक्त संदर्भ समझना आसान हो जाता है, और code review के समय यह खास तौर पर मददगार होता है। लेकिन ticket number को अनिवार्य बनाना मुझे पसंद नहीं, क्योंकि तब मामूली बदलावों के लिए भी बेकार tickets की बाढ़ आ जाती है; हाँ, अगर बदलाव किसी खास bug या task को संभाल रहा है, तो उसका उस bug या task से जुड़ना चाहिए

    • अगर scope की ज़रूरत नहीं है, तो बस उसे छोड़ दीजिए
      title line देखकर ही साफ दिखने वाले दोहराव वाले commit “type” से यह अब भी बेहतर है
    • आदर्श रूप में, मेरा मानना है कि किसी निर्धारित commit style की ज़रूरत ही नहीं होनी चाहिए; जो अभिव्यक्ति उस खास commit पर फिट बैठे, वही इस्तेमाल हो
      अगर बदलाव किसी ticket से साफ़-साफ़ मेल खाता है, तो “ticket number” commit इस्तेमाल करें, नहीं तो कोई और तरीका। कुछ बदलाव type में अच्छे से फिट बैठते हैं लेकिन scope में कम, और कुछ इसके उलट, इसलिए scoped commits और conventional commits को मिलाकर भी इस्तेमाल किया जा सकता है

  • मैं कहना चाहूँगा, “अनुच्छेद के टेक्स्ट में monospace font मत इस्तेमाल करो”
    फिर भी, लेख की मूल धारणा से मैं अधिकतर सहमत हूँ

  • commit message अच्छे न भी हों, तब भी बदलाव का दायरा समझने के लिए git log --name-only या git log --stat को अक्सर इस्तेमाल करने की सलाह दूँगा
    filenames देखकर, हर commit को खोलकर देखे बिना भी क्या बदला है इसका अच्छा अंदाज़ा लग जाता है

  • जो तरीका मुझे सच में पसंद है, वह है PR title पर conventional commit style लागू करना
    PR title को merge के बाद भी maintainer बदल सकता है, commit history को दोबारा लिखने की ज़रूरत नहीं पड़ती, और release-drafter जैसे tools के साथ इस्तेमाल करने पर GitHub releases में अर्थपूर्ण changelog को automate किया जा सकता है। यह लेखक द्वारा बताए गए stakeholders के हिसाब से सही granularity देता है, यानी feature·fix·breaking change को अलग-अलग दिखाता है, और अगली GitHub release draft के लिए उचित semver भी अपने-आप संभाल लेता है
    लेख में यह बात सही कही गई है कि parse-lib जैसे component को वैकल्पिक नहीं होना चाहिए, और मैं इस बात से भी सहमत हूँ कि conventional commits को लागू करने से नए contributors हतोत्साहित हो सकते हैं। लेकिन विकल्प भी कोई खास बेहतर नहीं लगते
    फिर भी, breaking change identifier fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays काफी जानकारी देता है। यह किसी खास component की bug fix है, उस fix के साथ अपरिहार्य रूप से आया breaking change है, और minor semver bump जैसी बात भी संकेत करता है। ऐसी चीज़ PR title में इस्तेमाल की जा सकती है

  • मैं मानता हूँ कि commit discipline को बढ़ावा देने के तरीके के रूप में मैं conventional commits में कुछ ज़्यादा ही उलझ गया था, और अंततः यह आदत बन गई
    अब यह मुझे अक्सर सीमित और मनमाना लगता है। कुछ projects में मुझे यह भी नहीं पता कि यह सच में प्रचलित तरीका है या नहीं, और मैं Linux/Go/Node style के ज्यादा करीब आ गया, जबकि अलग-अलग configuration वाले monorepo में type को जबरन गढ़ने से बेहतर [service]: [what changed] लिखना ज़्यादा स्वाभाविक लगा। आगे मैं सख्त परंपरा में फिट होने की जगह इस आधार पर अपने निजी commit style के साथ ज़्यादा प्रयोग करना चाहता हूँ कि क्या उपयोगी लगता है, और scoped commits एक अच्छी शुरुआत जैसे लगते हैं

  • chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
    लगभग सब बातों से सहमत हूँ, लेकिन “contributors को ऐसा revisionist history दिखाना जो commit log की बताई कहानी की विश्वसनीयता घटा देता है” वाले हिस्से पर मेरी एक अलग राय है। लेखक शायद मुख्य रूप से public branches की बात कर रहा है, और public branch के लिए यह वाजिब सलाह है। लेकिन private branches पर यह लागू नहीं होना चाहिए। अंतिम बदलाव की समीक्षा करने वाले, यानी maintainer या 10 साल बाद वाला मैं, उनके लिए चीज़ें समझना आसान बनाना काफी है; उलझी हुई सोच की पूरी धारा या उससे भी बुरा address review commits का ढेर छोड़ने की ज़रूरत नहीं है

  • “scope वैकल्पिक क्यों है?” इसका जवाब छोटे projects में बस यह है कि पूरा project ही scope होता है
    मैं इस बात से सहमत हूँ कि commit का “type” इतना उपयोगी नहीं है, लेकिन scoped commits और conventional commits के बीच बहुत बड़ा अंतर भी मुझे नहीं दिखता। scoped, बस “type” हटाया हुआ conventional ही है, और fix·feat·refactor·chore जैसी श्रेणियाँ होना कोई बुरी बात नहीं है
    अगर सब लोग commitlint के default values ज्यों-का-त्यों उठा रहे हैं, तो क्या बस लोगों को उसे बेहतर तरीके से संभालना नहीं सिखाया जाना चाहिए?