Git कमिट मेसेज सर्वोत्तम कसा लिहावा

एक वर्षाहून जुन्या असलेल्या कोणत्याही प्रोजेक्टवर git log चालवा आणि तुम्हाला एखाद्या टीमबद्दलचे सत्य सापडेल. निम्मे मेसेज म्हणतात “fix”, “update”, “wip”, “asdf”, किंवा माझे वैयक्तिक आवडते — “stuff”. आणि मग एक दिवस प्रोडक्शन बिघडते, तुम्ही त्या त्रासदायक ओळीवर git blame चालवता, आणि ज्या कमिटने ती ओळ आणली त्यात फक्त “minor changes” असे लिहिलेले असते. छान. खूपच उपयुक्त. धन्यवाद, भूतकाळातील मी.

मी एका दशकाहून अधिक काळ कोड लिहीत आलो आहे आणि मी प्रामाणिक राहतो: पहिल्या काही वर्षांत माझे कमिट मेसेज कचरा होते. जोपर्यंत मला दुसऱ्याच्या सहा महिने जुन्या कोडचे डीबगिंग करावे लागले नाही (आणि मग लक्षात आले की तो दुसरा कोणी नसून मीच होतो), तोपर्यंत मला हे उमजले नाही. एखादा diff तुम्हाला सांगतो की काय बदलले. फक्त कमिट मेसेज तुम्हाला सांगू शकतो की का. हाच तर खरा खेळ आहे.

त्रास का घ्यावा? तरीही कोणी ते वाचत नाही

हे खोटे आपण स्वतःला सांगतो. लोक कमिट मेसेज नक्कीच वाचतात — फक्त तुम्ही ते लिहिता त्या क्षणी नाही. ते नंतर वाचतात, दबावाखाली, जेव्हा काहीतरी आगीच्या भक्ष्यस्थानी पडलेले असते.

इथे चांगला मेसेज खरोखरच आपली किंमत वसूल करतो:

git blame — कोणीतरी कोडच्या एखाद्या विचित्र ओळीकडे बोट दाखवतो आणि कमिट त्यामागचे कारण समजावतो, जेणेकरून तुम्ही एखादा हेतुपुरस्सर केलेला उपाय “फिक्स” करत नाही.
ऑनबोर्डिंगच्या वेळी git log — एखादा नवीन डेव्हलपर इतिहास वाचतो जेणेकरून एखादे फीचर कसे विकसित झाले हे समजते.
git bisect — जेव्हा तुम्ही एखाद्या रिग्रेशनचा शोध घेत असता, तेव्हा लहान, चांगल्या प्रकारे वर्णन केलेल्या कमिट्समुळे तुम्हाला तासांऐवजी काही मिनिटांत दोषी सापडतो.
git revert — जेव्हा तुम्हाला एखादा बदल इतर असंबंधित गोष्टी न ओढता स्वच्छपणे रद्द करायचा असतो.
रिलीझ नोट्स आणि चेंजलॉग्ज — हे आता वाढत्या प्रमाणात थेट कमिट्समधून स्वयंचलितपणे तयार केले जातात.

एखादा diff तुम्हाला काय दाखवतो. कमिट मेसेज हे एकमेव ठिकाण आहे जिथे का टिकून राहते [1]. कोड स्वतःचे स्पष्टीकरण देऊ शकतो; हेतू देऊ शकत नाही. आजपासून सहा महिन्यांनंतर कोणालाही आठवत नाही की तुम्ही तो रिट्राय लूप काढून टाकलात कारण अपस्ट्रीम API ग्राहकांकडून दुप्पट शुल्क आकारू लागले होते. जोपर्यंत तुम्ही ते लिहून ठेवले नाही.

तर नाही, ही नोकरशाही नाही. हे त्या व्यक्तीसाठी ब्रेडक्रम्सचा माग सोडणे आहे ज्याला हे मेन्टेन करावे लागणार आहे — जो, सांख्यिकीयदृष्ट्या, तुम्हीच असणार आहात.

