कमेंट्स पर कमेंट्स कैसे लिखें

अनुवादक से प्रस्तावना

सॉफ्टवेयर विकास के वर्षों में, कई टीमों का सदस्य होने के नाते, विभिन्न अच्छे और अनुभवी लोगों के साथ काम करते हुए, मैंने अक्सर मनाया (और ईमानदार होने के लिए, मैंने वही समस्या बनाई) - रिपॉजिटरी में कुल गड़बड़। प्रत्येक ने अपने अंदाज में कमेंट्स पर लिखा (और, अगर लगातार एक में); टिप्पणियों के आधे बेकार थे (" यह एक पुल है " श्रेणी से), शेष आधे में से आधे को शायद ही समझा गया था।

और फिर एक बढ़िया पल मैंने इस लेख को देखा, जिसके पहले मुझे आखिरकार अनुवाद पर हाथ मिला। केवल 7 सरल और छोटे नियम, और - लो और निहारना - कमिट्स के इतिहास को देखना न केवल उपयोगी था, बल्कि सुखद भी था। क्रांतिकारी कुछ भी नहीं, सब कुछ बहुत स्पष्ट है, लेकिन तैयार और संक्षेप में ठीक है।

मैं यह नोट करना चाहता हूं कि यह २०१४ का एक लेख है। लेखक द्वारा बताई गई कुछ बहुत ही प्रासंगिक चीजें प्रासंगिकता नहीं खो सकती हैं, लेकिन लेख का सार बिल्कुल नहीं है।

परिचय: क्यों अच्छी टिप्पणियाँ महत्वपूर्ण हैं

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

 $ git log --online -5 --author cbeams --before "Fri Mar 26 2009"

 e5f4b49 r814 में इसके संक्षिप्त हटाने के बाद कॉन्फ़िगरेशनपॉस्टप्रोसेसर को फिर से जोड़ना।  @ TestCglibClassesAreLoadedJustInTimeForEnhancement () विधि को इग्नोर करें क्योंकि यह पता चलता है कि यह हाल ही में निर्माण टूटने में दोषियों में से एक था।  क्लास लोडर हैकिंग के कारण सूक्ष्म बहाव प्रभाव पड़ता है, असंबंधित परीक्षण टूट जाते हैं।  परीक्षण विधि अभी भी उपयोगी है, लेकिन केवल यह सुनिश्चित करने के लिए मैन्युअल आधार पर चलाया जाना चाहिए कि सीजीएलआईबी समय से पहले लोड नहीं किया गया है, और स्वचालित निर्माण के हिस्से के रूप में नहीं चलाया जाना चाहिए।
 2db0f12 ने दो बिल्ड-ब्रेकिंग मुद्दों को तय किया: 794 + को संशोधित करने के लिए ClassMetadataReadingVisitor को रिवर्ट किया गया, जब तक कि अगली जाँच यह निर्धारित नहीं कर देती कि यह डाउनस्ट्रीम परीक्षणों के विफल होने का कारण बनता है (जैसे प्रतीत होता है असंबंधित ClassPathXmlApplicationContextTests) के कारण।
 147709f Tweaks to पैकेज-info.java फाइलें
 22b25e0 समेकित यूटिल और म्यूटेबलऑनटेशन यूटिल्स को मौजूदा एस्मुलेट्स में वर्ग
 7f96f57 पॉलिशिंग

हॉरर। समान रिपॉजिटरी में इन अधिक हाल के कमिट्स के साथ तुलना करें:

 $ git log --online -5 --author pwebb - "सत अगस्त 30 2014"

 5ba3db6 कंपोजिटप्रोपरेटरी सोर्सटैस्ट को ठीक करना
 84564a0 Rework @PropertySource प्रारंभिक पार्सिंग तर्क
 e142fd1 ImportSelector मेटा-डेटा के लिए परीक्षण जोड़ें
 887815f डॉकबुक निर्भरता अपडेट करें और एपब उत्पन्न करें
 ac8326d पोलिश मॉकिटो उपयोग

आप कौन सा विकल्प पसंद करेंगे?

