गिट-कमिट - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

गिट-कमिट - रिपॉजिटरी में परिवर्तन रिकॉर्ड करें

SYNOPSIS

Git करना [-ए | --इंटरैक्टिव | --पैच] [-एस] [-वी] [-यू ] [--सुधार करना]
[--ड्राई-रन] [(-सी | -सी | --फिक्सअप | --स्क्वैश) ]
[-एफ | -एम ] [--रीसेट-लेखक] [--अनुमति-खाली]
[--अनुमति-खाली-संदेश] [--कोई-सत्यापन नहीं] [-ई] [--लेखक= ]
[--दिनांक= ] [--सफाई= ] [--[कोई स्थिति नहीं]
[-मैं | -ओ] [-एस[ ]] [--] [ ...]

वर्णन

इंडेक्स की वर्तमान सामग्री को लॉग संदेश के साथ एक नई कमिट में संग्रहीत करता है
उपयोगकर्ता परिवर्तनों का वर्णन कर रहा है।

जोड़ी जाने वाली सामग्री को कई तरीकों से निर्दिष्ट किया जा सकता है:

1. प्रयोग करके Git जोड़ना उपयोग करने से पहले अनुक्रमणिका में क्रमिक रूप से परिवर्तन "जोड़ें"। करना
आदेश (नोट: संशोधित फ़ाइलें भी "जोड़ी जानी चाहिए");

2. प्रयोग करके Git rm वर्किंग ट्री और इंडेक्स से फ़ाइलें हटाने के लिए, पहले भी
का उपयोग करना आदेश;

3. फ़ाइलों को तर्क के रूप में सूचीबद्ध करके करना आदेश, जिस स्थिति में प्रतिबद्धता होगी
सूचकांक में किए गए परिवर्तनों को अनदेखा करें, और इसके बजाय की वर्तमान सामग्री को रिकॉर्ड करें
सूचीबद्ध फ़ाइलें (जो Git को पहले से ही ज्ञात होनी चाहिए);

4. -a स्विच का उपयोग करके करना सभी में से परिवर्तनों को स्वचालित रूप से "जोड़ने" का आदेश
ज्ञात फ़ाइलें (अर्थात वे सभी फ़ाइलें जो पहले से ही अनुक्रमणिका में सूचीबद्ध हैं) और स्वचालित रूप से
इंडेक्स में "आरएम" फ़ाइलें जिन्हें कार्यशील ट्री से हटा दिया गया है, और फिर निष्पादित करें
वास्तविक प्रतिबद्धता;

5. --इंटरएक्टिव या --पैच स्विच का उपयोग करके करना एक निर्णय लेने का आदेश
अंतिम रूप देने से पहले, कौन सी फ़ाइलें या हंक प्रतिबद्धता का हिस्सा होना चाहिए
संचालन। का "इंटरएक्टिव मोड" अनुभाग देखें git-जोड़ें(1) काम करना सीखना
ये मोड.

इनमें से किसी में क्या शामिल है इसका सारांश प्राप्त करने के लिए --ड्राई-रन विकल्प का उपयोग किया जा सकता है
पैरामीटर (विकल्प और पथ) का एक ही सेट देकर अगली प्रतिबद्धता के लिए ऊपर।

यदि आप कोई प्रतिबद्धता बनाते हैं और उसके तुरंत बाद कोई गलती ढूंढ लेते हैं, तो आप उससे उबर सकते हैं
इसके साथ Git रीसेट करें.

विकल्प

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

-पी, --पैच
कौन सा परिवर्तन करना है यह चुनने के लिए इंटरैक्टिव पैच चयन इंटरफ़ेस का उपयोग करें। देखना
git-जोड़ें(२९) विवरण के लिए।

-सी , --पुन: उपयोग-संदेश=
एक मौजूदा प्रतिबद्ध ऑब्जेक्ट लें, और लॉग संदेश और लेखकत्व का पुन: उपयोग करें
कमिट बनाते समय जानकारी (टाइमस्टैम्प सहित)।

-सी , --रीडिट-संदेश=
पसंद -C, लेकिन इसके साथ -c संपादक को लागू किया जाता है, ताकि उपयोगकर्ता इसे आगे संपादित कर सके
प्रतिबद्ध संदेश.

--फिक्सअप=
रिबेस --ऑटोस्क्वैश के साथ उपयोग के लिए एक प्रतिबद्ध संदेश बनाएं। प्रतिबद्ध संदेश होगा
"फिक्सअप!" के उपसर्ग के साथ निर्दिष्ट प्रतिबद्धता से विषय पंक्ति बनें। देखना गिट-
रिबेस(२९) विवरण के लिए।

--स्क्वैश=
रिबेस --ऑटोस्क्वैश के साथ उपयोग के लिए एक प्रतिबद्ध संदेश बनाएं। प्रतिबद्ध संदेश
विषय पंक्ति निर्दिष्ट कमिट से "स्क्वैश!" के उपसर्ग के साथ ली गई है। हो सकता है
अतिरिक्त प्रतिबद्ध संदेश विकल्पों (-m/-c/-C/-F) के साथ उपयोग किया जाता है। देखना git-rebase(1) के लिए
विवरण।

--रीसेट-लेखक
जब -C/-c/--संशोधन विकल्पों के साथ प्रयोग किया जाता है, या एए विरोधाभासी होने के बाद प्रतिबद्ध होता है
चेरी-पिक, घोषणा करें कि परिणामी प्रतिबद्धता का लेखकत्व अब उसी का है
कमिटर. यह लेखक टाइमस्टैम्प को भी नवीनीकृत करता है।

--कम
ड्राई-रन करते समय आउटपुट को शॉर्ट-फॉर्मेट में दें। देखना git-स्थिति(1) के लिए
विवरण। तात्पर्य--ड्राई-रन।

--डाली
शाखा और ट्रैकिंग जानकारी संक्षिप्त प्रारूप में भी दिखाएं।

--चीनी मिटटी
ड्राई-रन करते समय, आउटपुट को चीनी मिट्टी के-तैयार प्रारूप में दें। देखना git-स्थिति(1)
जानकारी के लिए। तात्पर्य--ड्राई-रन।

--लंबा
ड्राई-रन करते समय, आउटपुट को लंबे प्रारूप में दें। तात्पर्य--ड्राई-रन।

-ज़, --शून्य
लघु या चीनी मिट्टी स्थिति आउटपुट दिखाते समय, स्थिति आउटपुट में प्रविष्टियाँ समाप्त करें
एलएफ के बजाय एनयूएल के साथ। यदि कोई प्रारूप नहीं दिया गया है, तो इसका तात्पर्य --पोर्सिलेन आउटपुट प्रारूप से है।

-एफ , --फ़ाइल=
दी गई फ़ाइल से कमिट संदेश लें। उपयोग - से संदेश पढ़ने के लिए
मानक इनपुट।

--लेखक=
प्रतिबद्ध लेखक को ओवरराइड करें. मानक एयू थोर का उपयोग करके एक स्पष्ट लेखक निर्दिष्ट करें
<[ईमेल संरक्षित]> प्रारूप. अन्यथा इसे एक पैटर्न माना जाता है और इसका उपयोग किया जाता है
उस लेखक द्वारा मौजूदा प्रतिबद्धता की खोज करने के लिए (यानी rev-list --all -i
--लेखक= ); इसके बाद कमिट लेखक को ऐसे पहले मिले कमिट से कॉपी किया जाता है।

--दिनांक=
कमिट में प्रयुक्त लेखक दिनांक को ओवरराइड करें।

-एम , --संदेश=
दिए गए का प्रयोग करें प्रतिबद्ध संदेश के रूप में. यदि एकाधिक -m विकल्प दिए गए हैं, तो उनका
मानों को अलग-अलग अनुच्छेदों के रूप में संयोजित किया गया है।

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

-एस, --साइनऑफ
कमिट लॉग संदेश के अंत में कमिटर द्वारा साइन-ऑफ-बाय लाइन जोड़ें।
साइनऑफ़ का अर्थ प्रोजेक्ट पर निर्भर करता है, लेकिन यह आम तौर पर उस कमिटर को प्रमाणित करता है
के पास इस कार्य को उसी लाइसेंस के तहत सबमिट करने का अधिकार है और वह डेवलपर से सहमत है
उत्पत्ति का प्रमाण पत्र (देखें) http://developercertificate.org/ अधिक जानकारी के लिए)।

-n, --नहीं-सत्यापित करें
यह विकल्प प्री-कमिट और कमिट-एमएसजी हुक को बायपास करता है। यह सभी देखें गीथूक(5).

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

--अनुमति-खाली-संदेश
जैसे --allow-empty यह कमांड मुख्य रूप से विदेशी SCM इंटरफ़ेस स्क्रिप्ट द्वारा उपयोग के लिए है।
यह आपको प्लंबिंग का उपयोग किए बिना एक खाली कमिट संदेश के साथ एक कमिट बनाने की अनुमति देता है
जैसे आदेश गिट-प्रतिबद्ध-वृक्ष(1).

--सफाई=
यह विकल्प निर्धारित करता है कि आपूर्ति किए गए प्रतिबद्ध संदेश को पहले कैसे साफ़ किया जाना चाहिए
प्रतिबद्ध. पट्टी, रिक्त स्थान, शब्दशः, कैंची या डिफ़ॉल्ट हो सकता है।

पट्टी
स्ट्रिप अग्रणी और अनुगामी खाली पंक्तियाँ, अनुगामी रिक्त स्थान, कमेंटरी और
लगातार खाली पंक्तियों को संक्षिप्त करें।

खाली स्थान के
#कमेंटरी को छोड़कर स्ट्रिप के समान ही नहीं हटाया जाता है।

शब्दशः
मैसेज बिल्कुल न बदलें.

कैंची
रिक्त स्थान के समान, सिवाय इसके कि पंक्ति "#" से (और इसमें शामिल) सब कुछ
---------------------- >8 ---------------------- "यदि संदेश छोटा कर दिया गया है
संपादित किया जाना है. "#" को core.commentChar के साथ अनुकूलित किया जा सकता है।

चूक
यदि संदेश को संपादित करना है तो स्ट्रिप के समान। अन्यथा रिक्त स्थान.

डिफ़ॉल्ट को इसके द्वारा बदला जा सकता है प्रतिबद्ध.सफाई विन्यास चर (देखें गिट-
विन्यास(1))।

-e, --edit
संदेश -F के साथ फ़ाइल से, -m के साथ कमांड लाइन से, और कमिट ऑब्जेक्ट से लिया गया है
-सी का उपयोग आमतौर पर अनमॉडिफाइड कमिट लॉग संदेश के रूप में किया जाता है। यह विकल्प आपको आगे बढ़ने की सुविधा देता है
इन स्रोतों से लिए गए संदेश को संपादित करें.

--कोई संपादन न करें
किसी संपादक को लॉन्च किए बिना चयनित प्रतिबद्ध संदेश का उपयोग करें। उदाहरण के लिए, गिट कमिट
--amend --no-edit किसी कमिट के कमिट संदेश को बदले बिना उसमें संशोधन करता है।

--संशोधन
एक नई कमिट बनाकर वर्तमान शाखा की नोक को बदलें। दर्ज पेड़ है
हमेशा की तरह तैयार किया गया (-i और -o विकल्पों के प्रभाव और स्पष्ट सहित)।
पाथस्पेक), और मूल कमिट से संदेश को शुरुआती बिंदु के रूप में उपयोग किया जाता है,
खाली संदेश के बजाय, जब कमांड लाइन से कोई अन्य संदेश निर्दिष्ट नहीं किया जाता है
-m, -F, -c, आदि जैसे विकल्पों के माध्यम से। नई प्रतिबद्धता में वही माता-पिता और लेखक हैं
वर्तमान वाला (--reset-author विकल्प इसका प्रतिवाद कर सकता है)।

