Git कमिट संदेश: नियम, उदाहरण, और प्रचलन

Git कमिट संदेश क्यों मायने रखता है

कमिट संदेश आपके बदलावों को किसी भी बाद में कोड पढ़ने वाले, जिसमे भविष्य के आप भी शामिल हैं, को समझाता है।

तीन महीने बाद, आपको याद नहीं रहेगा कि आपने वह डेटा पाइपलाइन क्यों रीफ़ैक्टर की थी या किसी विशेष ऑपरेशन के लिए आपने pandas से polars पर स्विच क्यों किया। आपका कमिट संदेश ही आपके तर्क का एकमात्र रिकॉर्ड है। इसके बिना, आपको अंदाज़ा लगाना पड़ेगा या Slack थ्रेड्स और JIRA टिकट्स में खंगालना पड़ेगा।

यहाँ कुछ और ठोस कारण हैं कि git कमिट संदेश क्यों मायने रखता है।

स्पष्ट कमिट संदेशों के साथ कोड रिव्यू तेज़ी से होते हैं। आपका रिव्यूअर संदेश को स्कैन कर सकता है, उद्देश्य समझ सकता है, और देख सकता है कि इम्प्लीमेंटेशन उससे मेल खाता है या नहीं। धुंधले संदेश रिव्यूअर्स को केवल diff से ही आपकी सोच को रिवर्स-इंजीनियर करने पर मजबूर करते हैं।

डिबगिंग भी आसान हो जाती है। जब कोई बग आता है, तो आप git log या git blame का प्रयोग करके पता लगाते हैं कि समस्याग्रस्त कोड कब आया। "fix authentication bug" जैसा संदेश कुछ नहीं बताता। "fix token expiration check in auth middleware" जैसा संदेश आपको सीधे समस्या तक ले जाता है।

टीम सहयोग एक पठनीय इतिहास पर निर्भर करता है। जब कोई आपके प्रोजेक्ट से जुड़ता है या आपके छोड़े स्थान से आगे बढ़ता है, तो वे कोडबेस कैसे विकसित हुआ समझने के लिए कमिट्स पढ़ते हैं। स्पष्ट संदेश आपकी Git हिस्ट्री को ऐसी दस्तावेज़ीकरण में बदलते हैं जो सच में मददगार हो।

निचोड़ यह है कि एक वर्णनात्मक कमिट संदेश लिखने में 15-30 सेकंड लगते हैं, लेकिन आगे चलकर घंटों की उलझन बचाते हैं।

एक अच्छे Git कमिट संदेश के मूल सिद्धांत

अच्छे कमिट संदेश कुछ सरल सिद्धांतों का पालन करते हैं—बस इतना ही।

भविष्य के पाठकों के लिए लिखें

आपका कमिट संदेश अभी के लिए नहीं—उसके लिए है जो इसे छह महीने बाद पढ़ेगा।

वह व्यक्ति कोई नया टीम सदस्य हो सकता है जो समझना चाहता है कि कोडबेस एक खास तरीके से क्यों काम करता है। वह आप भी हो सकते हैं, जो याद करने की कोशिश कर रहे हैं कि आपने एक निर्णय क्यों लिया था। किसी भी स्थिति में, उनके पास आज वाला संदर्भ नहीं होगा।

ध्यान दें उद्देश्य और तर्क पर, केवल क्या बदला इस पर नहीं। डिफ़ दिखाता है कि क्या बदला। आपका संदेश बताए कि क्यों बदला और किस समस्या को हल करता है।

स्पष्ट और संक्षिप्त रहें

छोटे, वर्णनात्मक संदेश दर्जनों कमिट्स के बीच स्कैन करना आसान बनाते हैं।

"add caching" जैसा संदेश धुंधला है। "add Redis caching for API responses" जैसा संदेश आपको ठीक-ठीक बताता है क्या हुआ। आप इसे git log --oneline में पढ़कर तुरंत समझ सकते हैं कि कमिट क्या करता है।

आपकी सब्जेक्ट लाइन का उत्तर होना चाहिए: यह कमिट क्या करता है? यदि उत्तर देने में 50-60 वर्ण से अधिक लग रहे हैं, तो शायद आप एक साथ बहुत से बदलाव कमिट कर रहे हैं।