पूर्व की लंबाई और शैली में भिन्नता है, बाद वाले संक्षिप्त और सजातीय हैं।
पहला स्वयं द्वारा प्राप्त किया जाता है, दूसरा सचेत रूप से लिखा जाता है।

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

इन परियोजनाओं में भाग लेने वालों को पता है कि प्रतिबद्ध पर एक अच्छी तरह से लिखित टिप्पणी अन्य डेवलपर्स के लिए किए गए परिवर्तनों के संदर्भ में बताने का सबसे अच्छा तरीका है (साथ ही भविष्य में खुद को भी)। संशोधनों में अंतर दिखाते हैं कि क्या बदल गया है, लेकिन केवल एक टिप्पणी स्पष्ट रूप से बता सकती है कि क्यों । पीटर हंटर ने इसे अच्छी तरह से कहा :

कोडिंग से पुनर्प्राप्त करना समय की बर्बादी है। हम पूरी तरह से इससे बच नहीं सकते हैं, इसलिए हमारे प्रयासों को इन लागतों को कम करने पर ध्यान केंद्रित करना चाहिए। कमेंट्स पर यही टिप्पणी की जाती है। इसलिए, वे बताते हैं कि क्या प्रोग्रामर एक टीम में अच्छा काम करता है।

यदि आपने वास्तव में यह नहीं सोचा है कि पहली दर वाली टिप्पणी क्या होनी चाहिए, तो आपने शायद गिट लॉग और इसी तरह के औजारों का भी उपयोग नहीं किया है। एक दुष्चक्र है: चूंकि आवागमन का इतिहास असंरचित और विषम है, इसलिए वे इसका उपयोग नहीं करते हैं और ध्यान नहीं देते हैं। और इस तथ्य के कारण कि वे इसका उपयोग नहीं करते हैं और ध्यान नहीं देते हैं, यह असंरचित और विषम रहता है।

लेकिन एक अच्छी तरह से डिजाइन की गई रिपॉजिटरी कहानी एक सुंदर और उपयोगी चीज है। आदेश में दोष , उल्टा , पलटाव , लॉग , शोर्टल और अन्य को जीवन में आता है । यह अन्य लोगों के कमिट को देखने और अनुरोधों को खींचने के लिए समझ में आता है, और, अचानक, अब उनके लेखकों की मदद की आवश्यकता नहीं है। यह समझने के लिए कि कुछ महीनों में [कोड में] कुछ साल पहले, यह न केवल संभव हो जाता है, बल्कि सुविधाजनक भी है।

परियोजना की दीर्घकालिक सफलता इस बात पर निर्भर करती है (अन्य बातों के अलावा) कि इसे बनाए रखना कितना सुविधाजनक है, और आवागमन का इतिहास अनुचर के सबसे शक्तिशाली साधनों में से एक है। यह आदेश में रखने के लिए सीखने के लिए समय बिताने के लायक है। पहले तो यह कुछ असुविधा का कारण हो सकता है, लेकिन फिर यह एक आदत बन जाएगा और अंत में, यह सभी प्रतिभागियों के लिए गर्व और उत्पादक कार्य का स्रोत बन जाएगा।

यह लेख केवल एक अच्छी कहानी को बनाए रखने के सबसे बुनियादी घटक पर छूता है, अर्थात्, एक अलग प्रतिबद्ध पर एक टिप्पणी कैसे लिखनी है। अन्य महत्वपूर्ण चीजें हैं, जैसे मर्जिंग कमिट जो यहां कवर नहीं हैं।

अधिकांश प्रोग्रामिंग भाषाओं में आम तौर पर स्वीकार किए जाने वाले सम्मेलनों का वर्णन किया गया है जो एक विशिष्ट शैली बनाते हैं [लेखन कोड], जैसे कि चर नाम, स्वरूपण नियम, और इसी तरह। बेशक, इस तरह के समझौतों के अलग-अलग संस्करण हैं, लेकिन अधिकांश डेवलपर्स की राय है कि एक विकल्प चुनना और इसका पालन करना एक गड़बड़ से बेहतर है जब हर कोई अपनी शैली में लिखता है।