यह इसके लिए एक मोटा समकक्ष है:

$ गिट रीसेट--सॉफ्ट हेड^
$...सही पेड़ तैयार करने के लिए कुछ और करें...
$ गिट कमिट -सी ORIG_HEAD

लेकिन मर्ज कमिट में संशोधन के लिए इसका उपयोग किया जा सकता है।

यदि आप किसी प्रतिबद्धता में संशोधन करते हैं तो आपको इतिहास को फिर से लिखने के निहितार्थ को समझना चाहिए
पहले ही प्रकाशित हो चुका है. ("अपस्ट्रीम रीबेस से पुनर्प्राप्ति" अनुभाग देखें गिट-
रिबेस(1)।)

--नहीं-पोस्ट-पुनर्लेखन
पोस्ट-रीराइट हुक को बायपास करें।

-मैं शामिल करता हूँ
अब तक चरणबद्ध सामग्री से प्रतिबद्धता बनाने से पहले, पथों की सामग्री को चरणबद्ध करें
कमांड लाइन पर भी दिया गया है। यह आमतौर पर वह नहीं है जो आप चाहते हैं जब तक कि आप ऐसा न करें
एक विवादित विलय का समापन।

-ओ, --केवल
निर्दिष्ट पथों की अद्यतन कार्यशील ट्री सामग्री लेकर एक प्रतिबद्धता बनाएं
अन्य पथों के लिए मंचित की गई किसी भी सामग्री की उपेक्षा करते हुए कमांड लाइन।
यह ऑपरेशन का डिफ़ॉल्ट मोड है Git करना यदि कोई पथ दिया गया है
कमांड लाइन, ऐसी स्थिति में इस विकल्प को छोड़ा जा सकता है। यदि यह विकल्प निर्दिष्ट है
साथ साथ --संशोधन, तो कोई पथ निर्दिष्ट करने की आवश्यकता नहीं है, जिसका उपयोग संशोधन के लिए किया जा सकता है
पहले से ही चरणबद्ध परिवर्तनों के बिना अंतिम प्रतिबद्धता।

