हैशमार्क (#) के साथ एक जीआईटी प्रतिबद्ध संदेश शुरू करें

Question

Git #कमेंट करते समय शुरू होने वाली लाइनों को कमेंट के रूप में मानता है । टिकट ट्रैकिंग सिस्टम के साथ काम करते समय, और लाइन की शुरुआत में टिकट नंबर लिखने की कोशिश करना बहुत ही कष्टप्रद होता है, जैसे

#123 salt hashed passwords

git बस कमिट मैसेज से लाइन हटा देगा। क्या हैश से बचने का कोई तरीका है? मैंने कोशिश की \और !, लेकिन कुछ भी नहीं काम करता है। पहले व्हॉट्सएप #संरक्षित हैं, इसलिए वे समस्या का समाधान नहीं कर रहे हैं।

Comments

@AlexBudovski क्योंकि संक्षिप्तता में मूल्य है।

— ज़वी

१. (.२ (फरवरी २०१३) git के बाद से, git config core.commentcharउस टिप्पणी वर्ण को कॉन्फ़िगर करने की अनुमति देता है। देखें नीचे मेरा उत्तर

— VonC

चूंकि Git v2.0.0 (2014.05.21) git commit --cleanup=scissorsअधिक लचीला होगा। मेरे जवाब

— सुंगम

मुझे कहना चाहिए, मुझे आश्चर्य है कि गीथहब लोगों ने इस समस्या के बारे में नहीं सोचा था जब उन्होंने इश्यू के साथ अंक संख्याओं को चिह्नित करने का फैसला किया था!

— माइकल स्कीपर

@ मिचेल निष्पक्ष होने के लिए, इस सम्मेलन का उपयोग पहले से ही मंटिस, ट्राक, रेडमाइन और शायद अन्य लोगों द्वारा किया जाता था। मुझे लगता है कि गिटहब ने पहिया को फिर से स्थापित करने के बजाय इसका पालन करने का फैसला किया। देखें stackoverflow.com/questions/40495/…

— केल्विन

Answer 1

यह व्यवहार git commit'डिफ़ॉल्ट' क्लीन-अप व्यवहार का हिस्सा है। यदि आप लाइनों को अपने साथ रखना चाहते हैं, तो आप #एक वैकल्पिक क्लीन-अप मोड का उपयोग कर सकते हैं।

उदाहरण के लिए

git commit --cleanup=whitespace

यदि आप ऐसा करते हैं तो आपको उन सभी #लाइनों को हटाने के लिए सावधान रहना होगा जो आप कमिटमेंट में प्रकट नहीं करना चाहते हैं।

Comments

अगला सवाल यह है: मैं उन प्रतिबद्ध संदेश टिप्पणियों को कहां संपादित कर सकता हूं जो git का परिचय देती हैं जो डिफ़ॉल्ट रूप से # के साथ शुरू होती हैं?

— एलेक्स

@ एलेक्स: यह commit.templateगिट कॉन्फ़िगरेशन चर द्वारा नियंत्रित किया जाता है ।

— सीबी बेली

मौजूदा कमिट्स में संशोधन के लिए भी यह बढ़िया काम करता है। जैसे:git commit --amend --cleanup=whitespace

— जेम्स एंड्रेस

@CharlesBailey: मैं जीआईटी कमिट / देव / अशक्त के साथ पूर्वनिर्धारित पाठ से छुटकारा पाने की उम्मीद कर रहा था, लेकिन यह अभी भी दिखा रहा है कि

— एलेक्स 12

जैसा कि आप "# 123 कमिट मैसेज" के साथ-साथ मैक और सोर्सट्री के लिए GitHub जैसे ग्राहकों के कमेंट मेसेज करने में सक्षम हैं, मुझे लगता है कि ये क्लाइंट हाँ क्या कर रहे हैं?

— फिल ओस्लर

Answer 2

ध्यान दें कि, git1.8.2 (फरवरी 2013) के बाद से , आप #प्रतिबद्ध संदेश में टिप्पणी लाइन के लिए ' ' की तुलना में एक अलग चरित्र का उपयोग कर सकते हैं ।

यह आपको #अपने बग नंबर संदर्भ के लिए ' ' का उपयोग करने की अनुमति देता है ।

विभिन्न "संकेत" लाइनें Git देती हैं जब वह उपयोगकर्ता से संपादक में संदेशों को संपादित करने के लिए कहता है तो #डिफ़ॉल्ट रूप से ' ' के साथ टिप्पणी की जाती है।

core.commentCharविन्यास चर इस 'अनुकूलित करने के लिए इस्तेमाल किया जा सकता #एक अलग चरित्र के लिए'।

---

सिद्धांत रूप में, आप एक शब्द (कई अक्षर) रख सकते हैंcore.commentChar , लेकिन git 2.0.x / 2.1 सख्त (Q3 2014) होगा।

देखें 50b54fd द्वारा Nguy 50n Thái Ngc Duy ( pclouds) :

config: core.commentChar पर सख्त हो

हम कमेंट स्ट्रिंग्स का समर्थन नहीं करते (कम से कम अभी तक नहीं)। और मल्टी-बाइट कैरेक्टर एन्कोडिंग का भी गलत मतलब निकाला जा सकता है।

दो कॉमा के साथ परीक्षण अपडेट किया जाता है क्योंकि यह इसका उल्लंघन करता है। यह पैच के साथ जोड़ा गया है जो कि eff80a9 में पेश core.commentCharकरता है (कस्टम "टिप्पणी चार" - 2013-01-16 की अनुमति दें)। यह मेरे लिए स्पष्ट नहीं है कि वह व्यवहार क्यों चाहता है।

---

git 2.0.x / 2.1 (Q3 2014) के लिए एक स्वत: चयन जोड़ देगा core.commentChar:
देखें प्रतिबद्ध 84c9dc2

जब core.commentChar" auto" होता है, तो टिप्पणी चार #डिफ़ॉल्ट रूप में ' ' से शुरू होती है, लेकिन यदि यह पहले से ही तैयार संदेश में है, तो एक छोटा सा उपसेट में दूसरा चार ढूंढें। यह आश्चर्य को रोकना चाहिए क्योंकि गिट अप्रत्याशित रूप से कुछ लाइनों को स्ट्रिप्स करता है।

ध्यान दें कि git इतनी स्मार्ट नहीं है कि ' #' को कस्टम टेम्पलेट में टिप्पणी चार के रूप में पहचाना जा सके और अंतिम टिप्पणी चार भिन्न होने पर इसे परिवर्तित किया जा सके।
यह कस्टम टेम्प्लेट में '#' लाइनों को प्रतिबद्ध संदेश का हिस्सा मानता है। इसलिए कस्टम टेम्पलेट के साथ इसका उपयोग न करें।

"ऑटो" के लिए उम्मीदवार के पात्रों की सूची है:

# ; @ ! $ % ^ & | :

इसका मतलब है कि कमांड जैसी git commit -m '#1 fixed issue'टिप्पणी स्वचालित रूप से कमेंट को ' ;' में बदल देगी , क्योंकि ' #' का प्रयोग कमिट मेसेज में किया गया था।

Comments

इसके बाद सिंटैक्स HL को ठीक करने के लिए, इस संबंधित प्रश्न को देखें: stackoverflow.com/questions/16164624/…

— Alois Mahdal

@ सच, ​​मैंने यह दर्शाने के लिए उत्तर दिया है।

— वॉनसी

@newbyca git के किस संस्करण के साथ आप देखते हैं कि इंटरेक्टिव रिबेस के दौरान समर्थित नहीं है?

— वॉनसी

तो, यह निर्धारित करने के लिए आप कर सकते हैं, जैसे:$ git config --global core.commentchar ';'

— davetapley

मुझे यह जवाब पसंद है। : नया सुझाव दिया समाधान के लिए Onelinergit config --global core.commentChar auto

— aross

Answer 3

यहाँ उत्तर अच्छे और विस्तृत हैं, लेकिन git noob जैसे मेरे लिए git config ऑप्शन को कस्टमाइज़ करना इतना स्पष्ट नहीं है। यहाँ से बदलने के लिए एक उदाहरण है #करने के लिए ;टिप्पणी पात्रों के लिए:

git config core.commentChar ";"

बस आपको इतना ही करना है।

Comments

यह डिफ़ॉल्ट टिप्पणी वाले पाठ को भी बदल देता है जो एक प्रतिबद्ध संदेश git commitको संपादित करने के लिए जब एक कॉन्फ़िगर संदेश को खोलने के लिए उपयोग करता है तो git एक प्रतिबद्ध संदेश में जोड़ता है !

— माइकल ट्रू

वन-ऑफ़ फ़िक्सेस के लिए, इसका उपयोग करें: git -c core.commentChar="|" commit --amend( |जो आप चाहते हैं उसे बदलें )।

— दरोगाओं

Answer 4

आप कमांड लाइन विकल्प का उपयोग कर सकते हैं -m:

git commit -m "#123 fixed"

Comments

लेकिन यह एक भयानक प्रतिबद्ध संदेश है। यह सुनिश्चित करना सुनिश्चित करें कि बग क्या था और यह कैसे तय किया गया था

— अच्छा व्यक्ति

प्रतिबद्ध संदेश ठीक है जब तक बग की एक संख्या है

— ट्रिडेंट

नहीं अगर बग ट्रैकिंग सिस्टम अचानक भ्रष्ट हो जाता है और आपके पास बैकअप नहीं है! :)

— caveman_dick

Answer 5

यदि आप एक इंटरैक्टिव रिबेस कर रहे हैं, तो जब आप इसमें कुछ नहीं के साथ अपने प्रतिबद्ध संदेश को बचाते हैं (क्योंकि #शुरुआत में यह एक टिप्पणी की है और इसलिए इसे नजरअंदाज कर दिया गया है) git आपको दिखाएगा कि क्या करना है:

Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

इसलिए, केवल संदेश में संशोधन करें:

git commit --amend -m "#123 salt hashed passwords"

और रिबास जारी रखें:

git rebase --continue

Comments

यह किसी ऐसे व्यक्ति के लिए सही है, जिसने पहले ही कमिट को धक्का दे दिया है, लेकिन संदेश बदलना चाहते हैं

— होआंग त्रिनह

यदि आप अपने संपादक का उपयोग करके कोई संदेश दर्ज करते हैं, तो यह नए तरीकों पर भी लागू होता है।

— ओवेन विलियम्स

Answer 6

git commit --cleanup=scissorsइस्तेमाल किया जाना चाहिए। यह 2014.05.21 को Git v2.0.0 में जोड़ा गया है

से git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

Comments

मुझे समझ में नहीं आता है कि यह कैसे कमेंटरी के द्वारा उपयोग करने commit.cleanup = whitespaceऔर हटाने से बेहतर है # …, जैसा कि @CharlesBailey ने पहले ही सुझाया है। scissors-मोड बस इसके अलावा git format-patch/ mailinfo/ द्वारा उपयोग किए जाने वाले कैंची-सिंटैक्स को साफ करता है am; संदेशों को कमेंट्री में जोड़ने पर यह वाक्य रचना का उपयोग नहीं करता है…-- >8 --… ।

— स्लिप डी। थॉम्पसन

1. मुझे लगता है कि यह बेहतर है क्योंकि मुझे " # ...कमेंट्री-हार्ड को हटाने" की आवश्यकता नहीं है । 2. मैं आपकी टिप्पणी के दूसरे भाग के बारे में निश्चित नहीं हूं, scissorsमोड निश्चित रूप से है git commit --help। आप किस संस्करण का gitउपयोग कर रहे हैं? @ स्लिप्ड.टॉमप्सन

— सुंगम

है ना? whitespaceमोड 1. अग्रणी और खाली लाइनों की अनुगामी प्रदान करता है, 2. अनुगामी व्हाट्सएप, 3. लगातार खाली रेखाओं का ढहना। scissors1. प्रमुख लाइनों को अलग करना और खाली लाइनों का अनुगमन करना, 2. व्हॉट्सएप को पीछे छोड़ना, 3. लगातार खाली लाइनों को गिराना, 4. लाइन से (और सहित) सब कुछ # -…- >8 -…-। हालाँकि, कैंची लाइनें ( # -…- >8 -…-) केवल git-format-patch/ mailinfo/ का उपयोग करते समय डाली जाती हैं am। इसलिए एक सामान्य git-commit/ merge/ rebase/ cherry-pickवर्कफ़्लो के लिए, scissorsस्ट्रिपिंग मोड मोड पर शून्य लाभ प्रदान करता whitespaceहै। v2.11.0

— स्लिप डी। थॉम्पसन

@ SlippD.Thompson आप किस संस्करण का उपयोग कर रहे हैं? मैं 2.8.3 का उपयोग कर रहा है और git commit --cleanup=scissors करता है पहले जोड़ें # ------------------------ >8 ------------------------से पहले लाइन git statusकी जानकारी। नीचे की तरह: `# ------------------------> 8 ------------------- ----- # ऊपर की रेखा को स्पर्श न करें। # नीचे सब कुछ हटा दिया जाएगा। # ब्रांच मास्टर पर # शुरुआती

— कमिटमेंट

मेरा मानना ​​है कि मैं इस के नीचे करने के लिए मिल गया है। Git वास्तव # ------------------------ >8 ------------------------में स्थिति txt से पहले सम्मिलित करता है "ऐसा लगता है जैसे आप हो सकते हैं ..." _ का उपयोग करते समय scissors; तथापि, यह कैंची पंक्ति का अंतर डाल के बाद# Conflicts: … पाठ। मैंने अपने में commit.status = falseसेट किया था .gitconfig, इसलिए मुझे कोई भी स्टेटस टेक्स्ट नहीं दिख रहा था, केवल कॉनफ्लिक्ट टेक्स्ट। मुझे सही साबित होना है; upvote में बदल रहा है।

— स्लिप डी। थॉम्पसन

Answer 7

टिकट नंबर के लिए एक अलग उपसर्ग का उपयोग करें। या "बग # 42" जैसे टिकट नंबर के लिए एक शब्द प्रस्तुत करें। या लाइन के लिए एक एकल अंतरिक्ष चरित्र प्रस्तुत करना; यदि आप उस व्हाट्सएप को हटाना चाहते हैं तो आप इसके लिए एक कमिट जोड़ सकते हैं।

मैं व्यक्तिगत रूप से इस तरह के कमिट मैसेज मैनिपुलेशन को हुक द्वारा नहीं करना चाहूंगा क्योंकि जब आप इसे नहीं चाहते हैं तो यह बहुत परेशान कर सकता है। सबसे आसान उपाय शायद समस्या पर फिर से विचार करना है।

Comments

समस्या के लिए अलग शब्दांकन केवल एक समाधान है। यदि परियोजना दिशानिर्देश कहते हैं कि टिकट आईडी के साथ एक प्रतिबद्ध संदेश शुरू होना चाहिए, तो यह काम नहीं करेगा। और बाद का हुक बहुत बदसूरत है। मुझे लगता है कि मुझे यह "बग" गिट डेवलपर्स को रिपोर्ट करना चाहिए

— 739'10

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

— विल्हेमटेल

git के कमिट मैसेज में एस्केप कैरेक्टर्स को सपोर्ट करना इतना बड़ा काम नहीं होगा

— knittl

यह पूरी तरह से उचित सुविधा अनुरोध है। विशेष रूप से इस तथ्य के प्रकाश में कि Trac, AFAICT, एक बग स्लिप के लिए प्रतिबद्ध नहीं है यदि प्रतिबद्ध संदेश स्लिप नंबर से शुरू नहीं होता है, जो हैश से शुरू होता है। तो यह सिर्फ किसी के मानकों का नहीं है, यह एक उपकरण का आवश्यक सिंटैक्स है। Git devs को यह तय करने दें कि वह सार्थक है या नहीं। (और हां, Trac भी समस्या को ठीक कर सकता है। इस बात का अनुरोध करने में कुछ भी गलत नहीं है कि Git वह भी कर सकता है।)

— ल्यूक मौरर

"विशेष रूप से इस तथ्य के प्रकाश में कि ट्राक, एएफएआईसीटी, एक बग स्लिप के लिए प्रतिबद्ध नहीं है, अगर प्रतिबद्ध संदेश स्लिप नंबर से शुरू नहीं होता है, तो हैश से शुरू होता है।" - Trac के साथ मेरे सीमित अनुभव #xxxमें, कमिट मैसेज में कहीं भी होने जैसा कुछ मुद्दा जुड़ेगा। यह कमिट की शुरुआत में होना जरूरी नहीं है। शायद यह कुछ ऐसा है जो पिछले पांच वर्षों में बदल गया है?

— गिल्डनस्टर्न

Answer 8

मेरे सभी आवागमन शुरू होते हैं #issueNumberइसलिए मैंने इस बॉयलरप्लेट को अपने पास रखा vim .git/hooks/commit-msg:

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

तो मान लें कि हमारी शाखा है #15और हम प्रतिबद्ध संदेश देते हैं add new awesome feature। इस दृष्टिकोण के साथ अंतिम प्रतिबद्ध संदेश होगा #15 add new awesome feature।