कमिट्स का वर्णन करने के लिए टीम का दृष्टिकोण बिल्कुल वैसा ही होना चाहिए। रिपॉजिटरी कहानी उपयोगी होने के लिए, टीम को कम से कम निम्नलिखित तीन बिंदुओं पर एक समझौते पर आना चाहिए।

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

सामग्री। टिप्पणी के मुख्य भाग में क्या जानकारी (यदि बिलकुल) होनी चाहिए? ऐसा क्यों नहीं होना चाहिए ?

मेटाडाटा। मुझे टास्क आईडी, रिक्वेस्ट नंबरों आदि को कैसे संदर्भित करना चाहिए?

सौभाग्य से, एक सार्थक टिप्पणी लिखने के लिए पहले से ही समझौते हैं। वास्तव में, वे आंशिक रूप से कुछ गिट कमांड के काम करने के तरीके से उपजी हैं। आपको पहिया को सुदृढ़ करने की आवश्यकता नहीं है। बस नीचे दिए गए सात नियमों का पालन करें - और आप एक पेशेवर के योग्य कमिट के इतिहास के करीब एक कदम होंगे।

एक शांत प्रतिबद्ध टिप्पणी के लिए सात नियम

याद रखें: यह सब पहले कहा गया है ।

1. खाली स्ट्रिंग के साथ हेडर को शरीर से अलग करें
2. शीर्षक को 50 अक्षरों तक सीमित रखें
3. शीर्षक को बड़ा करें
4. शीर्षक के अंत में डॉट न लगाएं
5. शीर्षक में अनिवार्यता का प्रयोग करें।
6. 72 अक्षरों के साथ शरीर में अगली पंक्ति पर जाएं
7. शरीर में, क्या और क्यों , और कैसे नहीं के सवालों के जवाब दें

उदाहरण के लिए:

 50 वर्णों या उससे कम के परिवर्तनों को संक्षेप में लिखें

 यहाँ उन्हें और अधिक विस्तार से समझाएँ, यदि आवश्यक हो।  का पालन करें
 लगभग 72 वर्णों की पंक्ति विराम।  कुछ स्थितियों में
 टिप्पणी की पहली पंक्ति को इसका शीर्षक माना जाता है, और सभी 
 बाकी शरीर के साथ है।  एक को दूसरे से अलग करना अत्यावश्यक है
 एक रिक्त स्ट्रिंग (यदि संदेश में एक शरीर है, बिल्कुल);
 `लॉग`,` शॉर्टलॉग` और `रिबेस` जैसे विभिन्न उपकरण समझ में नहीं आएंगे
 अगर हेडर और बॉडी अलग नहीं हुए हैं तो आप।

 यहाँ बताइए कि इससे किस समस्या का समाधान होता है।  दूर ले जाओ 
 इस बात पर अधिक ध्यान दें कि आपने ये परिवर्तन क्यों नहीं किए 
 वास्तव में आपने यह कैसे किया (यह आपके लिए कोड की व्याख्या करेगा)।
 क्या इसमें साइड इफेक्ट्स या अन्य अस्पष्ट प्रभाव हैं 
 ये परिवर्तन  यदि हां, तो इसे यहां स्पष्ट किया जाना चाहिए।

 पैराग्राफ को रिक्त लाइनों द्वारा अलग किया जाता है।

  - आप बुलेटेड लिस्ट कर सकते हैं

  - आमतौर पर एक तारांकन या 
    उनके सामने एक जगह के साथ एक पानी का छींटा  लेकिन अलग समझौते हैं

 यदि आपके पास बग ट्रैकर [या परियोजना प्रबंधन प्रणाली] है,
 इस तरह से टेक्स्ट के अंत में टास्क लिंक डालें:

 हल: # 123
 इसे भी देखें: # 456, # 789

1. खाली स्ट्रिंग के साथ हेडर को शरीर से अलग करें

मैनुअल से गिट कमिट कमांड तक:

हालांकि यह आवश्यक नहीं है, यह एक अच्छा विचार है कि कम से कम एक (कम से कम 50 अक्षर) कमिटमेंट के साथ कमेंट शुरू करने के लिए किए गए बदलावों का सारांश, फिर एक खाली लाइन और फिर एक अधिक विस्तृत विवरण। टिप्पणी में पहली खाली लाइन से पहले पाठ को कमिट का हेडर माना जाता है और इसका उपयोग विभिन्न Git कमांड में किया जाता है। उदाहरण के लिए, Git-format-patch (1) एक प्रतिबद्ध को ईमेल में बदल देता है; टीम पत्र के विषय के लिए प्रतिबद्ध है और पत्र के मुख्य भाग के लिए पाठ के बाकी हिस्सों का उपयोग करती है।

सबसे पहले, हर प्रतिबद्ध को हेडर और बॉडी की आवश्यकता नहीं होती है। कभी-कभी एक पंक्ति पर्याप्त होती है, खासकर जब परिवर्तन इतने छोटे होते हैं कि उनके बारे में कोई अतिरिक्त जानकारी की आवश्यकता नहीं होती है। उदाहरण के लिए:

  उपयोगकर्ता गाइड के परिचय में टाइपो को ठीक करें 

पर्याप्त ने कहा; अगर उपयोगकर्ता यह जानना चाहता है कि टाइपो को किस प्रकार से ठीक किया गया है, तो वह सिर्फ git show या git diff , या git log -p का उपयोग करके स्वयं में होने वाले परिवर्तनों को देख सकता है।

यदि आप कमांड लाइन का उपयोग करके ऐसा कुछ करते हैं, तो यह git प्रतिबद्ध के लिए -m विकल्प का उपयोग करने के लिए सुविधाजनक होगा:

  $ git कमिट -m "उपयोगकर्ता गाइड के परिचय में टाइपो को ठीक करें" 

हालांकि, जब स्थिति की कुछ व्याख्या और विवरण के लिए प्रतिबद्ध है, तो आपको उन्हें टिप्पणी बॉडी में लिखने की आवश्यकता है। उदाहरण के लिए:

 डेरेक मास्टर नियंत्रण कार्यक्रम

 MCP बुराई के रूप में निकला और विश्व वर्चस्व पर इरादे बन गया।
 इसने ट्रोन की डिस्क को MCP में फेंक दिया (इसके व्युत्पन्न के कारण)
 और इसे शतरंज के खेल में बदल देता है।

जिन टिप्पणियों में एक निकाय है, वे -m विकल्प के साथ लिखने के लिए सुविधाजनक नहीं हैं। इसके लिए टेक्स्ट एडिटर का इस्तेमाल करना बेहतर होगा। यदि आपने अभी तक Git के उपयोग के लिए संपादक को कॉन्फ़िगर नहीं किया है, तो प्रो Git पुस्तक के इस भाग को पढ़ें।

किसी भी स्थिति में, लॉग को देखते समय टिप्पणी का शीर्षक और निकाय अलग हो जाएगा। यहाँ पूरा प्रतिबद्ध रिकॉर्ड है:

 $ git लॉग
 प्रतिबद्ध 42e769bdf4894310333942ffc5a15151222a87be
 लेखक: केविन फ्लिन <kevin@flynnsarcade.com>
 दिनांक: शुक्र जनवरी ०१:००:00 १ ९ 200२ -२००

  डेरेक मास्टर नियंत्रण कार्यक्रम

  MCP बुराई के रूप में निकला और विश्व वर्चस्व पर इरादे बन गया।
  इसने ट्रोन की डिस्क को MCP में फेंक दिया (इसके व्युत्पन्न के कारण)
  और इसे शतरंज के खेल में बदल देता है।

और यहाँ git log --online कमांड है , जो केवल हेडर लाइन प्रदर्शित करता है:

 $ git लॉग-ऑनलाइन
 42e769 डेरेक मास्टर नियंत्रण कार्यक्रम

या गिट शॉर्टलॉग, जो समूह लेखक द्वारा फिर से संक्षिप्तता के लिए करता है, केवल शीर्षक दिखाता है:

 $ गिट शार्टलॉग
 केविन फ्लिन (1):
       डेरेक मास्टर नियंत्रण कार्यक्रम

 एलन ब्रेडले (1):
       सुरक्षा कार्यक्रम "ट्रॉन" का परिचय दें

 एड डिलिंजर (3):
       "MCP" को शतरंज कार्यक्रम का नाम दें
       शतरंज कार्यक्रम को संशोधित करें
       शतरंज कार्यक्रम को अपग्रेड करें

 वाल्टर गिब्स (1):
       प्रोटोपे शतरंज कार्यक्रम का परिचय दें