प्रत्येकजण उद्धृत करतो (आणि करायलाच हवे) असे सात नियम

बहुतेक आधुनिक सल्ला दोन व्यक्तींपर्यंत पोहोचतो. टिम पोपने २००८ च्या एका ब्लॉग पोस्टमध्ये ५०/७२ फॉरमॅटिंग संकेत लोकप्रिय केला [2], आणि नंतर ख्रिस बीम्सने cbea.ms वर त्यांचे “उत्तम कमिट मेसेजचे सात नियम” म्हणून संकलन केले, जे मूलतः प्रमाणभूत संदर्भ बनले आहे [1]. ते इथे आहेत, आणि ते लक्षात ठेवण्यासारखे आहेत:

विषय (subject) रिकाम्या ओळीने मुख्य भागापासून (body) वेगळा करा
विषयाची ओळ ५० अक्षरांपर्यंत मर्यादित ठेवा
विषयाची ओळ कॅपिटल अक्षराने सुरू करा
विषयाची ओळ पूर्णविरामाने संपवू नका
विषयाच्या ओळीत आज्ञार्थक (imperative) रूप वापरा
मुख्य भाग ७२ अक्षरांवर गुंडाळा (wrap)
मुख्य भागाचा वापर काय आणि का हे समजावण्यासाठी करा, कसे नाही

जोपर्यंत तुम्हाला प्रत्येकामागचे कारण समजत नाही तोपर्यंत हे पंडितपणा वाटतो. मला यात खोलवर जाऊ द्या, कारण प्रामाणिकपणे सांगायचे तर या नियमांमागचे का हे नियमांपेक्षा जास्त उपयुक्त आहे.

विषयाची ओळ खास असते — Git तिला वेगळ्या पद्धतीने हाताळते

ती पहिली ओळ केवळ एक संकेत नाही; Git स्वतः तिला कमिटचे शीर्षक म्हणून हाताळते. git log --oneline, git shortlog, git rebase, आणि जवळपास प्रत्येक GitHub/GitLab UI सारखी टूल्स सारांशांमध्ये फक्त त्या पहिल्या ओळीचा वापर करतात [1]. तिच्यानंतरची रिकामी ओळ हीच Git ला शीर्षक कुठे संपते आणि मुख्य भाग कुठे सुरू होतो हे कळण्याचा मार्ग आहे. रिकामी ओळ वगळा आणि तुमचा छानपणे लिहिलेला मुख्य भाग तुम्ही वापरता त्यापैकी निम्म्या टूल्समध्ये विषयात मिसळून जाईल.

५० अक्षरे का?

हे मनमानी नाही आणि ही कडक मर्यादा नाही — याला एक जोरदार ढकल समजा. GitHub तुम्हाला ५० अक्षरांवर इशारा देते आणि ७२ वर एलिप्सिससह कापते [1]. त्याहून महत्त्वाचे म्हणजे, ही मर्यादा स्पष्टतेस भाग पाडते. जर तुम्ही तुमचा बदल ५० अक्षरांत वर्णन करू शकत नसाल, तर हा सहसा एक इशारा असतो की तुमचा कमिट खूप जास्त गोष्टी करत आहे (याबद्दल नंतर अधिक). मुख्य भाग ७२ वर गुंडाळला जातो जेणेकरून Git चे डीफॉल्ट इंडेंटेशन ८०-कॉलम टर्मिनलमध्ये कुरूपपणे गुंडाळल्याशिवाय बसते [3].

आज्ञार्थक रूपाची बाब — होय, ती खरोखर महत्त्वाची आहे

हा तो नियम आहे ज्याकडे लोक सर्वात जास्त डोळे फिरवतात, म्हणून मला माझा मुद्दा मांडू द्या. “Fix login redirect loop” लिहा, “Fixed” नाही, “Fixes” नाही, “Fixing” नाही.

हा कसोटीचा प्रयोग जो ही गोष्ट क्लिक करतो: तुमच्या विषयाने “If applied, this commit will ___” हे वाक्य पूर्ण केले पाहिजे [4].

