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

कार्यक्रम:

नाम

गिट-मर्ज - दो या दो से अधिक विकास इतिहासों को एक साथ जोड़ें

SYNOPSIS

Git मर्ज [-एन] [--स्टेट] [--नो-कमिट] [--स्क्वैश] [--[नहीं-]संपादित करें]
[-एस ] [-एक्स ] [-एस[ ]]
[--[नहीं-]rerere-autoupdate] [-m ] [ ...]
Git मर्ज सिर ...
Git मर्ज --गर्भपात

वर्णन

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

मान लें कि निम्नलिखित इतिहास मौजूद है और वर्तमान शाखा "मास्टर" है:

ए---बी---सी टॉपिक
/
डी---ई---एफ---जी मास्टर

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

ए---बी---सी टॉपिक
/ \ _
डी---ई---एफ---जी---एच मास्टर

दूसरा वाक्यविन्यास ( सिर ...) ऐतिहासिक कारणों से समर्थित है। उपयोग नहीं करो
इसे कमांड लाइन से या नई स्क्रिप्ट में। यह git मर्ज -m जैसा ही है
....

तीसरा सिंटैक्स ("git merge --abort") मर्ज के परिणामित होने के बाद ही चलाया जा सकता है
संघर्ष। Git मर्ज --गर्भपात मर्ज प्रक्रिया को निरस्त कर देगा और पुनर्निर्माण का प्रयास करेगा
विलय पूर्व स्थिति. हालाँकि, यदि मर्ज शुरू होने पर अप्रतिबद्ध परिवर्तन थे (और)
विशेष रूप से यदि विलय शुरू होने के बाद उन परिवर्तनों को और संशोधित किया गया था), Git मर्ज
--गर्भपात कुछ मामलों में मूल (विलय-पूर्व) परिवर्तनों का पुनर्निर्माण करने में असमर्थ होगा।
इसलिए:

चेतावनी: दौड़ना Git मर्ज गैर-तुच्छ अप्रतिबद्ध परिवर्तनों के साथ हतोत्साहित किया जाता है: जबकि
संभव है, यह आपको ऐसी स्थिति में छोड़ सकता है जहां से पीछे हटना मुश्किल होगा
संघर्ष।

विकल्प

--प्रतिबद्ध, --नहीं-प्रतिबद्ध
मर्ज करें और परिणाम प्रतिबद्ध करें। इस विकल्प का उपयोग ओवरराइड करने के लिए किया जा सकता है
--कोई प्रतिबद्धता नहीं.

--नो-कमिट के साथ मर्ज निष्पादित करें लेकिन मर्ज विफल होने का दिखावा करें और ऑटोकमिट न करें,
उपयोगकर्ता को पहले मर्ज परिणाम का निरीक्षण करने और उसमें और सुधार करने का मौका देने के लिए
प्रतिबद्ध.

--संपादित करें, -ई, --नहीं-संपादन
आगे संपादित करने के लिए सफल यांत्रिक विलय करने से पहले एक संपादक को आमंत्रित करें
स्वतः उत्पन्न मर्ज संदेश, ताकि उपयोगकर्ता मर्ज को समझा और उचित ठहरा सके।
--नो-एडिट विकल्प का उपयोग ऑटो-जनरेटेड संदेश को स्वीकार करने के लिए किया जा सकता है (यह आम तौर पर होता है
हतोत्साहित)। यदि आप ड्राफ्ट दे रहे हैं तो --edit (या -e) विकल्प अभी भी उपयोगी है
कमांड लाइन से -m विकल्प के साथ संदेश और इसे संपादक में संपादित करना चाहते हैं।

पुरानी स्क्रिप्ट उपयोगकर्ता को संपादित करने की अनुमति न देने के ऐतिहासिक व्यवहार पर निर्भर हो सकती हैं
मर्ज लॉग संदेश. जब वे गिट मर्ज चलाएंगे तो उन्हें एक संपादक खुला हुआ दिखाई देगा। बनाने के लिए
ऐसी स्क्रिप्ट को अद्यतन व्यवहार, पर्यावरण चर के अनुसार समायोजित करना आसान होता है
GIT_MERGE_AUTOEDIT को उनके आरंभ में नहीं पर सेट किया जा सकता है।