सुसंगत रहें

रेपो भर में सुसंगतता हिस्ट्री को अनुमानित और पार्स करना आसान बनाती है।

जब हर कमिट एक ही फ़ॉर्मैट का पालन करता है, तो आप जल्दी से हिस्ट्री स्कैन कर सकते हैं। आपको पता होता है कि बदलाव के प्रकार, स्कोप और विवरण कहाँ देखना है। जो टीमें सुसंगत फ़ॉर्मैट लागू करती हैं वे चेंजलॉग बनाने या प्रकार के आधार पर कमिट फ़िल्टर करने जैसे कार्य स्वचालित कर सकती हैं।

कोई स्टाइल चुनें और उसी पर टिके रहें। यदि आपकी टीम वर्तमानकाल के इम्परेटिव का इस्तेमाल करती है, तो यूँ ही भूतकाल में न शिफ्ट हों।

क्या और क्यों समझाएँ (कैसे नहीं)

कोड दिखाता है कि आपने समस्या कैसे हल की। आपका कमिट संदेश बताए कि समस्या क्या थी और आपने यह समाधान क्यों चुना।

"refactored load_data() to use list comprehension instead of for loop" मत लिखें। लिखें "speed up data loading by 40% for large CSV files." पहला संदेश कोड बदलाव का वर्णन करता है। दूसरा प्रभाव बताता है।

संदर्भ तब जोड़ें जब वह भविष्य के पाठकों को आपका निर्णय समझने में मदद करे। यदि आपने किसी समाधान पर पहुँचने से पहले तीन तरीके आजमाए, तो उसका ज़िक्र करें। यदि कोई संबंधित बग रिपोर्ट या डिज़ाइन निर्णय है, तो उसका संदर्भ दें।

Git कमिट संदेश की संरचना

अधिकांश Git कमिट संदेश एक मानक तीन-भागीय संरचना का पालन करते हैं: सब्जेक्ट लाइन, बॉडी, और फ़ूटर।

सब्जेक्ट लाइन

सब्जेक्ट लाइन एक-लाइन का सारांश है जो git log --oneline और पुल रिक्वेस्ट सूचियों में दिखता है।

संभव हो तो इसे 50 वर्णों के अंदर रखें, अधिकतम 72। यह सीमा सुनिश्चित करती है कि संदेश टर्मिनल आउटपुट और GitHub के UI में बिना कटे ठीक से दिखे। यदि आप 50 वर्णों में सारांश नहीं समा पा रहे, तो शायद आप एक कमिट में बहुत कुछ समेट रहे हैं।

इम्परेटिव मूड का उपयोग करें—"add feature" लिखें, "added feature" या "adds feature" नहीं। इसे ऐसे समझें मानो वाक्य पूरा कर रहे हैं: "If applied, this commit will..."। तो "If applied, this commit will add Redis caching" स्वाभाविक लगता है, जबकि "If applied, this commit will adds Redis caching" नहीं।

उदाहरण:

• fix null pointer exception in data loader

• add caching layer for API responses

• remove deprecated pandas functions

बॉडी (जब ज़रूरी हो)

सरल बदलावों के लिए बॉडी छोड़ दें। यदि आपकी सब्जेक्ट लाइन कमिट को पूरी तरह समझा देती है, तो बस।

जब आपको बताने की ज़रूरत हो कि आपने बदलाव क्यों किया या ऐसा संदर्भ देना हो जो भविष्य के पाठकों की मदद करे, तब बॉडी जोड़ें। सब्जेक्ट और बॉडी के बीच एक खाली लाइन छोड़ें—Git इन्हें अलग करने के लिए इसका उपयोग करता है।

बॉडी में इन सवालों के जवाब हों: यह किस समस्या को हल करता है? आपने यह तरीका क्यों चुना? क्या कोई साइड इफ़ेक्ट या सीमाएँ हैं? क्या आपने अन्य समाधान पर विचार किया?

टर्मिनल आउटपुट में पठनीयता के लिए लाइनों को 72 वर्णों पर रैप करें। अधिकांश टेक्स्ट एडिटर्स यह अपने-आप कर सकते हैं।