✅ If applied, this commit will Fix login redirect loop
❌ If applied, this commit will Fixed login redirect loop

दुसरे वाक्य निरर्थक वाटते. यामागे एक खोल कारणही आहे — Git स्वतः आज्ञार्थक रूपात लिहितो. जेव्हा तुम्ही मर्ज करता, तेव्हा Git “Merge branch ‘feature’” तयार करतो. जेव्हा तुम्ही रिव्हर्ट करता, तेव्हा तो “Revert …” लिहितो. तुमचे कमिट्स कोडबेसला दिलेल्या आज्ञांसारखे वाचले गेले पाहिजेत, Git च्या स्वतःच्या आवाजाशी सुसंगत [4]. गंमत म्हणजे, एवढा सगळा उपदेश असूनही, GitHub वरील फक्त सुमारे ४४% कमिट्स प्रत्यक्षात आज्ञार्थक रूप वापरतात [5]. त्यामुळे याचे पालन केल्याने तुम्ही अशा अल्पसंख्याकांमध्ये येता ज्यांना आपण काय करत आहोत हे माहीत असल्याचे दिसते.

एक झटपट आधी/नंतर:

❌ करू नका	✅ करा
`fixed the bug.`	`Fix null check in user serializer`
`Updating README`	`Document the env setup steps`
`changes to api`	`Add pagination to /orders endpoint`
`WIP`	`Add failing test for expired tokens`

मुख्य भागात काय जाते

विषय काय सांगतो. मुख्य भाग हे ठिकाण आहे जिथे तुम्ही हा बदल का, आता का, आणि तुम्ही काय विचारात घेतले हे समजावता. कसे याचे वर्णन करू नका — diff आधीच कसे दाखवतो. तुम्ही सोडवत असलेली समस्या आणि तुमच्या दृष्टिकोनामागचे कारण समजावा [1].

संपूर्ण मेसेजचे एक खऱ्याखुऱ्यासारखे उदाहरण:

Cap retry attempts on payment webhook

The webhook handler retried indefinitely on a 5xx from the
billing provider. During their outage last Tuesday this hammered
their API and triggered duplicate charge attempts for ~30 users.

Limit retries to 3 with exponential backoff, and log the final
failure so support can reconcile manually. Refunds for the
affected accounts are tracked in TICKET-4821.

लक्षात घ्या की बॅकऑफ कसा अंमलात आणला आहे याबद्दल एकही ओळ नाही. कोड ते दाखवतो. मेसेज त्या गोष्टी टिपतो ज्या अन्यथा तुम्ही कायमच्या गमावल्या असत्या — आउटेज, दुप्पट शुल्क, तिकीट. हाच तो अपूरणीय भाग आहे.

एक व्यावहारिक टीप: कोणत्याही महत्त्वाच्या गोष्टीसाठी git commit -m वापरणे थांबवा. -m फ्लॅग गुपचूप तुम्हाला एक-ओळी मेसेज लिहिण्याचे प्रशिक्षण देतो कारण त्याच्यासह योग्य मुख्य भाग लिहिणे त्रासदायक असते [6]. फक्त git commit चालवा, तुमचा एडिटर उघडू द्या, आणि एखाद्या माणसासारखे लिहा. git config --global core.editor "code --wait" (किंवा vim, किंवा जे काही) ने तुमचा एडिटर सेट करा आणि तुम्ही तयार आहात.

अॅटॉमिक कमिट्स लिहा — हेच खरे रहस्य आहे

ही ती गोष्ट आहे जी जवळपास कोणीही नवशिक्यांना सांगत नाही: तुमच्या कमिट मेसेजची गुणवत्ता जवळपास पूर्णपणे तुमच्या कमिटच्या गुणवत्तेवर अवलंबून असते. जर तुमचा कमिट पंधरा असंबंधित गोष्टी बदलत असेल, तर जगातील कोणताही मेसेज त्याचा चांगला सारांश करू शकत नाही. तुम्ही शेवटी “various fixes” लिहाल कारण खरोखरच तेच एकमेव प्रामाणिक वर्णन असते.