--ff
जब मर्ज फास्ट-फॉरवर्ड के रूप में हल हो जाता है, तो केवल शाखा सूचक को अपडेट करें
एक मर्ज कमिट बनाना। यह पहले गलत व्यवहार है।

--नो-एफएफ
मर्ज कमिट तब भी बनाएं जब मर्ज फास्ट-फॉरवर्ड के रूप में हल हो जाए। यह है
एनोटेटेड (और संभवतः हस्ताक्षरित) टैग को मर्ज करते समय डिफ़ॉल्ट व्यवहार।

--ff-केवल
जब तक वर्तमान HEAD पहले से ही मौजूद न हो, तब तक गैर-शून्य स्थिति के साथ विलय करने और बाहर निकलने से इनकार करें
अप-टू-डेट या मर्ज को फास्ट-फॉरवर्ड के रूप में हल किया जा सकता है।

--लॉग[= ], --नो-लॉग
शाखा नामों के अलावा, लॉग संदेश को एक-पंक्ति विवरण से भरें
अधिक से अधिक वास्तविक प्रतिबद्धताएँ जिनका विलय किया जा रहा है। यह सभी देखें git-fmt-मर्ज-संदेश(1).

--नो-लॉग के साथ मर्ज किए जा रहे वास्तविक कमिट्स से एक-पंक्ति विवरण सूचीबद्ध न करें।

--स्टेट, -एन, --नो-स्टेट
मर्ज के अंत में एक डिफस्टेट दिखाएं। डिफस्टैट को भी इसके द्वारा नियंत्रित किया जाता है
कॉन्फ़िगरेशन विकल्प मर्ज.स्टेट।

-n या --no-stat के साथ मर्ज के अंत में एक डिफस्टेट नहीं दिखता है।

--स्क्वैश, --नो-स्क्वैश
कार्यशील वृक्ष और अनुक्रमणिका स्थिति का निर्माण ऐसे करें जैसे कि कोई वास्तविक विलय हुआ हो (सिवाय इसके
जानकारी मर्ज करें), लेकिन वास्तव में कोई प्रतिबद्धता न बनाएं, HEAD को स्थानांतरित न करें, या रिकॉर्ड न करें
$GIT_DIR/MERGE_HEAD (मर्ज कमिट बनाने के लिए अगला git कमिट कमांड उत्पन्न करने के लिए)।
यह आपको वर्तमान शाखा के शीर्ष पर एक एकल कमिट बनाने की अनुमति देता है जिसका प्रभाव है
किसी अन्य शाखा के विलय के समान (या ऑक्टोपस के मामले में अधिक)।

--नो-स्क्वैश के साथ मर्ज करें और परिणाम दें। इस विकल्प का उपयोग किया जा सकता है
ओवरराइड--स्क्वैश।

-एस , --रणनीति=
दी गई मर्ज रणनीति का उपयोग करें; में उन्हें निर्दिष्ट करने के लिए एक से अधिक बार आपूर्ति की जा सकती है
आदेश दें कि उन पर मुकदमा चलाया जाए। यदि कोई -s विकल्प नहीं है, तो रणनीतियों की एक अंतर्निहित सूची है
इसके बजाय उपयोग किया गया (Git मर्ज-पुनरावर्ती एकल शीर्ष का विलय करते समय, Git मर्ज-ऑक्टोपस
अन्यथा)।

-एक्स , --रणनीति-विकल्प=
मर्ज रणनीति के माध्यम से मर्ज रणनीति विशिष्ट विकल्प पास करें।

--सत्यापित-हस्ताक्षर, --नहीं-सत्यापित-हस्ताक्षर
सत्यापित करें कि विलय की जा रही प्रतिबद्धताओं में अच्छे और विश्वसनीय जीपीजी हस्ताक्षर हैं और निरस्त करें
ऐसा न होने की स्थिति में विलय।

