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

कार्यक्रम:

नाम

गिट-पुल - किसी अन्य रिपॉजिटरी या स्थानीय शाखा से प्राप्त करें और उसके साथ एकीकृत करें

SYNOPSIS

Git खींच [विकल्प] [ [ ...]]

वर्णन

दूरस्थ रिपॉजिटरी से वर्तमान शाखा में परिवर्तन शामिल करता है। इसके डिफ़ॉल्ट में
मोड, git पुल git फ़ेच के लिए शॉर्टहैंड है जिसके बाद git मर्ज FETCH_HEAD होता है।

ज्यादा ठीक, Git खींच चलाता है Git लाना दिए गए पैरामीटर और कॉल के साथ Git मर्ज सेवा मेरे
पुनर्प्राप्त शाखा प्रमुखों को वर्तमान शाखा में मर्ज करें। --रीबेस के साथ, यह चलता है Git
रिबेस के बजाय Git मर्ज.

पास किए गए रिमोट रिपॉजिटरी का नाम होना चाहिए git-fetch(1).
एक मनमाना रिमोट रेफरी नाम दे सकता है (उदाहरण के लिए, टैग का नाम) या यहां तक ​​कि एक
संबंधित रिमोट-ट्रैकिंग शाखाओं के साथ रेफरी का संग्रह (उदाहरण के लिए,
refs/heads/*:refs/remotes/origin/*), लेकिन आम तौर पर यह रिमोट में एक शाखा का नाम होता है
भंडार।

के लिए डिफ़ॉल्ट मान और "रिमोट" और "मर्ज" से पढ़े जाते हैं
द्वारा निर्धारित वर्तमान शाखा के लिए कॉन्फ़िगरेशन Git शाखा(1) --ट्रैक.

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

ए---बी---सी मूल पर मास्टर
/
डी---ई---एफ---जी मास्टर
^
आपके भंडार में मूल/मास्टर

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

ए---बी---सी मूल/गुरु
/ \ _
डी---ई---एफ---जी---एच मास्टर

देख git-मर्ज(1) विवरण के लिए, जिसमें यह भी शामिल है कि संघर्षों को कैसे प्रस्तुत किया जाता है और कैसे संभाला जाता है।

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

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

विकल्प

-क्यू, --शांत
स्थानांतरण के दौरान रिपोर्टिंग को दबाने के लिए इसे अंतर्निहित git-fetch दोनों को पास कर दिया जाता है,
और विलय के दौरान आउटपुट को कम करने के लिए अंतर्निहित गिट-मर्ज।

-v, --verbose
git-fetch और git-merge के लिए --verbose पास करें।

--[नहीं-]रिकर्स-सबमॉड्यूल[=हां|ऑन-डिमांड|नहीं]
यह विकल्प नियंत्रित करता है कि क्या सभी पॉप्युलेट सबमॉड्यूल के नए कमिट भी लाए जाने चाहिए
(देखें गिट-कॉन्फ़िगरेशन(1) और गिटमॉड्यूल्स(5)). आवश्यक डेटा प्राप्त करने के लिए यह आवश्यक हो सकता है
सबमॉड्यूल कमिट को मर्ज करने के लिए, एक सुविधा Git ने 1.7.3 में सीखी। ध्यान दें कि परिणाम
सबमॉड्यूल में मर्ज की जांच नहीं की जाएगी, "गिट सबमॉड्यूल अपडेट" करना होगा
कार्य वृक्ष को मर्ज परिणाम के साथ अद्यतन करने के लिए बाद में बुलाया गया।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-r, --रीबेस[=झूठा|सत्य|संरक्षित]
सत्य होने पर, लाने के बाद वर्तमान शाखा को अपस्ट्रीम शाखा के शीर्ष पर पुनः स्थापित करें। अगर
अपस्ट्रीम शाखा और के अनुरूप एक रिमोट-ट्रैकिंग शाखा है
पिछली बार लाए जाने के बाद से अपस्ट्रीम शाखा को दोबारा आधार बनाया गया था, रीबेस उस जानकारी का उपयोग करता है
गैर-स्थानीय परिवर्तनों को दोबारा आधार बनाने से बचें।

जब संरक्षित करने के लिए सेट किया जाता है, तो git rebase को पास किए गए --preserve-merges विकल्प के साथ रीबेस करें
स्थानीय रूप से बनाए गए मर्ज कमिट को फ़्लैट नहीं किया जाएगा।

गलत होने पर, वर्तमान शाखा को अपस्ट्रीम शाखा में मर्ज करें।

पुल.रीबेस, शाखा देखें। .rebase और शाखा.autoSetupRebase में गिट-कॉन्फ़िगरेशन(1) यदि
आप चाहते हैं कि git पुल विलय के बजाय हमेशा --rebase का उपयोग करें।

नोट
यह एक संभावित है खतरनाक संचालन का तरीका। यह इतिहास को फिर से लिखता है, जो ऐसा करता है
जब आपने वह इतिहास पहले ही प्रकाशित कर दिया तो यह अच्छा संकेत नहीं है। करना नहीं इस विकल्प का उपयोग करें
जब तक कि आपने पढ़ा न हो git-rebase(1) सावधानी से ।

--नहीं-रिबेस
पहले ओवरराइड करें--रीबेस।

ऑप्शंस सम्बंधित सेवा मेरे प्राप्त कर रहा है
--सब
सभी रिमोट प्राप्त करें.

-ए, --जोड़ें
प्राप्त किए गए रेफरियों के रेफरी नाम और ऑब्जेक्ट नाम को मौजूदा सामग्री में जोड़ें
.git/FETCH_HEAD. इस विकल्प के बिना .git/FETCH_HEAD में पुराना डेटा ओवरराइट हो जाएगा।

--गहराई=
प्रत्येक दूरस्थ शाखा के शीर्ष से कमिट की निर्दिष्ट संख्या तक लाने की सीमा सीमित करें
इतिहास। यदि ए के लिए लाया जा रहा है उथला --depth= ​​के साथ git क्लोन द्वारा बनाई गई रिपॉजिटरी
विकल्प (देखें Git क्लोन(1)), इतिहास को निर्दिष्ट संख्या तक गहरा या छोटा करें
प्रतिबद्ध. गहन प्रतिबद्धताओं के लिए टैग नहीं लाए गए हैं।

--उथला
यदि स्रोत रिपॉजिटरी पूर्ण है, तो एक उथले रिपॉजिटरी को पूर्ण रिपॉजिटरी में परिवर्तित करें,
उथले भंडारों द्वारा लगाई गई सभी सीमाओं को हटाना।

यदि स्रोत भंडार उथला है, तो जितना संभव हो उतना प्राप्त करें ताकि वर्तमान हो
रिपॉजिटरी का इतिहास स्रोत रिपॉजिटरी के समान ही है।

--अद्यतन-उथला
डिफ़ॉल्ट रूप से उथले भंडार से लाते समय, git फ़ेच उसे संदर्भित करने से इंकार कर देता है
.git/shallow को अद्यतन करने की आवश्यकता है। यह विकल्प .git/shallow को अपडेट करता है और ऐसे रेफरी को स्वीकार करता है।

-एफ, --फोर्स
. Git लाना के साथ प्रयोग किया जाता है : Refspec, यह अद्यतन करने से इंकार कर देता है
स्थानीय शाखा जब तक कि दूरस्थ शाखा न हो यह एक वंशज है
का . यह विकल्प उस चेक को ओवरराइड करता है.

-के, --रखना
डाउनलोड किया हुआ पैक रखें.

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

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

--अपलोड-पैक
जब दिया जाता है, और रिपॉजिटरी से लाने का प्रबंधन किया जाता है Git फ़ेच-पैक,
--exec= के लिए गैर-डिफ़ॉल्ट पथ निर्दिष्ट करने के लिए कमांड को पास किया जाता है
दूसरे छोर पर कमांड चलाएँ।

--प्रगति
मानक त्रुटि स्ट्रीम पर प्रगति की स्थिति डिफ़ॉल्ट रूप से रिपोर्ट की जाती है जब यह है
एक टर्मिनल से जुड़ा हुआ है, जब तक कि -q निर्दिष्ट न हो। यह ध्वज प्रगति की स्थिति को भी बल देता है
यदि मानक त्रुटि स्ट्रीम किसी टर्मिनल पर निर्देशित नहीं है।


"रिमोट" रिपॉजिटरी जो फ़ेच या पुल ऑपरेशन का स्रोत है। यह
पैरामीटर या तो एक यूआरएल हो सकता है (नीचे जीआईटी यूआरएल अनुभाग देखें) या रिमोट का नाम
(नीचे रिमोट अनुभाग देखें)।


निर्दिष्ट करता है कि कौन सा रेफरेंस लाना है और कौन सा स्थानीय रेफर्स अद्यतन करना है। जब नहीं एस
कमांड लाइन पर दिखाई देते हैं, लाने के लिए रेफरेंस रिमोट से पढ़े जाते हैं। ।लाना
इसके बजाय चर (देखें) git-fetch(1))।

ए का प्रारूप पैरामीटर एक वैकल्पिक प्लस + ​​है, इसके बाद स्रोत रेफरी है
, उसके बाद एक कोलन :, उसके बाद गंतव्य रेफरी . कोलन हो सकता है
कब छोड़ा गया खाली है।

टैग इसका मतलब refs/tags/ के समान है :रेफ्स/टैग/ ; यह लाने का अनुरोध करता है
दिए गए टैग तक सब कुछ।

रिमोट रेफरी जो मेल खाता है लाया गया है, और यदि खाली स्ट्रिंग नहीं है,
इससे मेल खाने वाले स्थानीय रेफरी का उपयोग करके तेजी से अग्रेषित किया जाता है . यदि वैकल्पिक प्लस + ​​है
उपयोग किए जाने पर, स्थानीय रेफ को अपडेट किया जाता है, भले ही इसका परिणाम तेजी से आगे बढ़ने वाला अपडेट न हो।

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

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

GIT यूआरएल

सामान्य तौर पर, URL में परिवहन प्रोटोकॉल, के पते के बारे में जानकारी होती है
रिमोट सर्वर, और भंडार के लिए पथ। परिवहन प्रोटोकॉल के आधार पर, कुछ
इस जानकारी से अनुपस्थित हो सकता है।

Git ssh, git, http और https प्रोटोकॉल का समर्थन करता है (इसके अलावा, ftp, और ftps का उपयोग किया जा सकता है)
लाने और rsync के लिए लाने और धकेलने के लिए इस्तेमाल किया जा सकता है, लेकिन ये अक्षम हैं और
पदावनत; उनका उपयोग न करें)।

मूल परिवहन (यानी git:// URL) कोई प्रमाणीकरण नहीं करता है और इसका उपयोग किया जाना चाहिए
असुरक्षित नेटवर्क पर सावधानी

उनके साथ निम्नलिखित सिंटैक्स का उपयोग किया जा सकता है:

· ssh://[उपयोगकर्ता@]host.xz[:port]/path/to/repo.git/

· git://host.xz[:port]/path/to/repo.git/

· http[s]://host.xz[:port]/path/to/repo.git/

· एफ़टीपी [एस]: //host.xz [: पोर्ट]/पथ/to/repo.git/

· rsync://host.xz/path/to/repo.git/

ssh प्रोटोकॉल के साथ एक वैकल्पिक scp- जैसे सिंटैक्स का भी उपयोग किया जा सकता है:

· [उपयोगकर्ता@]host.xz:path/to/repo.git/

यह सिंटैक्स केवल तभी पहचाना जाता है जब पहले कोलन से पहले कोई स्लैश न हों। इससे मदद मिलती है
एक स्थानीय पथ में अंतर करें जिसमें एक कोलन होता है। उदाहरण के लिए स्थानीय पथ foo:bar can
एक एसएसएच यूआरएल के रूप में गलत व्याख्या किए जाने से बचने के लिए एक पूर्ण पथ या ./foo:bar के रूप में निर्दिष्ट किया जाना चाहिए।

एसएसएच और गिट प्रोटोकॉल अतिरिक्त रूप से ~ उपयोगकर्ता नाम विस्तार का समर्थन करते हैं:

· ssh://[उपयोगकर्ता@]host.xz[:port]/~[user]/path/to/repo.git/

· git://host.xz[:port]/~[user]/path/to/repo.git/

· [उपयोगकर्ता@]host.xz:/~[उपयोगकर्ता]/पथ/से/repo.git/

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

· /पथ/से/repo.git/

फ़ाइल:///पथ/से/repo.git/

क्लोनिंग को छोड़कर, जब पूर्व का तात्पर्य है, तो ये दो वाक्यविन्यास अधिकतर समकक्ष होते हैं
--स्थानीय विकल्प। देखो Git क्लोन(२९) विवरण के लिए।

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

· ::

कहां एक पथ, एक सर्वर और पथ, या एक मनमाना URL जैसी स्ट्रिंग हो सकती है
विशिष्ट दूरस्थ सहायक द्वारा पहचाना जा रहा है। देखो गीट्रेमोट-हेल्पर्स(1) के लिए
विवरण।

यदि बड़ी संख्या में समान-नाम वाले दूरस्थ रिपॉजिटरी हैं और आप a . का उपयोग करना चाहते हैं
उनके लिए अलग प्रारूप (जैसे कि आपके द्वारा उपयोग किए जाने वाले URL को URL में फिर से लिखा जाएगा)
work), आप प्रपत्र का कॉन्फ़िगरेशन अनुभाग बना सकते हैं:

[यूआरएल " "]
इसके बजाय =

उदाहरण के लिए, इसके साथ:

[यूआरएल "गिट: //git.host.xz/"]
इसके बजाय = host.xz:/पथ/से/
इसके बजाय = काम:

"work:repo.git" या "host.xz:/path/to/repo.git" जैसा URL किसी भी में फिर से लिखा जाएगा
संदर्भ जो एक यूआरएल को "git://git.host.xz/repo.git" लेता है।

यदि आप केवल पुश के लिए URL को फिर से लिखना चाहते हैं, तो आप का एक कॉन्फ़िगरेशन अनुभाग बना सकते हैं
प्रपत्र:

[यूआरएल " "]
पुशइनस्टेडऑफ =

उदाहरण के लिए, इसके साथ:

[यूआरएल "ssh://example.org/"]
PushInsteadOf = git://example.org/

"git://example.org/path/to/repo.git" जैसे URL को फिर से लिखा जाएगा
पुश के लिए "ssh://example.org/path/to/repo.git", लेकिन पुल अभी भी मूल का उपयोग करेगा
यूआरएल.

उपाय

URL के स्थान पर निम्न में से किसी एक के नाम का उपयोग किया जा सकता है: तर्क:

· Git कॉन्फ़िगरेशन फ़ाइल में रिमोट: $GIT_DIR/config,

· $GIT_DIR/remotes निर्देशिका में एक फ़ाइल, या

· $GIT_DIR/branches निर्देशिका में एक फ़ाइल।

ये सभी आपको कमांड लाइन से रेफस्पेक को छोड़ने की अनुमति भी देते हैं क्योंकि वे प्रत्येक
एक refspec होता है जो git डिफ़ॉल्ट रूप से उपयोग करेगा।

नामांकित दूरस्थ in विन्यास पट्टिका
आप उस रिमोट का नाम प्रदान करना चुन सकते हैं जिसे आपने पहले उपयोग करके कॉन्फ़िगर किया था
गिट-रिमोट(1) गिट-कॉन्फ़िगरेशन(1) या $GIT_DIR/config फ़ाइल में मैन्युअल संपादन द्वारा भी। यूआरएल
इस रिमोट का उपयोग रिपॉजिटरी तक पहुंचने के लिए किया जाएगा। इस रिमोट का रेफस्पेक होगा
डिफ़ॉल्ट रूप से उपयोग किया जाता है जब आप कमांड लाइन पर रेफस्पेक प्रदान नहीं करते हैं। में प्रवेश
config फ़ाइल इस तरह दिखाई देगी:

[दूरस्थ" "]
यूआरएल =
पुशुर =
धक्का =
लाना =

NS केवल धक्का देने के लिए उपयोग किया जाता है। यह वैकल्पिक है और डिफ़ॉल्ट है .

नामांकित पट्टिका in $GIT_DIR/रिमोट्स
आप $GIT_DIR/remotes में फ़ाइल का नाम प्रदान करना चुन सकते हैं। इस फ़ाइल में URL
भंडार तक पहुँचने के लिए उपयोग किया जाएगा। इस फ़ाइल में refspec डिफ़ॉल्ट के रूप में उपयोग किया जाएगा
जब आप कमांड लाइन पर रेफस्पेक प्रदान नहीं करते हैं। इस फ़ाइल में निम्नलिखित होना चाहिए
प्रारूप:

URL: उपरोक्त URL प्रारूप में से एक
धकेलना:
खींचना:

पुश: लाइनों का उपयोग द्वारा किया जाता है Git धक्का और खींचो: लाइनों का उपयोग द्वारा किया जाता है Git खींच और Git लाना.
एकाधिक पुश: और पुल: अतिरिक्त शाखा मैपिंग के लिए लाइनें निर्दिष्ट की जा सकती हैं।

नामांकित पट्टिका in $GIT_DIR/शाखाएं
आप $GIT_DIR/शाखाओं में फ़ाइल का नाम देना चुन सकते हैं। इस फ़ाइल में URL
भंडार तक पहुँचने के लिए उपयोग किया जाएगा। इस फ़ाइल में निम्न प्रारूप होना चाहिए:

#

आवश्यक है; # वैकल्पिक है।

ऑपरेशन के आधार पर, यदि आप नहीं करते हैं, तो git निम्नलिखित में से किसी एक का उपयोग करेगा
कमांड लाइन पर एक प्रदान करें। $GIT_DIR/शाखाओं में इस फ़ाइल का नाम है
तथा मास्टर के लिए डिफ़ॉल्ट।

गिट लाने का उपयोग करता है:

रेफरी/प्रमुख/ :रेफरी/सिर/

गिट पुश का उपयोग करता है:

प्रमुख: रेफरी / प्रमुख /

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

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

चूक व्यवहार

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

यह निर्धारित करने के लिए कि किस URL से प्राप्त करना है, कॉन्फ़िगरेशन का मान
दूर। .url से परामर्श लिया जाता है और यदि ऐसा कोई वैरिएबल नहीं है, तो URL पर मान:
`$GIT_DIR/रिमोट/ में लाइन फ़ाइल का उपयोग किया जाता है.

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

रेफरी/प्रमुख/*:रेफरी/रिमोट/उत्पत्ति/*

ग्लोबिंग रेफस्पेक में एक गैर-रिक्त आरएचएस होना चाहिए (यानी जो लाया गया था उसे संग्रहीत करना चाहिए
रिमोट-ट्रैकिंग शाखाएं), और इसके एलएचएस और आरएचएस को /* के साथ समाप्त होना चाहिए। उपरोक्त यह निर्दिष्ट करता है
सभी दूरस्थ शाखाओं को refs/remotes/origin/ में दूरस्थ-ट्रैकिंग शाखाओं का उपयोग करके ट्रैक किया जाता है
एक ही नाम के तहत पदानुक्रम.

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

यदि गिट पुल की कमांड लाइन पर स्पष्ट संदर्भ दिए गए थे, तो वे सभी मर्ज हो गए हैं।

जब कमांड लाइन पर कोई refspec नहीं दिया गया था, तो git पुल refspec का उपयोग करता है
कॉन्फ़िगरेशन या $GIT_DIR/रिमोट/ . ऐसे मामलों में, निम्नलिखित नियम लागू होते हैं:

1. यदि शाखा. वर्तमान शाखा के लिए .मर्ज कॉन्फ़िगरेशन विद्यमान है, वही है
दूरस्थ साइट पर उस शाखा का नाम जिसका विलय किया गया है।

2. यदि रेफस्पेक ग्लोबिंग है, तो कुछ भी मर्ज नहीं किया गया है।

3. अन्यथा पहले refspec की दूरस्थ शाखा का विलय कर दिया जाता है।

उदाहरण

· जिस रिपॉजिटरी से आपने क्लोन किया है उसके लिए रिमोट-ट्रैकिंग शाखाओं को अपडेट करें, फिर एक को मर्ज करें
उनमें से आपकी वर्तमान शाखा में:

$ गिट पुल, गिट पुल मूल

आम तौर पर विलय की गई शाखा रिमोट रिपॉजिटरी का प्रमुख होती है, लेकिन विकल्प होता है
शाखा द्वारा निर्धारित. .रिमोट और शाखा। .मर्ज विकल्प; देखना गिट-
विन्यास(२९) विवरण के लिए।

· अगली दूरस्थ शाखा को वर्तमान शाखा में विलय करें:

$ git पुल ओरिजिन अगला

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

$ git फ़ेच मूल
$ गिट मर्ज मूल/अगला

यदि आपने कोई ऐसा प्रयास किया जिसके परिणामस्वरूप जटिल संघर्ष हुआ और आप फिर से शुरुआत करना चाहेंगे, तो आप
के साथ ठीक हो सकते हैं Git रीसेट करें.

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