-यू[ ], --अनट्रैक्ड-फ़ाइलें[= ]
ट्रैक न की गई फ़ाइलें दिखाएं.

मोड पैरामीटर वैकल्पिक है (डिफ़ॉल्ट रूप से)। सब), और हैंडलिंग निर्दिष्ट करने के लिए उपयोग किया जाता है
ट्रैक न की गई फ़ाइलों का; जब -u का उपयोग नहीं किया जाता है, तो डिफ़ॉल्ट होता है साधारण, यानी अनट्रैक्ड दिखाएं
फ़ाइलें और निर्देशिकाएँ।

संभावित विकल्प हैं:

· नहीं - कोई भी अनट्रैक की गई फ़ाइलें न दिखाएं

· साधारण - ट्रैक न की गई फ़ाइलें और निर्देशिकाएँ दिखाता है

· सब - ट्रैक न की गई निर्देशिकाओं में अलग-अलग फ़ाइलें भी दिखाता है।

status.showUntrackedFiles कॉन्फ़िगरेशन का उपयोग करके डिफ़ॉल्ट को बदला जा सकता है
वैरिएबल को प्रलेखित किया गया है गिट-कॉन्फ़िगरेशन(1).

-v, --verbose
HEAD कमिट और उसके नीचे क्या कमिट किया जाएगा, के बीच एकीकृत अंतर दिखाएं
प्रतिबद्ध संदेश टेम्पलेट उपयोगकर्ता को क्या याद दिलाकर प्रतिबद्धता का वर्णन करने में मदद करता है
प्रतिबद्धता में परिवर्तन होता है। ध्यान दें कि इस भिन्न आउटपुट में इसकी पंक्तियाँ उपसर्ग नहीं हैं
साथ में #. यह अंतर प्रतिबद्ध संदेश का हिस्सा नहीं होगा.