उदाहरण:

add Redis caching for API responses

API response times were hitting 2-3 seconds for repeated queries.
Added Redis with 5-minute TTL to cache query results. This drops
response time to ~50ms for cached queries.

Considered using in-memory cache but Redis lets us scale horizontally
if needed.

फ़ूटर (वैकल्पिक)

फ़ूटर का उपयोग संबंधित इश्यूज़, पुल रिक्वेस्ट्स, या ब्रेकिंग चेंजेस का संदर्भ देने के लिए करें।

यदि आपका कमिट कोई GitHub इश्यू ठीक करता है, तो फ़ूटर में Fixes #123 या Closes #456 जोड़ें। कमिट मर्ज होने पर GitHub इश्यू अपने-आप बंद कर देगा। ब्रेकिंग चेंजेस के लिए BREAKING CHANGE: जोड़ें, और बताएं कि क्या टूटा और माइग्रेट कैसे करें।

उदाहरण:

remove support for Python 3.7

Python 3.7 reached end-of-life in June 2023. This commit drops
support and updates minimum version to Python 3.8.

BREAKING CHANGE: Python 3.7 users must upgrade to 3.8 or later.
Closes #789

अधिकांश कमिट्स के लिए आपको फ़ूटर की ज़रूरत नहीं होती—सिर्फ़ तब जब आप बाहरी संदर्भ लिंक कर रहे हों या ब्रेकिंग चेंजेस चिह्नित कर रहे हों।

आम Git कमिट संदेश प्रकार और उनका उपयोग कब करें

कई प्रोजेक्ट्स बदलावों को एक नज़र में वर्गीकृत करने के लिए कमिट टाइप प्रीफ़िक्स का उपयोग करते हैं।

आपको लेबल्स की कोई सख्त सूची याद रखने की ज़रूरत नहीं। उद्देश्य यह है कि पाठक पूरे डिफ़ पढ़े बिना जल्दी समझ लें कि किस तरह का बदलाव हुआ।

यहाँ चार श्रेणियाँ हैं जिनसे आप वाकिफ़ रहें:

• फ़ीचर परिवर्तन नई कार्यक्षमता लाते हैं। जब आप कुछ नया बना रहे हों—जैसे नया API एन्डपॉइंट, डेटा प्रोसेसिंग फ़ंक्शन, या यूज़र-फेसिंग फ़ीचर—तो feat: या add: जैसे प्रीफ़िक्स का उपयोग करें। उदाहरण: feat: add CSV export for analysis results।

• बग फ़िक्सेस मौजूदा समस्याएँ हल करते हैं। जब आप इच्छित व्यवहार को बहाल कर रहे हों, तो fix: का उपयोग करें। यह नल पॉइंटर एक्सेप्शन से लेकर आपके मॉडल में गलत गणनाओं तक कुछ भी हो सकता है। उदाहरण: fix: handle missing values in preprocessing pipeline।

• दस्तावेज़ीकरण अपडेट्स कोड कमेंट्स, README फ़ाइलों या इनलाइन डॉक्यूमेंटेशन को बेहतर बनाते हैं। जब आप कोड का व्यवहार नहीं बदल रहे, बस उसे बेहतर समझा रहे हों, तो docs: का उपयोग करें। उदाहरण: docs: add usage examples for data loader class।

• रीफ़ैक्टरिंग और मेंटेनेंस कार्य कोड संरचना में सुधार करते हैं बिना व्यवहार बदले। जब आप कोड को साफ़-सुथरा या अधिक रखरखावयोग्य बनाने के लिए पुनर्गठित कर रहे हों, तो refactor: का उपयोग करें। निर्भरता अपडेट करने या बिल्ड कॉन्फ़िग बदलने जैसे नियमित कार्यों के लिए chore: का उपयोग करें। उदाहरण: refactor: extract validation logic into separate module या chore: update pandas to 3.0.0।

जो भी प्रकार आपके बदलाव का सबसे अच्छा वर्णन करे, उसे चुनें और आगे बढ़ें—"सही" लेबल चुनने से ज़्यादा सुसंगतता मायने रखती है।

बेहतर Git कमिट संदेश लिखने के नियम