--सारांश, --कोई सारांश नहीं
--stat और --no-stat के पर्यायवाची; इन्हें बहिष्कृत कर दिया गया है और इन्हें हटा दिया जाएगा
भविष्य।

-क्यू, --शांत
चुपचाप काम करो. तात्पर्य - कोई प्रगति नहीं।

-v, --verbose
वर्बोज़ बनें।

--प्रगति, --नहीं-प्रगति
प्रगति को स्पष्ट रूप से चालू/बंद करें। यदि कोई भी निर्दिष्ट नहीं है, तो प्रगति दिखाई जाती है
मानक त्रुटि एक टर्मिनल से जुड़ी है। ध्यान दें कि सभी मर्ज रणनीतियाँ नहीं हो सकतीं
प्रगति रिपोर्टिंग का समर्थन करें.

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

-एम
मर्ज कमिट के लिए उपयोग किए जाने वाले कमिट संदेश को सेट करें (यदि कोई बनाया गया है)।

यदि --लॉग निर्दिष्ट किया गया है, तो मर्ज किए जा रहे कमिट्स का एक शॉर्टलॉग इसमें जोड़ा जाएगा
निर्दिष्ट संदेश.

RSI Git एफएमटी-मर्ज-संदेश स्वचालित के लिए एक अच्छा डिफ़ॉल्ट देने के लिए कमांड का उपयोग किया जा सकता है Git
मर्ज मंगलाचरण. स्वचालित संदेश में शाखा विवरण शामिल हो सकता है।

--[नहीं-]रेरेरे-ऑटोअपडेट
रेरेरे तंत्र को ऑटो-संघर्ष के परिणाम के साथ सूचकांक को अद्यतन करने की अनुमति दें
यदि संभव हो तो समाधान.

--गर्भपात
वर्तमान विरोध समाधान प्रक्रिया को निरस्त करें, और पूर्व-विलय को फिर से बनाने का प्रयास करें
राज्य.

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

Git मर्ज --गर्भपात के बराबर है Git रीसेट करें --मर्ज जब MERGE_HEAD मौजूद हो.

...
आमतौर पर अन्य शाखा प्रमुख हमारी शाखा में विलय के लिए प्रतिबद्ध होते हैं। से अधिक निर्दिष्ट करना
एक प्रतिबद्धता दो से अधिक माता-पिता (स्नेह से एक कहा जाता है) के साथ एक विलय बनाएगी
ऑक्टोपस मर्ज)।

यदि कमांड लाइन से कोई कमिट नहीं दिया गया है, तो रिमोट-ट्रैकिंग शाखाओं को मर्ज करें
वर्तमान शाखा को इसके अपस्ट्रीम के रूप में उपयोग करने के लिए कॉन्फ़िगर किया गया है। कॉन्फ़िगरेशन भी देखें
इस मैनुअल पृष्ठ का अनुभाग.

जब FETCH_HEAD (और कोई अन्य प्रतिबद्धता नहीं) निर्दिष्ट किया जाता है, तो शाखाएं रिकॉर्ड की जाती हैं
विलय के लिए git फ़ेच के पिछले आह्वान द्वारा .git/FETCH_HEAD फ़ाइल में विलय कर दिया गया है
वर्तमान शाखा.

पूर्व विलय निरीक्षण

बाहरी परिवर्तन लागू करने से पहले, आपको अपना काम अच्छी स्थिति में और प्रतिबद्ध होना चाहिए
स्थानीय स्तर पर, इसलिए विवाद होने पर इसे रोका नहीं जाएगा। यह सभी देखें git-stash(1). Git
खींच और Git मर्ज स्थानीय अप्रतिबद्ध परिवर्तन ओवरलैप होने पर कुछ भी किए बिना रुक जाएगा
उन फ़ाइलों के साथ Git खींच/Git मर्ज अद्यतन करने की आवश्यकता हो सकती है.