यदि दो बार निर्दिष्ट किया गया है, तो जो प्रतिबद्ध किया जाएगा उसके बीच एकीकृत अंतर भी दिखाएं
और वर्कट्री फ़ाइलें, यानी ट्रैक की गई फ़ाइलों में अस्थिर परिवर्तन।

-क्यू, --शांत
प्रतिबद्ध सारांश संदेश को दबाएँ.

--पूर्वाभ्यास
कोई कमिट न बनाएँ, बल्कि उन रास्तों की सूची दिखाएँ जिनके लिए कमिट किया जाना है, वे रास्ते जिनके साथ
स्थानीय परिवर्तन जो अप्रतिबद्ध छोड़ दिए जाएंगे और पथ जो ट्रैक नहीं किए गए हैं।

--स्थिति
का आउटपुट शामिल करें git-स्थिति(1) कमिट मैसेज टेम्प्लेट में एक का उपयोग करते समय
प्रतिबद्ध संदेश तैयार करने के लिए संपादक। डिफ़ॉल्ट रूप से चालू है, लेकिन ओवरराइड करने के लिए इसका उपयोग किया जा सकता है
कॉन्फ़िगरेशन वैरिएबल कमिट.स्टेटस।

--कोई स्थिति नहीं
का आउटपुट शामिल न करें git-स्थिति(1) उपयोग करते समय प्रतिबद्ध संदेश टेम्पलेट में
डिफ़ॉल्ट प्रतिबद्ध संदेश तैयार करने के लिए एक संपादक।