एक अॅटॉमिक कमिट हा सर्वात लहान बदल असतो जो स्वतःहून अर्थपूर्ण असतो आणि कोडबेस कार्यरत स्थितीत सोडतो [7]. एक तार्किक बदल. एक बग फिक्स, एक फॉरमॅटिंग क्लीनअप आणि एक नवीन फीचर मिसळू नका.

यासाठी एक अगदी सोपी वासाची कसोटी आहे: जर तुमच्या विषयाच्या ओळीला “and” या शब्दाची गरज असेल, तर तुमचा कमिट बहुधा दोन कमिट्स आहे [8]. “Add search filter and fix navbar styling” — हे ट्रेंच कोट घातलेले दोन कमिट्स आहेत.

ही शिस्त का योग्य आहे:

git bisect एक महाशक्ती बनते. लहान, केंद्रित कमिट्समुळे bisect ला बग आणणारा नेमका बदल शोधता येतो [9].
रिव्हर्ट्स स्वच्छ असतात. त्यासोबत आलेले एखादे असंबंधित फिक्स चुकून रिव्हर्ट न करता तुम्ही एक फीचर रद्द करू शकता [9].
कोड रिव्ह्यू सोपे होते. रिव्ह्यूअर्स ६००-ओळींच्या मिश्र गठ्ठ्यापेक्षा एक लहान, एक-उद्देशीय बदल खूप जलद समजतात.
इतिहास एका गोष्टीसारखा वाचला जातो. प्रत्येक कमिट हा प्रोजेक्ट इथपर्यंत कसा पोहोचला याचा एक अध्याय असतो [9].

माझ्यासाठी जो प्रवाह कामी येतो: git add -p (पॅच मोड) ने निवडकपणे स्टेज करा जेणेकरून तुम्ही फक्त संबंधित हंक्सच कमिट करता, जरी तुमच्या वर्किंग डिरेक्टरीमध्ये बरेच असंबंधित बदल चालू असले तरी. आणि जर तुम्ही आधीच लोकल पातळीवर गोंधळ केला असेल, तर त्यासाठीच इंटरॅक्टिव्ह रिबेस आहे — पुश करण्यापूर्वी स्क्वॅश करा आणि विभाजित करा.

atomic vs messy commits

Conventional Commits: मशीन आणि माणसांसाठी रचना

एकदा तुम्ही मूलभूत गोष्टींवर प्रभुत्व मिळवले की, एक लोकप्रिय संकेत आहे जो वर एक हलकी रचना जोडतो: Conventional Commits. फॉरमॅट अगदी सोपा आहे [10]:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

तर तुमची विषयाची ओळ एका टाईपने सुरू होते. सामान्य टाईप्स:

Type	केव्हा वापरावे
`feat`	एक नवीन फीचर
`fix`	एक बग फिक्स
`docs`	फक्त डॉक्युमेंटेशन
`style`	फॉरमॅटिंग, व्हाइटस्पेस — लॉजिकमध्ये बदल नाही
`refactor`	असा कोड बदल जो बग फिक्सही करत नाही किंवा फीचरही जोडत नाही
`perf`	कार्यक्षमतेतील सुधारणा
`test`	टेस्ट्स जोडणे किंवा दुरुस्त करणे
`build` / `ci`	बिल्ड सिस्टम किंवा CI कॉन्फिग
`chore`	नियमित देखभाल, डिपेंडन्सीज, टूलिंग

प्रत्यक्षातील उदाहरणे:

feat(auth): add passwordless email login
fix(api): handle empty cart on checkout
docs: clarify env setup in README
refactor(parser): extract token validation

ब्रेकिंग बदल दोन प्रकारे ध्वजांकित केले जातात: कोलनच्या आधी एक !, किंवा एक BREAKING CHANGE: फूटर [10]:

feat!: drop support for Node 16

BREAKING CHANGE: minimum supported runtime is now Node 18.