कई अन्य स्थितियां हैं जहां हेडर और कमिट के शरीर के बीच अंतर करना आवश्यक है - और इसके लिए उन्हें एक खाली लाइन द्वारा अलग किया जाना चाहिए।

2. शीर्षक को 50 अक्षरों तक सीमित रखें

तकनीकी रूप से, 50 वर्णों से आगे जाना संभव है, लेकिन अनुशंसित नहीं है। शीर्षक की यह लंबाई इसकी पठनीयता की गारंटी देती है, और यह भी बताती है कि लेखक सबसे संक्षिप्त और स्पष्ट शब्दों के बारे में सोचता है कि क्या हो रहा है।

संकेत: यदि आपके लिए कार्य के परिणामों को संक्षेप में प्रस्तुत करना कठिन है, तो शायद एक प्रतिबद्ध में बहुत अधिक परिवर्तन शामिल हैं। परमाणु करने के लिए कठोर प्रयास (यह एक अलग पद के लिए एक विषय है)।

GitHub का इंटरफ़ेस इन सम्मेलनों का स्पष्ट समर्थन करता है। यदि आप 50 वर्णों की सीमा से बाहर जाते हैं तो वह आपको चेतावनी देगा:


और एक दीर्घवृत्त को प्रतिस्थापित करते हुए, 72 वर्णों से अधिक लंबे हेडर को काटें:


इसलिए 50 पात्रों का लक्ष्य रखें, लेकिन ध्यान रखें कि 72 एक सख्त प्रतिबंध है।

3. शीर्षक को बड़ा करें

यहां सब कुछ सरल है। सभी शीर्षकों को बड़ा करें।

उदाहरण के लिए:

• प्रति घंटे 88 मील तक तेजी

बजाय:

• 88 मील प्रति घंटे की रफ्तार

4. शीर्षक के अंत में डॉट न लगाएं

इसकी कोई जरूरत नहीं है। इसके अलावा, जब हम 50 को पूरा करने की कोशिश करते हैं तो प्रत्येक वर्ण मायने रखता है।

उदाहरण के लिए:

• पॉड बे दरवाजे खोलें

बजाय:

• पॉड बे दरवाजे खोलें।

5. शीर्षक में अनिवार्यता का प्रयोग करें।

इंपीरियल मूड का शाब्दिक अर्थ है: एक क्रिया का एक रूप जिसमें इच्छा (आदेश, अनुरोध या सलाह) व्यक्त की जाती है। कुछ उदाहरण:

• अपना कमरा साफ करें (कमरे को साफ करें)
• दरवाजा बंद करो
• कचरा बाहर निकालो

जिन सात नियमों के बारे में आप पढ़ रहे हैं उनमें से प्रत्येक अनिवार्य मनोदशा में लिखा गया है ("72 वर्णों के साथ शरीर में अगली पंक्ति पर जाएं", आदि)।

यह फ़ॉर्म थोड़ा अशिष्ट लग सकता है, और इसलिए अक्सर इसका उपयोग नहीं किया जाता है [अंग्रेजी में - लगभग। प्रति। ]। लेकिन यह प्रतिबद्ध हेडर के लिए एकदम सही है। एक कारण यह है कि आपकी ओर से कमिट होने पर Git खुद को जरूरी इस्तेमाल करता है।
उदाहरण के लिए, git मर्ज का उपयोग करते समय , निम्न संदेश डिफ़ॉल्ट रूप से जोड़ा जाएगा:

 मर्ज शाखा 'myfeature'

और जब git रिवर्ट का उपयोग कर रहे हों:

 "सामान के साथ चीज़ जोड़ें" वापस लाएँ
	
 यह श्रद्धा cc87791524aedd593cff5a74532befe7ab69ce9d प्रतिबद्ध है।