-एस[ ], --gpg-चिह्न[= ]
जीपीजी-साइन कमिट करता है। keyid तर्क वैकल्पिक है और कमिटर के लिए डिफ़ॉल्ट है
पहचान; यदि निर्दिष्ट किया गया है, तो इसे बिना स्थान के विकल्प के साथ चिपका दिया जाना चाहिए।

--नहीं-gpg-चिह्न
काउंटरमैंड प्रतिबद्ध.gpgसाइन कॉन्फ़िगरेशन वैरिएबल जो प्रत्येक को बाध्य करने के लिए सेट है
हस्ताक्षर करने के लिए प्रतिबद्ध है।

--
किसी और तर्क की व्याख्या विकल्प के रूप में न करें।

...
जब फ़ाइलें कमांड लाइन पर दी जाती हैं, तो कमांड की सामग्री को प्रतिबद्ध करता है
नामित फ़ाइलें, पहले से चरणबद्ध परिवर्तनों को रिकॉर्ड किए बिना। इन फ़ाइलों की सामग्री
पहले जो मंचन किया गया है उसके शीर्ष पर अगली प्रतिबद्धता के लिए भी मंचन किया जाता है।

DATE प्रारूप

GIT_AUTHOR_DATE, GIT_COMMITTER_DATE पर्यावरण चर और --दिनांक विकल्प
निम्नलिखित दिनांक स्वरूपों का समर्थन करें:

गिट आंतरिक प्रारूप
यह है , कहां की संख्या है
UNIX युग के बाद से सेकंड। एक सकारात्मक या नकारात्मक ऑफसेट है
यूटीसी से। उदाहरण के लिए सीईटी (जो यूटीसी से 2 घंटे आगे है) +0200 है।

RFC 2822
RFC 2822 द्वारा वर्णित मानक ईमेल प्रारूप, उदाहरण के लिए गुरु, 07 अप्रैल 2005
22:13:13 +0200।

आईएसओ 8601
आईएसओ 8601 मानक द्वारा निर्दिष्ट समय और तारीख, उदाहरण के लिए 2005-04-07T22:13:13। NS
पार्सर टी वर्ण के बजाय एक स्थान भी स्वीकार करता है।

नोट
इसके अलावा, दिनांक भाग निम्नलिखित प्रारूपों में स्वीकार किया जाता है: YYYY.MM.DD,
MM/DD/YYYY और DD.MM.YYYY।