मर्ज कमिट में असंबंधित परिवर्तनों को रिकॉर्ड करने से बचने के लिए, Git खींच और Git मर्ज यह भी होगा
यदि HEAD कमिट के सापेक्ष सूचकांक में कोई परिवर्तन पंजीकृत है तो निरस्त करें। (एक
अपवाद तब होता है जब परिवर्तित सूचकांक प्रविष्टियाँ उस स्थिति में होती हैं जिसके परिणामस्वरूप होगा
पहले से ही विलय।)

यदि सभी नामित कमिट पहले से ही HEAD के पूर्वज हैं, Git मर्ज के साथ जल्दी बाहर निकल जायेंगे
संदेश "पहले से ही अद्यतित।"

तेजी से आगे बढ़ना मर्ज

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

इस व्यवहार को --no-ff विकल्प से दबाया जा सकता है।

जब सही है मर्ज

तेजी से आगे बढ़ने वाले विलय (ऊपर देखें) को छोड़कर, विलय की जाने वाली शाखाओं को बांधा जाना चाहिए
एक मर्ज कमिट द्वारा एक साथ, जिसके माता-पिता के रूप में ये दोनों हैं।

विलय की जाने वाली सभी शाखाओं से परिवर्तनों को समेटने वाला एक मर्ज किया गया संस्करण प्रतिबद्ध है, और
आपके HEAD, इंडेक्स और वर्किंग ट्री को इसमें अपडेट किया जाता है। संशोधन होना संभव है
कार्यशील वृक्ष में जब तक वे ओवरलैप न हों; अद्यतन उन्हें सुरक्षित रखेगा.

जब यह स्पष्ट नहीं होता कि परिवर्तनों का समाधान कैसे किया जाए, तो निम्न होता है:

1. हेड पॉइंटर वही रहता है।

2. MERGE_HEAD रेफरी को अन्य शाखा प्रमुख की ओर इंगित करने के लिए सेट किया गया है।

3. जो पथ साफ़-साफ़ मर्ज हो गए हैं, उन्हें इंडेक्स फ़ाइल और आपके कार्यशील ट्री दोनों में अपडेट किया जाता है।

4. परस्पर विरोधी पथों के लिए, इंडेक्स फ़ाइल तीन संस्करणों तक रिकॉर्ड करती है: चरण 1 संग्रहीत करता है
सामान्य पूर्वज से संस्करण, HEAD से चरण 2, और MERGE_HEAD से चरण 3 (आप
git ls-files -u) के साथ चरणों का निरीक्षण कर सकते हैं। कार्यशील ट्री फ़ाइलों में शामिल हैं
"विलय" कार्यक्रम का परिणाम; यानी परिचित संघर्ष मार्करों के साथ 3-तरफा विलय परिणाम
<<< === >>>.

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

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

विलय टैग

किसी एनोटेटेड (और संभवतः हस्ताक्षरित) टैग को मर्ज करते समय, Git हमेशा एक मर्ज कमिट बनाता है
भले ही फास्ट-फॉरवर्ड मर्ज संभव हो, और प्रतिबद्ध संदेश टेम्पलेट तैयार किया गया हो
टैग संदेश. इसके अतिरिक्त, यदि टैग पर हस्ताक्षर किया गया है, तो हस्ताक्षर जांच को एक के रूप में रिपोर्ट किया जाता है
संदेश टेम्पलेट में टिप्पणी करें. यह सभी देखें git-टैग(1).

जब आप काम के साथ एकीकृत होना चाहते हैं तो प्रतिबद्धता की ओर ले जाते हैं
टैग किया गया, उदाहरण के लिए अपस्ट्रीम रिलीज़ पॉइंट के साथ सिंक्रोनाइज़ करना, हो सकता है कि आप इसे बनाना न चाहें
अनावश्यक मर्ज प्रतिबद्धता.

ऐसे मामले में, आप गिट मर्ज, या पास में फीड करने से पहले टैग को स्वयं "अनरैप" कर सकते हैं
--ff-केवल तभी जब आपके पास अपना कोई काम न हो। उदाहरण के लिए

गिट फ़ेच मूल
गिट मर्ज v1.2.3^0
गिट मर्ज --एफएफ-केवल v1.2.3

कैसे संघर्ष हैं पेश किया

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