टीम्स हे का स्वीकारतात

याचा फायदा सौंदर्यविषयक नाही — तो ऑटोमेशनचा आहे. टाईप मशीन-वाचनीय असल्यामुळे, टूलिंग हे करू शकते:

तुमच्या कमिट इतिहासातून स्वयंचलितपणे चेंजलॉग्ज तयार करणे.
तुमची सिमँटिक व्हर्जन योग्यरीत्या वाढवणे — fix → patch, feat → minor, BREAKING CHANGE → major [10].
माणूस व्हर्जन ठरवल्याशिवाय CI मध्ये रिलीझ आणि पब्लिश पायऱ्या ट्रिगर करणे.

ही काही फारशी प्रचलित नसलेली गोष्टही नाही. ३८१ टॉप NPM लायब्ररींच्या एका पुनरावलोकनात असे आढळले की जवळपास ९५% Conventional Commits फॉरमॅटिंग वापरत होत्या, आणि निम्म्याहून अधिक त्यांच्या इतिहासात ८०%+ अनुपालन गाठत होत्या [11]. जर तुम्ही एखादी लायब्ररी मेन्टेन करत असाल, तर हे आता जवळपास मूलभूत अपेक्षा बनले आहे.

प्रामाणिकपणे सांगायचे तर — हे प्रत्येकासाठी आहे का? एखाद्या एकल प्रोजेक्टवर किंवा लहान अंतर्गत अॅपवर जिथे तुम्ही काहीही स्वयं-रिलीझ करत नाही, तिथे feat:/fix: हे प्रिफिक्स केवळ औपचारिकतेसाठी औपचारिकता वाटू शकतात. आधीचे सात नियम प्रिफिक्सपेक्षा कितीतरी जास्त महत्त्वाचे आहेत. जेव्हा ऑटोमेशन शिस्तीची किंमत वसूल करते तेव्हा Conventional Commits वापरा. एखादे लोकप्रिय रेपो वापरते म्हणून त्याचे अंधानुकरण करू नका.

अँटी-पॅटर्न्स — कमिट मेसेज वाईट कशामुळे होतो

मला नावे घेऊ द्या. हे तेच आहेत जे मला सतत दिसतात, आणि ते का दुखावतात [12][8]:

“Fix bug” — कोणता बग? तुम्हाला आठवणार नाही. बगचे नाव सांगा.
“Update”, “changes”, “stuff”, “wip” — शून्य माहिती. diff ने आधीच सांगितले की काहीतरी बदलले.
फायली सूचीबद्ध करणे: “Update user.rb and helper.js” — git show आधीच फायली सूचीबद्ध करतो. मेसेजने बदलाचा अर्थ समजावला पाहिजे, फाइल सूचीची नक्कल करू नये [12].
विषयात “and” — जवळपास नेहमीच याचा अर्थ कमिटचे विभाजन व्हायला हवे [8].
भूतकाळ / चुकीचे रूप — “Fixed”, “Added”, “Changing”. आज्ञार्थक निवडा आणि सुसंगत राहा.
एक-ओळींची भिंत — सर्व दहा कमिट्स “updates” म्हणत आहेत. git commit -m च्या अतिवापराने हेच तयार होते [12].
उघड गोष्ट पुन्हा सांगणारा विषय — “Make changes to the changes file”. काय आणि का ते सांगा.

एंटर दाबण्यापूर्वी इथे एक मनाची खात्री: तुमची विषयाची ओळ “If applied, this commit will ___” अशी पुन्हा वाचा आणि स्वतःला विचारा की जो तिथे नव्हता त्याला सहा महिन्यांनी ती समजेल का. जर उत्तर नाही असेल, तर तीस सेकंद जास्त खर्च करा. हे तुमच्या भविष्यातील मानसिक स्वास्थ्यातील सर्वात स्वस्त गुंतवणूक आहे जी तुम्ही कधीही कराल.

तुम्हाला प्रामाणिक ठेवणारी टूलिंग