उदाहरण

अपना स्वयं का कार्य रिकॉर्ड करते समय, आपके कार्यशील ट्री में संशोधित फ़ाइलों की सामग्री होती है
अस्थायी रूप से एक स्टेजिंग क्षेत्र में संग्रहीत किया जाता है जिसे "इंडेक्स" कहा जाता है Git जोड़ना. एक फ़ाइल हो सकती है
केवल इंडेक्स में, लेकिन वर्किंग ट्री में नहीं, अंतिम कमिट पर वापस लौटाया गया
गिट रीसेट हेड के साथ - , जो प्रभावी रूप से वापस लौटता है Git जोड़ना और परिवर्तनों को रोकता है
इस फ़ाइल को अगली प्रतिबद्धता में भाग लेने से। बनने वाले राज्य के निर्माण के बाद
इन आदेशों के साथ क्रमिक रूप से प्रतिबद्ध, गिट कमिट (बिना किसी पथनाम पैरामीटर के)
अब तक जो मंचन किया गया है उसे रिकॉर्ड करने के लिए उपयोग किया जाता है। यह कमांड का सबसे बुनियादी रूप है.
एक उदाहरण:

$ संपादित करें hello.c
$ गिट आरएम अलविदा.सी
$ git hello.c जोड़ें
$ गिट प्रतिबद्ध

प्रत्येक व्यक्तिगत परिवर्तन के बाद फ़ाइलों को व्यवस्थित करने के बजाय, आप git कमिट को नोटिस करने के लिए कह सकते हैं
उन फ़ाइलों में परिवर्तन जिनकी सामग्री आपके कार्यशील ट्री में ट्रैक की जाती है और करते हैं
आपके लिए संगत git ऐड और git rm। अर्थात्, यह उदाहरण वैसा ही करता है
यदि आपके कार्यशील वृक्ष में कोई अन्य परिवर्तन नहीं है तो पहले का उदाहरण:

$ संपादित करें hello.c
$ आरएम अलविदा.सी
$ git कमिट -a

कमांड git कमिट -ए सबसे पहले आपके वर्किंग ट्री को देखता है, नोटिस करता है कि आपने संशोधित किया है
hello.c और अलविदा.c को हटा दिया, और आपके लिए आवश्यक git ऐड और git rm निष्पादित करता है।

कई फ़ाइलों में परिवर्तनों को व्यवस्थित करने के बाद, आप परिवर्तनों को रिकॉर्ड किए जाने के क्रम को बदल सकते हैं,
गिट कमिट को पथनाम देकर। जब पथनाम दिए जाते हैं, तो कमांड एक प्रतिबद्धता बनाता है
जो केवल नामित पथों में किए गए परिवर्तनों को रिकॉर्ड करता है:

$ संपादित करें hello.c hello.h
$ git hello.c hello.h जोड़ें
$ मेकफ़ाइल संपादित करें
$ गिट कमिट मेकफ़ाइल

यह एक कमिट बनाता है जो मेकफ़ाइल में संशोधन को रिकॉर्ड करता है। परिवर्तन के लिए मंचन किया गया
परिणामी प्रतिबद्धता में hello.c और hello.h शामिल नहीं हैं। हालाँकि, उनके परिवर्तन हैं
खोए नहीं हैं - वे अभी भी मंचित हैं और केवल रोके हुए हैं। उपरोक्त क्रम के बाद यदि आप
कर:

$ गिट प्रतिबद्ध

यह दूसरी प्रतिबद्धता अपेक्षा के अनुरूप hello.c और hello.h में परिवर्तन रिकॉर्ड करेगी।