यहाँ नियमों की एक चेकलिस्ट है जो आपके कमिट संदेशों को अधिक उपयोगी बनाएगी।

• सब्जेक्ट लाइन 50 वर्णों के अंदर रखें। यह सुनिश्चित करता है कि git log --oneline, GitHub की कमिट सूची, और टर्मिनल आउटपुट में बिना कटे सही दिखे। यदि 50 में नहीं समा रहा, तो अधिकतम 72 तक रखें।

• इम्परेटिव मूड का उपयोग करें। "add feature" लिखें, "added feature" या "adds feature" नहीं। आपकी सब्जेक्ट लाइन वाक्य "If applied, this commit will..." को पूरा करे। जैसे "If applied, this commit will add caching" सही पढ़ता है।

• सब्जेक्ट और बॉडी के बीच एक खाली लाइन रखें। Git इस खाली लाइन से सारांश और विस्तृत व्याख्या में भेद करता है। इसके बिना Git टूल्स आपका संदेश गलत दिखा सकते हैं।

• सब्जेक्ट लाइन के अंत में पूर्णविराम न लगाएँ। आप वर्ण बचाते हैं और सब्जेक्ट लाइन वैसे भी पूर्ण वाक्य नहीं है। fix null pointer in loader लिखें, fix null pointer in loader नहीं।

• अपनी सब्जेक्ट लाइन के पहले शब्द को कैपिटलाइज़ करें। Add caching for API calls लिखें, add caching for API calls नहीं। इससे आपकी कमिट हिस्ट्री सुसंगत और पेशेवर दिखती है।

• बॉडी में "क्यों", न कि "क्या" समझाएँ। डिफ़ दिखाता है कि क्या बदला। बॉडी में बदलाव के पीछे का तर्क, वैकल्पिक तरीकों और किए गए ट्रेड-ऑफ़ समझाएँ।

• बॉडी टेक्स्ट को 72 वर्ण पर रैप करें। इससे टर्मिनल आउटपुट में लाइन रैपिंग की समस्या नहीं आती और विभिन्न टूल्स में पठनीयता बनी रहती है।

• हर कमिट को एटॉमिक रखें। एक तर्कसंगत बदलाव प्रति कमिट। यदि आप बग ठीक कर रहे हैं और कोड रीफ़ैक्टर कर रहे हैं, तो उन्हें अलग-अलग कमिट्स में बाँटें और अलग संदेश दें।

अच्छे Git कमिट संदेश के उदाहरण

यहाँ वास्तविक दुनिया के उदाहरण हैं जो अलग-अलग परिदृश्यों के लिए अच्छे कमिट संदेश दिखाते हैं।

एक सरल फ़िक्स

fix: handle NaN values in feature engineering

The preprocessing pipeline crashed when encountering NaN values
in the 'age' column. Added fillna() with median imputation before
scaling features.

यह इसलिए काम करता है क्योंकि यह समस्या (NaN क्रैश) पहचानता है, बताता है कहाँ हुई (प्रीप्रोसेसिंग पाइपलाइन, age कॉलम), और समाधान बताता है (मीडियन इम्प्यूटेशन)।

एक नया फ़ीचर

feat: add model performance tracking to MLflow

Added automatic logging of model metrics, parameters, and artifacts
to MLflow after each training run. This replaces our manual CSV
logging and makes experiment comparison much easier.

Metrics tracked: accuracy, precision, recall, F1 score
Training time also logged for performance monitoring.

अच्छे फ़ीचर कमिट्स बताते हैं आपने क्या बनाया, वह क्यों उपयोगी है, और ऐसे विवरण देते हैं जो स्कोप समझने में मदद करें।

एक रीफ़ैक्टर

refactor: split data_loader.py into separate modules

Moved dataset classes to datasets.py, transformation logic to
transforms.py, and utility functions to utils.py. The original
file was 800+ lines and hard to navigate.

No behavior changes - all tests still pass.

रीफ़ैक्टर संदेश स्पष्ट करें कि आपने कार्यक्षमता नहीं बदली, केवल संरचना। "all tests still pass" पंक्ति रिव्यूअर्स को आश्वस्त करती है।