केवळ इच्छाशक्तीने शिस्त टिकवणे कठीण आहे, म्हणून त्याऐवजी मशीनना तुम्हाला टोचू द्या:

कमिट मेसेज टेम्पलेट — तुमच्या स्वतःच्या नियमांची आठवण सेट करा:
```
git config --global commit.template ~/.gitmessage.txt
```
त्या फाइलमध्ये एक सांगाडा ठेवा (विषयाची आठवण, रिकामी ओळ, मुख्य भागाची आठवण) आणि तुम्ही प्रत्येक वेळी कमिट करता तेव्हा तो दिसतो.
commitlint + Husky — एक git हुक जो Conventional Commits चे पालन न करणारे कमिट्स नाकारतो. टीम्ससाठी उत्तम.
Commitizen — एक इंटरॅक्टिव्ह प्रॉम्प्ट जो तुम्हाला योग्यरीत्या फॉरमॅट केलेला कमिट तयार करण्यात मार्गदर्शन करतो.
एडिटर इंटिग्रेशन — बहुतेक एडिटर्स (आणि GitKraken सारखी टूल्स) तुमचा विषय ५० अक्षरांपलीकडे गेल्यावर अधोरेखित करतात [13].

यापैकी कोणीही तुमच्यासाठी चांगला मेसेज लिहीत नाही — ते फक्त आकार लागू करतात. विचार करणे हे अजूनही तुमचेच काम आहे. आणि आजकाल एखादा AI सहाय्यक तुमच्या diff वरून एक बऱ्यापैकी मेसेज मसुदा करू शकतो, जे खरोखरच उपयुक्त आहे, पण त्याला एखाद्या ज्युनिअरचा पहिला मसुदा समजा. तो काय बदलले ते पाहू शकतो; तो गेल्या मंगळवारचा आउटेज किंवा तिकीट क्रमांक पाहू शकत नाही. तो संदर्भ फक्त तुमच्या डोक्यात राहतो, आणि तो मेसेजमध्ये टाकणे हाच संपूर्ण उद्देश आहे.

तुम्ही प्रत्यक्षात पाळू शकाल असा एक वर्कफ्लो

सगळे एकत्र करून, एक समजूतदार कमिट सवय रोजच्या जीवनात कशी दिसते ते इथे आहे:

एक तार्किक बदल करा. जर तुम्ही असंबंधित संपादनांकडे वळला असाल, तर git add -p ने निवडकपणे स्टेज करा.
git commit चालवा (-m शिवाय) जेणेकरून तुमचा एडिटर उघडतो.
~५० अक्षरांखालचा विषय लिहा, आज्ञार्थक रूप, कॅपिटल अक्षराने सुरू, पूर्णविराम नाही. जर तुमची टीम Conventional Commits वापरत असेल तर एक टाईप प्रिफिक्स जोडा.
रिकामी ओळ, मग एक मुख्य भाग जो का हे समजावतो — पण फक्त बदलाला संदर्भाची गरज असेल तरच. क्षुल्लक कमिट्सना मुख्य भाग लागत नाही.
फूटरमध्ये तिकिटे किंवा इश्यूज संदर्भित करा (Refs #421, Closes #88).
सेव्ह करण्यापूर्वी “If applied, this commit will ___” कसोटीने ते पुन्हा वाचा.

एवढेच. हे प्रत्येक कमिटला कदाचित एक मिनिट जोडते आणि नंतर तास वाचवते. अधिक उदाहरणांसह सखोल मार्गदर्शनासाठी, freeCodeCamp चे पायरीवार मार्गदर्शक हे एक भक्कम सहवाचन आहे [14].

सर्वोत्तम कमिट मेसेज हा सर्वात हुशार किंवा सर्वात लांब नसतो. तो असा असतो जो तुमचा भविष्यातील सहकारी स्क्रीनकडे पाहून ओरडणार असलेल्या प्रश्नाचे उत्तर देतो: “पृथ्वीवर हे का बदलले गेले?” त्याचे उत्तर द्या, आणि तुम्ही काम केले आहे.

End