डिफ़ॉल्ट रूप से, Git उसी शैली का उपयोग करता है जो RCS से "मर्ज" प्रोग्राम द्वारा उपयोग की जाती है
इस तरह के एक विरोधाभासी हंक को प्रस्तुत करने के लिए सूट, इस तरह:

यहां ऐसी रेखाएं हैं जो या तो सामान्य से अपरिवर्तित हैं
पूर्वज, या साफ़-साफ़ हल हो गया क्योंकि केवल एक पक्ष बदल गया।
<<<<<<< आपका:sample.txt
संघर्ष का समाधान कठिन है;
चलो शॉपिंग चलते हैं।
=======
Git संघर्ष समाधान को आसान बनाता है।
>>>>>>> उनका:sample.txt
और यहां एक और पंक्ति है जो स्पष्ट रूप से हल की गई है या असंशोधित है।

वह क्षेत्र जहां परस्पर विरोधी परिवर्तन हुए हैं, उसे मार्करों <<<<<<<, से चिह्नित किया गया है
=======, और >>>>>>>। ======= से पहले का भाग आम तौर पर आपका पक्ष और भाग होता है
बाद में आम तौर पर उनका पक्ष होता है।

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

"merge.conflictStyle" कॉन्फ़िगरेशन सेट करके एक वैकल्पिक शैली का उपयोग किया जा सकता है
परिवर्तनीय से "diff3"। "diff3" शैली में, उपरोक्त संघर्ष इस तरह दिख सकता है:

यहां ऐसी रेखाएं हैं जो या तो सामान्य से अपरिवर्तित हैं
पूर्वज, या साफ़-साफ़ हल हो गया क्योंकि केवल एक पक्ष बदल गया।
<<<<<<< आपका:sample.txt
संघर्ष का समाधान कठिन है;
चलो शॉपिंग चलते हैं।
|||||||||||||||
संघर्ष का समाधान कठिन है.
=======
Git संघर्ष समाधान को आसान बनाता है।
>>>>>>> उनका:sample.txt
और यहां एक और पंक्ति है जो स्पष्ट रूप से हल की गई है या असंशोधित है।

<<<<<<<, =======, और >>>>>>> मार्करों के अलावा, यह अन्य ||||||| का उपयोग करता है। निशान
उसके बाद मूल पाठ आता है। आप बता सकते हैं कि मूल में केवल एक तथ्य बताया गया है,
और आपके पक्ष ने बस उस कथन को स्वीकार कर लिया और हार मान ली, जबकि दूसरे पक्ष ने ऐसा करने का प्रयास किया
अधिक सकारात्मक दृष्टिकोण रखें. आप कभी-कभी बेहतर समाधान लेकर आ सकते हैं
मूल देखना.

कैसे सेवा मेरे संकल्प संघर्ष

संघर्ष देखने के बाद, आप दो काम कर सकते हैं:

· विलय न करने का निर्णय लें. आपको केवल इंडेक्स फ़ाइल को रीसेट करने की आवश्यकता है
HEAD 2. को उलटने और 2. और 3. द्वारा किए गए कार्यशील ट्री परिवर्तनों को साफ़ करने के लिए प्रतिबद्ध है; गिट
इसके लिए merge --abort का उपयोग किया जा सकता है।

· विवादों का समाधान करें. Git वर्किंग ट्री में संघर्षों को चिह्नित करेगा। फ़ाइलें संपादित करें
आकार में और Git जोड़ना उन्हें सूचकांक में. उपयोग Git करना सौदा सील करने के लिए।

आप कई उपकरणों के साथ संघर्ष पर काम कर सकते हैं:

· मर्जटूल का उपयोग करें. git mergetool एक ग्राफ़िकल मर्जटूल लॉन्च करने के लिए जो आपके काम आएगा
विलय के माध्यम से.

· अंतर को देखो. git diff तीन-तरफा अंतर दिखाएगा, जिसमें से परिवर्तनों को हाइलाइट किया जाएगा
HEAD और MERGE_HEAD दोनों संस्करण।