या जब आप GitHub पर पुल अनुरोध इंटरफ़ेस में "मर्ज" बटन पर क्लिक करते हैं:

 Someuser / somebranch से मर्ज पुल अनुरोध # 123

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

• पठनीयता के लिए रिफलेक्टर सबसिस्टम एक्स
• अद्यतन शुरू कर रहा है प्रलेखन
• हटाए गए तरीकों को हटा दें
• रिलीज़ संस्करण 1.0.0

यह तरीका पहली बार असहज लग सकता है। हम संकेत का उपयोग करने के लिए अधिक उपयोग किए जाते हैं, जो तथ्यों की रिपोर्ट करने की अधिक संभावना है। इसलिए, प्रतिबद्ध संदेश अक्सर कुछ इस तरह से निकलते हैं:

• वाई के साथ फिक्स्ड बग
• X का व्यवहार बदलना

और कभी-कभी हेडर कमिट की सामग्री का वर्णन करते हैं:

• टूटे हुए सामान के लिए अधिक सुधार
• मीठे नए एपीआई तरीके

एक सरल नियम है जो आपको गलतियों से बचने की अनुमति देगा।

एक अच्छी तरह से बना प्रतिबद्ध हैडर को निम्नलिखित वाक्य पूरा करना चाहिए:

• यदि लागू किया जाता है, तो यह प्रतिबद्धता < प्रतिबद्ध हेडर > होगी

उदाहरण के लिए:

• यदि लागू किया जाता है, तो यह प्रतिबद्धता पठनीयता के लिए सबसिस्टम एक्स को रिफलेक्टर करेगी
• यदि लागू किया जाता है, तो यह कमिट शुरू हो जाएगा प्रलेखन शुरू हो जाएगा
• यदि लागू किया जाता है, तो यह कमिट हटाए गए तरीकों को हटा देगा
• यदि लागू किया जाता है, तो यह प्रतिबद्ध संस्करण 1.0.0 जारी करेगा

यदि लागू किया जाता है, तो यह प्रतिबद्धता उपयोगकर्ता / शाखा से पुल अनुरोध # 123 का विलय करेगी

सुनिश्चित करें कि क्रिया अन्य में नहीं, अनिवार्य नहीं, मूड यहां काम नहीं करते हैं:

• यदि लागू किया जाता है, तो यह प्रतिबद्ध वाई के साथ बग को ठीक कर देगा
• यदि लागू किया जाता है, तो यह प्रतिबद्धता एक्स के व्यवहार को बदल देगी
• यदि लागू किया जाता है, तो यह प्रतिबद्ध टूटे हुए सामान के लिए अधिक सुधार करेगा
• यदि लागू किया जाता है, तो यह प्रतिबद्ध नए एपीआई तरीकों को मीठा करेगा

याद रखें: अनिवार्यता का उपयोग केवल कमिट के हेडर में महत्वपूर्ण है। कमिट के शरीर में, यह वैकल्पिक है।

6. 72 वर्णों के साथ शरीर में अगली पंक्ति पर जाएं

गिट खुद ही लाइन ब्रेक की व्यवस्था नहीं करता है। टिप्पणी निकाय का संपादन करते समय, आपको सही बॉर्डर याद रखना चाहिए और मैन्युअल रूप से लाइन ब्रेक सेट करना चाहिए।

यह अनुशंसा की जाती है कि आप 72 वर्णों के साथ अगली पंक्ति में जाएं ताकि Git इंडेंट कर सके और अभी भी कुल 80 वर्णों को फिट कर सके।

एक अच्छा टेक्स्ट एडिटर इसमें मदद कर सकता है। कमिट में संदेश लिखने के लिए 72 अक्षरों को फीड करने के लिए विम, को कॉन्फ़िगर करना, कहना बहुत आसान है। हालाँकि, ऐसा हुआ कि मैसेज कमिट के लिए स्मार्ट लाइन ब्रेक का समर्थन करने पर IDE बहुत खराब हैं (हालांकि IntelliJ IDEA के नवीनतम संस्करण इस भाग में बेहतर हो गए हैं)। ( लगभग प्रति। - शायद इस समय सब कुछ बहुत बेहतर है )।