एक दस्तावेज़ीकरण अपडेट

docs: add examples for custom loss functions

Previous documentation showed only built-in loss functions.
Added three examples: weighted cross-entropy, focal loss, and
custom regression loss with L1 regularization.

Each example includes code and explanation of when to use it.

दस्तावेज़ीकरण कमिट्स बताएँ कि आपने क्या दस्तावेज़ित किया और इसकी ज़रूरत क्यों थी।

किसी इश्यू या टिकट का संदर्भ देना

fix: prevent memory leak in batch processing

Large datasets caused memory usage to grow unbounded during batch
processing. The issue was holding references to processed batches
in the results list.

Changed to yield results instead of accumulating them in memory.
Memory usage now stays constant regardless of dataset size.

Fixes #247

जब आप किसी इश्यू का संदर्भ देते हैं, तो इतना संदर्भ शामिल करें कि कोई बिना टिकट पर क्लिक किए भी समाधान समझ सके। नीचे का Fixes #247 GitHub को बताता है कि यह कमिट मर्ज होने पर इश्यू अपने-आप बंद कर दे।

सभी उदाहरण एक ही पैटर्न का पालन करते हैं: क्या बदला से शुरू करें, क्यों समझाएँ, ऐसा संदर्भ जोड़ें जो भविष्य के पाठकों की मदद करे, और प्रासंगिक होने पर संबंधित इश्यूज़ का संदर्भ दें।

Git कमिट संदेश मानक के रूप में Conventional Commits

Conventional commits एक लोकप्रिय फ़ॉर्मैट है जो एक सरल प्रीफ़िक्स पैटर्न के जरिए कमिट संदेशों में संरचना जोड़ता है।

बेसिक फ़ॉर्मैट

फ़ॉर्मैट कुछ ऐसा दिखता है: type(scope): description।

टाइप बताता है कि आप किस तरह का बदलाव कर रहे हैं—फ़ीचर्स के लिए feat, बग फ़िक्स के लिए fix, दस्तावेज़ीकरण के लिए docs, कोड पुनर्संरचना के लिए refactor। स्कोप वैकल्पिक है और बताता है कि कोडबेस का कौन-सा हिस्सा बदला—जैसे (auth) या (api)। डिस्क्रिप्शन बताता है आपने क्या किया।

उदाहरण:

feat(api): add endpoint for batch predictions
fix(auth): prevent token expiration edge case
docs(readme): add installation instructions for Windows
refactor(data): extract validation logic to separate module

ध्यान रखें कि यह एक प्रचलन है, आवश्यकता नहीं। Git को इससे कोई फ़र्क नहीं पड़ता कि आप यह फ़ॉर्मैट उपयोग करते हैं या नहीं। ज़्यादातर यह टीम के निर्णय पर निर्भर है कि सुसंगतता और टूलिंग के लिए संदेशों को कैसे संरचित करना है।

Conventional commits कब उपयोगी हैं

जो टीमें रिलीज़ प्रक्रियाओं को स्वचालित करती हैं, उन्हें conventional commits से सबसे अधिक लाभ मिलता है।

टूल्स आपकी कमिट हिस्ट्री को पार्स कर सकते हैं और अपने-आप चेंजलॉग बना सकते हैं। जब आप कोई रिलीज़ टैग करते हैं, तो टूल पिछली रिलीज़ से अब तक के कमिट्स स्कैन करता है, उन्हें प्रकार (feat, fix, docs) के अनुसार समूहित करता है, और एक फ़ॉर्मैटेड चेंजलॉग बनाता है। इससे वर्ज़न्स के बीच क्या बदला उसका हाथ से ट्रैक रखने का काम बचता है।

Conventional commits सेमांटिक वर्ज़निंग ऑटोमेशन का भी समर्थन करते हैं। यदि पिछली रिलीज़ के बाद से आपके सभी कमिट्स फिक्सेस हैं, तो टूल पैच वर्ज़न बढ़ाता है (1.2.3 → 1.2.4)। यदि आपने फ़ीचर्स जोड़े हैं, तो माइनर वर्ज़न बढ़ता है (1.2.3 → 1.3.0)। ब्रेकिंग चेंजेस मेजर वर्ज़न बंप ट्रिगर करते हैं (1.2.3 → 2.0.0)।