· प्रत्येक शाखा के अंतर को देखें. गिट लॉग --मर्ज -पी पहले अंतर दिखाएंगे
HEAD संस्करण के लिए और फिर MERGE_HEAD संस्करण के लिए।

· मूल प्रतियों को देखें. गिट शो :1:फ़ाइल नाम सामान्य पूर्वज, गिट शो दिखाता है
:2:फ़ाइलनाम HEAD संस्करण दिखाता है, और git शो:3:फ़ाइलनाम MERGE_HEAD दिखाता है
संस्करण.

उदाहरण

· मौजूदा शाखा के शीर्ष पर शाखाओं के सुधार और संवर्द्धन को मिलाकर एक ऑक्टोपस बनाया जाता है
मर्ज करें:

$ git मर्ज संवर्द्धन को ठीक करता है

· हमारी मर्ज रणनीति का उपयोग करके अप्रचलित शाखा को वर्तमान शाखा में मर्ज करें:

$ git मर्ज - हमारा अप्रचलित है

· शाखा रखरखाव को वर्तमान शाखा में मर्ज करें, लेकिन कोई नई प्रतिबद्धता न बनाएं
खुद ब खुद:

$ गिट मर्ज--नो-कमिट मेनटेन

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

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

मर्ज रणनीतियाँ

मर्ज तंत्र (गिट मर्ज और गिट पुल कमांड) बैकएंड की अनुमति देता है मर्ज रणनीतियों
-s विकल्प के साथ चुना जाना है। कुछ रणनीतियाँ अपने स्वयं के विकल्प भी ले सकती हैं, जो हो सकते हैं
-X . देकर पारित किया गया गिट मर्ज और/या गिट पुल के लिए तर्क।

संकल्प
यह केवल दो शीर्षों को हल कर सकता है (यानी वर्तमान शाखा और आपके द्वारा खींची गई दूसरी शाखा
from) 3-वे मर्ज एल्गोरिथम का उपयोग करना। यह क्रिस-क्रॉस मर्ज का सावधानीपूर्वक पता लगाने की कोशिश करता है
अस्पष्टता और आम तौर पर सुरक्षित और तेज़ माना जाता है।

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

RSI पुनरावर्ती रणनीति निम्नलिखित विकल्प ले सकती है:

Pyrenean भालू (पृष्ठ मौजूद नहीं है)
यह विकल्प परस्पर विरोधी लोगों को समर्थन देकर स्वतः समाधान करने के लिए बाध्य करता है हमारी
संस्करण। दूसरे पेड़ से होने वाले परिवर्तन जो हमारे पक्ष से विरोध नहीं करते हैं
मर्ज परिणाम पर प्रतिबिंबित। बाइनरी फ़ाइल के लिए, संपूर्ण सामग्री ली जाती है
हमारी तरफ से।

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

उन लोगों के
यह के विपरीत है Pyrenean भालू (पृष्ठ मौजूद नहीं है).

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

अंतर-एल्गोरिदम=[धैर्य|न्यूनतम|हिस्टोग्राम|मायर्स]
बताता है मर्ज-पुनरावर्ती एक अलग अंतर एल्गोरिथ्म का उपयोग करने के लिए, जो बचने में मदद कर सकता है
गैर-महत्वपूर्ण मिलान लाइनों (जैसे ब्रेसिज़ से .) के कारण होने वाली ग़लतफ़हमी
विशिष्ट कार्य)। यह सभी देखें git-diff(1) --diff-एल्गोरिदम।

इग्नोर-स्पेस-चेंज, इग्नोर-ऑल-स्पेस, इग्नोर-स्पेस-एट-ईओएल
संकेतित प्रकार के व्हाइटस्पेस परिवर्तन के साथ लाइनों को अपरिवर्तित मानता है
तीन-तरफा विलय के लिए। व्हॉट्सएप परिवर्तन एक पंक्ति में अन्य परिवर्तनों के साथ मिश्रित होते हैं
उपेक्षा नहीं की जाती है। यह सभी देखें git-diff(1) -बी, -डब्ल्यू, और --इग्नोर-स्पेस-एट-ईओएल।