7. शरीर में, सवालों का जवाब "क्या" और "क्यों", "कैसे" नहीं

बिटकॉइन रिपॉजिटरी की यह प्रतिबद्धता यह बताती है कि क्या और क्यों बदल गया है:

 प्रतिबद्ध eb0b56b19017ab5c16c745e6da39c53126924ed6
 लेखक: पीटर वूइल <pieter.wuille@gmail.com>
 दिनांक: शुक्र अगस्त १२:५२:५५ २०१४ +०२००

    सरलीकृत सरलीकृत करें। इसके अपवाद को संभालना

    Serialize.h की स्ट्रीम से 'स्टेट' और 'एक्सटर्मास्क' निकालें
    कार्यान्वयन, साथ ही संबंधित तरीके।

    जैसा कि अपवादों में हमेशा 'फेलबिट' शामिल होता है, और सेटस्टेट हमेशा था
    बिट्स = फेलबिट के साथ बुलाया गया था, यह सब तुरंत किया गया था ए बढ़ा
    अपवाद।  उन चर से छुटकारा पाएं, और सेटस्टेट की जगह लें
    प्रत्यक्ष अपवाद फेंकने के साथ (जो कुछ मृतकों को भी हटाता है
    कोड)।

    परिणामस्वरूप, विफलता के बाद कभी भी अच्छा () नहीं पहुंचता है
    केवल 2 कॉल, जिनमें से एक परीक्षण में है), और बस बदला जा सकता है
    द्वारा; ईओएफ ()।

    असफल (), स्पष्ट (n) और अपवाद () केवल कभी नहीं कहे जाते हैं।  हटाएं
    उन्हें।

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

ज्यादातर मामलों में, आप इस विवरण को छोड़ सकते हैं कि परिवर्तन कैसे किए गए थे। आमतौर पर, कोड इस अर्थ में खुद के लिए बोलता है (और यदि यह इतना जटिल है कि स्पष्टीकरण की आवश्यकता है, तो इसमें इसके लिए टिप्पणियां हैं)।

मुख्य रूप से यह समझाने पर ध्यान दें कि परिवर्तन क्यों किए गए थे - परिवर्तन करने से पहले स्थिति का वर्णन करें (और इसके साथ क्या गलत था), स्थिति के बाद, और आपने समस्या को हल करने का यह विशेष तरीका क्यों चुना।

शायद भविष्य में आप इसके लिए खुद को धन्यवाद देंगे!

युक्तियाँ

कमांड लाइन को प्यार करो। आईडीई के बारे में भूल गया।

कई कारण हैं - Git कमांड की संख्या द्वारा - कमांड लाइन का अधिकतम उपयोग करने के लिए। गिट एक बेहद शक्तिशाली उपकरण है; आईडीई - भी, लेकिन प्रत्येक अपने तरीके से। मैं हर दिन IntelliJ IDEA का उपयोग करता हूं, मुझे अक्सर दूसरों के साथ व्यवहार करना पड़ता था (उदाहरण के लिए, ग्रहण), लेकिन मैंने कभी नहीं देखा कि IDE में Git के एकीकरण की तुलना सरलता और क्षमताओं से कमांड लाइन तक की जा सकती है (जैसे ही इसे समझें)।

संस्करण नियंत्रण के लिए आईडीई की कुछ विशेषताएं बस अमूल्य हैं, उदाहरण के लिए, जब आप फ़ाइल का नाम हटाते हैं, तो आप स्वचालित रूप से गिट rm निष्पादित करते हैं या जब आप इसका नाम बदल देते हैं तो अन्य आवश्यक गिट टुकड़े। लेकिन यह बहुत बुरा होता है जब आप आईडीई का उपयोग करके कमिट्स के इतिहास को कमिट करने, मर्ज करने, रिबेस करने या करने का जटिल विश्लेषण करते हैं।

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

प्रो गिट बुक पढ़ें

शानदार प्रो गिट बुक ( रूसी में भी - लगभग। अनुवाद ) स्वतंत्र रूप से उपलब्ध है। इसका फायदा उठाएं!