लेकिन यदि आपकी टीम स्वचालित रिलीज़ या चेंजलॉग जनरेशन का उपयोग नहीं करती, तो conventional commits ज़रूरत से ज़्यादा हो सकते हैं। यह संरचना इंसानों से ज़्यादा मशीनों की मदद करती है, इसे ध्यान में रखें।

Git कमिट संदेशों में आम गलतियाँ जिनसे बचना चाहिए

अनुभवी डेवलपर्स भी कभी-कभी कमिट संदेश लिखते हुए गलतियाँ करते हैं, लेकिन यह ज्ञान की कमी से कम और लापरवाही से ज़्यादा जुड़ा है।

यहाँ कुछ गलतियाँ हैं जिनसे आपको बचना चाहिए।

अस्पष्ट या जनरल संदेश

"fix bug" या "update code" जैसे संदेश भविष्य के पाठकों को कुछ नहीं बताते।

जब आप git log में किसी खास बदलाव की तलाश कर रहे होते हैं, तो आप दर्जनों कमिट्स स्कैन करते हैं। "fix bug" जैसा संदेश आपको डिफ़ खोलकर कोड पढ़ने पर मजबूर करता है कि क्या ठीक हुआ। "fix null pointer in data preprocessing" जैसा संदेश तुरंत बता देता है कि क्या यह वही कमिट है जिसे आप ढूँढ रहे हैं।

जनरल संदेश सबका समय बर्बाद करते हैं। यदि आपको इतना भी याद नहीं कि आपने क्या बदला कि आप एक विशिष्ट संदेश लिख सकें, तो शायद आपको अभी कमिट नहीं करना चाहिए।

असंबंधित बदलाव मिलाना

एक कमिट में एक तर्कसंगत बदलाव होना चाहिए।

जब आप एक ही कमिट में बग फ़िक्स करते हैं और असंबंधित कोड रीफ़ैक्टर करते हैं, तो आप कोड रिव्यू को कठिन और git bisect को बेकार बना देते हैं। यदि वह कमिट रिग्रेशन लाता है, तो किसी को यह सुलझाना पड़ेगा कि बदलाव के किस हिस्से ने कारण बना। यदि वे केवल बग फ़िक्स को रिवर्ट करना चाहें, तो नहीं कर पाएँगे—वे रीफ़ैक्टर भी रिवर्ट कर देंगे।

हमेशा बदलावों को अलग-अलग कमिट्स में बाँटें। एक कमिट में बग ठीक करें, दूसरे में रीफ़ैक्टर करें। हर कमिट ऐसा होना चाहिए जिसे आप स्वतंत्र रूप से रिवर्ट कर सकें बिना कोडबेस तोड़े।

यदि आपने स्थानीय रूप से बदलाव मिला दिए हैं, तो git add -p का उपयोग करके फ़ाइलों के हिस्सों को अलग-अलग स्टेज करें और उन्हें तर्कसंगत खंडों में कमिट करें।

वर्क-इन-प्रोग्रेस संदेश छोड़ देना

"WIP" या "temp fix" जैसे संदेश वाले कमिट स्थानीय रूप से तो ठीक हैं, लेकिन मेन ब्रांच में नहीं आने चाहिए।

फ़ीचर ब्रांच मर्ज करने से पहले अपनी कमिट हिस्ट्री साफ़ करें। Squash करके WIP कमिट्स को अर्थपूर्ण कमिट्स में बदलें और सही संदेश दें। "asdf" और "trying something" को फिर से लिखें ताकि वे बताएँ कि आपने वास्तव में क्या किया।

पुश करने से पहले कमिट्स को मिलाने, संदेश फिर से लिखने और क्रम बदलने के लिए git rebase -i का उपयोग करें। आपकी टीम को क्या और क्यों बदला इसका साफ़ इतिहास दिखना चाहिए, न कि आपका डिबगिंग प्रोसेस।

Git कमिट संदेशों का उपयोग करने वाली टीमों के लिए सर्वश्रेष्ठ प्रथाएँ