· अगर लेकिन हाल ही संस्करण केवल एक पंक्ति में व्हॉट्सएप परिवर्तन प्रस्तुत करता है, हमारी संस्करण है
उपयोग किया गया;

· अगर हमारी संस्करण व्हाइटस्पेस परिवर्तन पेश करता है लेकिन लेकिन हाल ही संस्करण में शामिल हैं a
महत्वपूर्ण परिवर्तन, लेकिन हाल ही संस्करण का उपयोग किया जाता है;

· अन्यथा, मर्ज सामान्य तरीके से आगे बढ़ता है।

सामान्य बनाना
यह एक फ़ाइल के सभी तीन चरणों का वर्चुअल चेक-आउट और चेक-इन चलाता है जब
तीन-तरफा विलय को हल करना। शाखाओं का विलय करते समय इस विकल्प का उपयोग किया जाना है
विभिन्न स्वच्छ फिल्टर या एंड-ऑफ-लाइन सामान्यीकरण नियमों के साथ। देखें "विलय
अलग-अलग चेकइन/चेकआउट विशेषताओं वाली शाखाएं" in gitattributes(5) के लिए
विवरण।

नो-रिनॉर्मलाइज़
सामान्यीकरण विकल्प को अक्षम करता है। यह मर्ज को ओवरराइड करता है
विन्यास चर।

नाम बदलें-दहलीज=
नाम बदलने का पता लगाने के लिए उपयोग की जाने वाली समानता सीमा को नियंत्रित करता है। यह सभी देखें git-diff(1)
-एम।

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

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

Pyrenean भालू (पृष्ठ मौजूद नहीं है)
यह किसी भी संख्या में शीर्षों को हल करता है, लेकिन विलय का परिणामी वृक्ष हमेशा यही होता है
वर्तमान शाखा प्रमुख, अन्य सभी शाखाओं के सभी परिवर्तनों को प्रभावी ढंग से अनदेखा कर रहा है।
इसका उपयोग पार्श्व शाखाओं के पुराने विकास इतिहास को बदलने के लिए किया जाता है। ध्यान दें
कि यह -Xours विकल्प से भिन्न है पुनरावर्ती मर्ज रणनीति।

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

3-वे मर्ज का उपयोग करने वाली रणनीतियों के साथ (डिफ़ॉल्ट सहित, पुनरावर्ती), यदि कोई परिवर्तन
दोनों शाखाओं पर किया जाता है, लेकिन बाद में शाखाओं में से एक पर वापस कर दिया जाता है, वह परिवर्तन होगा
मर्ज किए गए परिणाम में मौजूद; कुछ लोगों को यह व्यवहार भ्रमित करने वाला लगता है। ऐसा इसलिए होता है क्योंकि
मर्ज करते समय केवल हेड्स और मर्ज बेस पर विचार किया जाता है, न कि
व्यक्तिगत करता है। मर्ज एल्गोरिथम इसलिए वापस किए गए परिवर्तन को नहीं के रूप में मानता है
बिल्कुल बदलें, और बदले हुए संस्करण को इसके बजाय प्रतिस्थापित करता है।

विन्यास

मर्ज.संघर्षशैली
उस शैली को निर्दिष्ट करें जिसमें कार्यशील ट्री फ़ाइलों पर विवादित हंक लिखे गए हैं
विलय. डिफ़ॉल्ट "मर्ज" है, जो एक <<<<<<< संघर्ष मार्कर, द्वारा किए गए परिवर्तन दिखाता है
एक तरफ, एक ======= मार्कर, दूसरी तरफ द्वारा किए गए परिवर्तन, और फिर एक >>>>>>> मार्कर।
एक वैकल्पिक शैली, "diff3", एक ||||||| जोड़ती है मार्कर और मूल पाठ से पहले
======= मार्कर.

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