विलय के बाद (द्वारा शुरू किया गया) Git मर्ज or Git खींच) झगड़ों के कारण रुक जाता है, साफ़-साफ़
मर्ज किए गए पथ आपके लिए प्रतिबद्ध होने के लिए पहले से ही चरणबद्ध हैं, और जो पथ परस्पर विरोधी हैं वे हैं
अविलीन अवस्था में छोड़ दिया गया। आपको पहले यह जांचना होगा कि कौन से पथ परस्पर विरोधी हैं Git
हैसियत और उन्हें अपने कार्यशील ट्री में मैन्युअल रूप से ठीक करने के बाद, आप परिणाम को इस प्रकार चरणबद्ध करेंगे
हमेशा की तरह Git जोड़ना:

$ गिट स्थिति | ग्रेप अविलय
असंबद्ध: हेलो.सी
$ संपादित करें hello.c
$ git hello.c जोड़ें

विरोधों को हल करने और परिणाम का मंचन करने के बाद, git ls-files -u का उल्लेख करना बंद हो जाएगा
संघर्षपूर्ण मार्ग. जब आपका काम पूरा हो जाए, तो अंत में मर्ज को रिकॉर्ड करने के लिए git कमिट चलाएँ:

$ गिट प्रतिबद्ध

अपने स्वयं के परिवर्तनों को रिकॉर्ड करने के मामले में, आप टाइपिंग को सहेजने के लिए -a विकल्प का उपयोग कर सकते हैं। एक
अंतर यह है कि मर्ज रिज़ॉल्यूशन के दौरान, आप पथनामों के साथ गिट कमिट का उपयोग नहीं कर सकते हैं
परिवर्तन किए जाने के क्रम को बदलें, क्योंकि मर्ज को एक के रूप में दर्ज किया जाना चाहिए
एकल प्रतिबद्धता. वास्तव में, पथ नाम दिए जाने पर कमांड चलने से इंकार कर देता है (लेकिन -i देखें)।
विकल्प)।

चर्चा

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

गिट कुछ हद तक चरित्र एन्कोडिंग अज्ञेयवादी है।

· बूँद वस्तुओं की सामग्री बाइट्स के निर्बाध अनुक्रम हैं। कोई नहीं है
कोर स्तर पर एन्कोडिंग अनुवाद।

पथ के नाम UTF-8 नॉर्मलाइज़ेशन फॉर्म C में एन्कोड किए गए हैं। यह ट्री ऑब्जेक्ट्स पर लागू होता है,
कमांड लाइन तर्कों में अनुक्रमणिका फ़ाइल, रेफरी नाम, साथ ही पथ नाम,
पर्यावरण चर और कॉन्फ़िगरेशन फ़ाइलें (.git/config (देखें .) गिट-कॉन्फ़िगरेशन(1), गिटिग्नोर(5)
gitattributes(5) और गिटमॉड्यूल्स(5))।

ध्यान दें कि मुख्य स्तर पर गिट पथ नामों को केवल गैर-एनयूएल के अनुक्रम के रूप में मानता है
बाइट्स, कोई पथ नाम एन्कोडिंग रूपांतरण नहीं हैं (मैक और विंडोज को छोड़कर)।
इसलिए, गैर-ASCII पथ नामों का उपयोग करना अधिकतर प्लेटफ़ॉर्म और फ़ाइल पर भी काम करेगा
सिस्टम जो विरासती विस्तारित ASCII एन्कोडिंग का उपयोग करते हैं। हालांकि, पर बनाए गए भंडार
ऐसे सिस्टम UTF-8-आधारित सिस्टम (जैसे Linux, Mac, Windows) पर ठीक से काम नहीं करेंगे।
और इसके विपरीत। इसके अतिरिक्त, कई गिट-आधारित टूल बस पथ नामों को मानते हैं
UTF-8 और अन्य एन्कोडिंग को सही ढंग से प्रदर्शित करने में विफल रहेगा।

प्रतिबद्ध लॉग संदेश आमतौर पर यूटीएफ -8 में एन्कोड किए जाते हैं, लेकिन अन्य विस्तारित एएससीआईआई एन्कोडिंग
भी समर्थित हैं। इसमें ISO-8859-x, CP125x और कई अन्य शामिल हैं, लेकिन नहीं
UTF-16/32, EBCDIC और CJK मल्टी-बाइट एन्कोडिंग (GBK, Shift-JIS, Big5, EUC-x, CP9xx)
और इतने पर).