यदि आपकी टीम Git हिस्ट्री को सच में उपयोगी बनाना चाहती है, तो आपको सुसंगतता चाहिए। पालन करने के लिए कुछ सर्वश्रेष्ठ प्रथाएँ यहाँ हैं।

एक साझा स्टाइल पर शुरुआत में सहमति बनाएं। तय करें कि आप conventional commits, कस्टम फ़ॉर्मैट, या सिर्फ़ बुनियादी नियमों का सेट उपयोग करेंगे। एक तरीका चुनें और पूरी टीम में उसी पर टिके रहें। जब आधे कमिट्स "feat: add feature" कहते हैं और बाकी आधे "Added new feature", तो आपकी हिस्ट्री स्कैन करना कठिन हो जाता है और ऑटोमेशन टूट सकता है।

स्टाइल से ज़्यादा मायने यह रखता है कि सब उसका पालन करें। कुछ टीमें वर्तमानकाल के इम्परेटिव ("add feature") को प्राथमिकता देती हैं, कुछ भूतकाल ("added feature") का उपयोग करती हैं। दोनों ठीक हैं यदि सुसंगत रूप से लागू हों।

अपनी परंपराएँ कहीं सुलभ स्थान पर दस्तावेज़ित करें। अपने रेपो में CONTRIBUTING.md फ़ाइल जोड़ें जो उदाहरणों के साथ आपका कमिट संदेश फ़ॉर्मैट समझाए। इसे नए टीम सदस्यों की ऑनबोर्डिंग डॉक्यूमेंट्स में शामिल करें। जब कोई पूछे "इस कमिट को कैसे फ़ॉर्मैट करूँ?", तो बार-बार समझाने की बजाय डॉक्यूमेंटेशन का संदर्भ दें।

आपका दस्तावेज़ीकरण उस बेसिक फ़ॉर्मैट को कवर करे जिसे आप उपयोग करते हैं, कब बॉडी जोड़नी है बनाम केवल सब्जेक्ट रखना है, इश्यूज़ या टिकट्स का संदर्भ कैसे दें, और आपके रेपो से कुछ वास्तविक उदाहरण।

कोड रिव्यू के दौरान कमिट संदेशों का उपयोग करें। अच्छे कमिट संदेश पुल रिक्वेस्ट रिव्यू को तेज़ और केंद्रित बनाते हैं। रिव्यूअर्स कोड में जाने से पहले कमिट संदेश पढ़कर बदलावों की प्रगति समझ सकते हैं।

रिव्यू करते समय, कमिट संदेशों की जाँच उसी तरह करें जैसे कोड की। यदि कोई संदेश अस्पष्ट या भ्रामक है, तो मर्ज होने से पहले उसे फिर से लिखने के लिए कहें। स्पष्ट कमिट्स वाला PR रिव्यू करना आसान, ज़रूरत पड़ने पर रिवर्ट करना आसान, और बाद में समझना भी आसान होता है।

निष्कर्ष

एक स्पष्ट कमिट संदेश लिखने में 30 सेकंड लगते हैं, लेकिन आगे चलकर घंटों की उलझन बचती है।

अपनी कमिट हिस्ट्री को ऐसे दस्तावेज़ीकरण की तरह समझें जो आपके कोड के साथ रहता है। जब आप "fix bug" लिखते हैं बजाय "fix null pointer in data preprocessing" के, तो आप उस कमिट को बाद में पढ़ने वाले हर व्यक्ति—खुद सहित—का समय बर्बाद कर रहे होते हैं।

अपने कमिट संदेशों को कोड की तरह ट्रीट करें। यदि आप ढीला-ढाला, बिना कमेंट का कोड प्रोडक्शन में पुश नहीं करेंगे, तो ढीले-ढाले कमिट संदेश भी न पुश करें। इम्परेटिव मूड का उपयोग करें, सब्जेक्ट लाइन 50 वर्णों के अंदर रखें, ज़रूरत पड़ने पर बॉडी में "क्यों" समझाएँ, और हर कमिट एटॉमिक रखें।

अब आप अर्थपूर्ण कमिट संदेश लिखना जानते हैं। अपने कौशल को अगले स्तर पर ले जाने के लिए हमारा Intermediate Git कोर्स जॉइन करें।