मर्ज.एफएफ
डिफ़ॉल्ट रूप से, Git किसी कमिट को मर्ज करते समय एक अतिरिक्त मर्ज कमिट नहीं बनाता है
वर्तमान प्रतिबद्धता के वंशज. इसके बजाय, वर्तमान शाखा का सिरा है
तेजी से अग्रेषित. जब गलत पर सेट किया जाता है, तो यह वेरिएबल Git को एक अतिरिक्त मर्ज बनाने के लिए कहता है
ऐसे मामले में प्रतिबद्ध (कमांड लाइन से --no-ff विकल्प देने के बराबर)।
जब केवल पर सेट किया जाता है, तो केवल ऐसे तेज़-फ़ॉरवर्ड मर्ज की अनुमति दी जाती है (देने के बराबर)।
--ff-only विकल्प कमांड लाइन से)।

मर्ज.ब्रांचडेस्क
शाखा नामों के अलावा, शाखा विवरण पाठ के साथ लॉग संदेश भरें
उनके साथ जुड़ा हुआ है. डिफ़ॉल्ट से असत्य.

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

मर्ज.renameLimit
मर्ज के दौरान नाम बदलने का पता लगाते समय विचार की जाने वाली फ़ाइलों की संख्या; अगर
निर्दिष्ट नहीं है, डिफ़ॉल्ट diff.renameLimit का मान है।

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

मर्ज.स्टेट
क्या ORIG_HEAD और मर्ज परिणाम के बीच अंतर को अंत में प्रिंट करना है
विलय. डिफ़ॉल्ट रूप से सत्य है.

मर्ज.टूल
नियंत्रित करता है कि किस मर्ज टूल का उपयोग किया जाता है git-mergetool(1). नीचे दी गई सूची वैध दिखाती है
अंतर्निहित मूल्य. किसी भी अन्य मान को कस्टम मर्ज टूल के रूप में माना जाता है और इसके लिए आवश्यक है कि a
संगत मर्जटूल। .cmd वैरिएबल परिभाषित है।

· अरैक्सिस

· ई.पू

· बीसी3

· कोड तुलना

· डेल्टावॉकर

· विलीन हो जाना

· फैलाना

· उभरना

· उभरना

· gvimdiff

· gvimdiff2

· gvimdiff3

· kdiff3

· पिघलाना

· opendiff

· p4मर्ज

· tkdiff

· कछुआ उभरना

· विमडिफ़

· vimdiff2

· vimdiff3

· विनमर्ज

· xxdiff

मर्ज.वर्बोसिटी
पुनरावर्ती मर्ज रणनीति द्वारा दिखाए गए आउटपुट की मात्रा को नियंत्रित करता है। स्तर 0 आउटपुट
यदि विरोध का पता चला तो अंतिम त्रुटि संदेश के अलावा कुछ भी नहीं। केवल स्तर 1 आउटपुट
विरोध, 2 आउटपुट विरोध और फ़ाइल परिवर्तन। स्तर 5 और उससे ऊपर के आउटपुट डिबगिंग
जानकारी। डिफ़ॉल्ट लेवल 2 है। इसे ओवरराइड किया जा सकता है GIT_MERGE_VERBOSITY
वातावरण विविधता।

विलय. ।नाम
कस्टम निम्न-स्तरीय मर्ज ड्राइवर के लिए मानव-पठनीय नाम परिभाषित करता है। देखना
gitattributes(२९) विवरण के लिए।

विलय. ।चालक
उस कमांड को परिभाषित करता है जो कस्टम निम्न-स्तरीय मर्ज ड्राइवर को लागू करता है। देखना
gitattributes(२९) विवरण के लिए।

विलय. .पुनरावर्ती
आंतरिक मर्ज करते समय उपयोग किए जाने वाले निम्न-स्तरीय मर्ज ड्राइवर का नाम बताता है
सामान्य पूर्वज. देखना gitattributes(२९) विवरण के लिए।

शाखा। .मर्जविकल्प
शाखा में विलय के लिए डिफ़ॉल्ट विकल्प सेट करता है . वाक्यविन्यास और समर्थित विकल्प
के रूप में ही हैं Git मर्ज, लेकिन रिक्त स्थान वर्ण वाले विकल्प मान
वर्तमान में समर्थित नहीं हैं.

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