हालांकि हम प्रोत्साहित करते हैं कि प्रतिबद्ध लॉग संदेश यूटीएफ -8 में एन्कोड किए गए हैं, दोनों कोर और
गिट चीनी मिट्टी के बरतन को परियोजनाओं पर यूटीएफ -8 को मजबूर नहीं करने के लिए डिज़ाइन किया गया है। यदि a . के सभी प्रतिभागी
विशेष परियोजना को विरासत एन्कोडिंग का उपयोग करना अधिक सुविधाजनक लगता है, गिट मना नहीं करता है
यह। हालाँकि, कुछ बातों का ध्यान रखना चाहिए।

1. Git करना और Git प्रतिबद्ध वृक्ष यदि प्रतिबद्ध लॉग संदेश दिया गया है तो चेतावनी जारी करता है
मान्य UTF-8 स्ट्रिंग की तरह नहीं दिखता है, जब तक कि आप स्पष्ट रूप से नहीं कहते कि आपकी परियोजना a . का उपयोग करती है
विरासत एन्कोडिंग। इसे कहने का तरीका यह है कि .git/config . में i18n.commitencoding हो
फ़ाइल, इस तरह:

[i18n]
कमिटेंकोडिंग = आईएसओ-8859-1

उपरोक्त सेटिंग के साथ बनाए गए कमिट ऑब्जेक्ट i18n.commitencoding के मान को रिकॉर्ड करते हैं
इसके एन्कोडिंग हेडर में। यह अन्य लोगों की मदद करने के लिए है जो उन्हें बाद में देखते हैं। की कमी
इस हेडर का तात्पर्य है कि प्रतिबद्ध लॉग संदेश यूटीएफ -8 में एन्कोड किया गया है।

2. Git लॉग इन, Git दिखाना, Git दोष और दोस्त कमिट के एन्कोडिंग हेडर को देखते हैं
ऑब्जेक्ट, और लॉग संदेश को यूटीएफ -8 में फिर से कोड करने का प्रयास करें जब तक कि अन्यथा निर्दिष्ट न हो। आप
.git/config . में i18n.logoutputencoding के साथ वांछित आउटपुट एन्कोडिंग निर्दिष्ट कर सकते हैं
फ़ाइल, इस तरह:

[i18n]
लॉगआउटपुटनकोडिंग = आईएसओ-8859-1

यदि आपके पास यह कॉन्फ़िगरेशन चर नहीं है, तो i18n.commitencoding का मान है
इसके बजाय इस्तेमाल किया।

ध्यान दें कि हमने जानबूझकर प्रतिबद्ध लॉग संदेश को फिर से कोड नहीं करना चुना है जब एक प्रतिबद्ध है
यूटीएफ -8 को प्रतिबद्ध वस्तु स्तर पर मजबूर करने के लिए बनाया गया है, क्योंकि यूटीएफ -8 को फिर से कोडिंग नहीं है
अनिवार्य रूप से एक प्रतिवर्ती ऑपरेशन।

वातावरण और विन्यास चर

प्रतिबद्ध लॉग संदेश को संपादित करने के लिए उपयोग किए जाने वाले संपादक को GIT_EDITOR से चुना जाएगा
पर्यावरण चर, कोर.एडिटर कॉन्फ़िगरेशन चर, विज़ुअल वातावरण
चर, या EDITOR पर्यावरण चर (उसी क्रम में)। देखना git-वर(२९) विवरण के लिए।

हुक

यह कमांड कमिट-एमएसजी, प्रिपेयर-कमिट-एमएसजी, प्री-कमिट और पोस्ट-कमिट हुक चला सकता है।
देख गीथूक(5) अधिक जानकारी के लिए।

onworks.net सेवाओं का उपयोग करके ऑनलाइन git-commit का उपयोग करें