'गिट पुल' और 'गिट भ्रूण' में क्या अंतर है?


11909

git pullऔर के बीच अंतर क्या हैं git fetch?


364
मुझे यह अच्छी तरह से लिखा गया है git fetch और git पुल के बारे में लिखा गया लेख पढ़ने लायक है: longair.net/blog/2009/04/16/git-fetch-and-merge
Marcos Oliveira

50
हमारा वैकल्पिक दृष्टिकोण git fetch; git reset --hard origin/masterहमारे वर्कफ़्लो के हिस्से के रूप में बन गया है। यह स्थानीय परिवर्तनों को दूर करता है, आपको मास्टर के साथ अद्यतित रखता है लेकिन यह सुनिश्चित करता है कि आप वर्तमान परिवर्तनों में शीर्ष पर नए बदलावों को नहीं खींचते हैं और गड़बड़ करते हैं। हमने इसे कुछ समय के लिए उपयोग किया है और यह मूल रूप से व्यवहार में बहुत सुरक्षित लगता है। बस पहले किसी भी कार्य-प्रगति को जोड़ना / कमिट करना / रोकना सुनिश्चित करें!
माइकल डुरंट

25
सुनिश्चित करें कि आप जानते हैं कि सही तरीके से गिट स्टैश का उपयोग कैसे करें। यदि आप 'पुल' और 'लाने' के बारे में पूछ रहे हैं, तो शायद 'स्टैश' को भी समझाने की ज़रूरत होगी ...
हेनरी हेलेइन

35
मर्क्यूरियल से आने वाले बहुत सारे लोग "गिट पुल" का उपयोग करते हैं, यह सोचकर कि यह "एचजी पुल" के बराबर है। जो यह नहीं है। "Hg पुल" के समान Git "git fetch" है।
सर्ज Shultz

7
git fet कमांड ब्रांच अपडेटेड ब्रांच के साथ अपडेटेड कोड और आपके लोकल में नए जोड़े गए ब्रांच भी मिलेंगे, git pull command fetch केवल करंट ब्रांच का अपडेटेड कोड
कार्तिक पटेल

जवाबों:


9912

सरल शब्दों में, git pulla का git fetchअनुसरण करता है git merge

आप git fetchअपनी दूरस्थ-ट्रैकिंग शाखाओं को अपडेट करने के लिए किसी भी समय कर सकते हैं refs/remotes/<remote>/

यह ऑपरेशन कभी भी आपकी किसी स्थानीय शाखा के अंतर्गत नहीं बदलता है refs/heads, और आपकी कार्यशील प्रति को बदले बिना करना सुरक्षित है। मैंने भी लोगों को git fetchसमय-समय पर पृष्ठभूमि में एक क्रॉन जॉब में चलने के बारे में सुना है (हालांकि मैं ऐसा करने की सलाह नहीं दूंगा)।

git pullवह है जो आप अपने दूरस्थ संस्करण के साथ एक स्थानीय शाखा को अप-टू-डेट लाने के लिए करते हैं, जबकि अपनी अन्य दूरस्थ-ट्रैकिंग शाखाओं को भी अपडेट करते हैं।

गिट प्रलेखन - गिट पुल :

इसके डिफ़ॉल्ट मोड में, उसके बाद git pullशॉर्टहैंड git fetchकिया जाता है git merge FETCH_HEAD


326
"ए" गिट पुल "आप अपने रिपॉजिटरी को आज तक लाने के लिए क्या करेंगे" <- क्या भ्रूण द्वारा पहले से किया गया रिपॉजिटरी अपडेट नहीं है? क्या इसका मतलब यह नहीं है कि यह आपकी स्थानीय शाखाओं को दूरस्थ शाखाओं के साथ अप-टू-डेट करता है? मर्ज करने के लिए: यह उन शाखाओं की आपकी स्थानीय प्रतियों के साथ दूरस्थ शाखाओं का विलय करता है, या यह वास्तव में यहां क्या विलय करता है?
अल्बर्ट

193
@ अल्बर्ट: हाँ, यह अजीब शब्द है। git pullहमेशा वर्तमान शाखा में विलीन हो जाएगा । तो तुम जो शाखा आप को खींचने के लिए चाहते हैं का चयन से , और यह वर्तमान शाखा में खींचती है। से शाखा स्थानीय या दूरदराज के हो सकता है; यह एक दूरस्थ शाखा भी हो सकती है जो पंजीकृत नहीं है git remote(मतलब आप git pullकमांड लाइन पर एक URL पास करते हैं )।
intuited

128
@ एस्परटस: नहीं। पुश करना कभी भी मर्ज नहीं होता है। उपयोगकर्ता को स्थानीय रूप से किसी भी मर्ज संघर्ष को हल करने, खींचने की उम्मीद है, फिर रिमोट पर वापस धक्का दें।
ग्रेग हेविगिल

32
यदि मैं हूं /home/alice/और करूं git fetch /home/bob, तो बाद में मुझे कौन से पैरामीटर पास करने चाहिए git merge?
ripper234

105
गिट सीखने वाले लोगों पर ध्यान दें: pullवास्तव में fetchप्लस ए द्वारा अनुकरण नहीं किया जा सकता है merge। मैंने केवल एक परिवर्तन लाया जहां केवल एक दूरस्थ शाखा सूचक परिवर्तन होता है, और mergeकुछ भी करने से इनकार करता है। pullदूसरी ओर, मेरी ट्रैकिंग शाखा के लिए तेजी से आगे बढ़ें।
रोमन स्टार्कोव

2170
  • जब आप उपयोग करते हैं pull, तो गिट आपके लिए अपने काम को स्वचालित रूप से करने की कोशिश करता है। यह संदर्भ के प्रति संवेदनशील है , इसलिए Git आपके द्वारा वर्तमान में काम कर रही शाखा में किसी भी खींचे गए कमिट को मर्ज कर देगा। pull स्वचालित रूप से उन कॉमेट्स को मर्ज कर देता है जो आपको पहले उनकी समीक्षा किए बिना करते हैं । यदि आप अपनी शाखाओं का बारीकी से प्रबंधन नहीं करते हैं, तो आप बार-बार संघर्ष में भाग सकते हैं।

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


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

126
@elexhobby शार्ट पुट, git fetchकेवल आपकी .git/निर्देशिका (AKA: लोकल रिपॉजिटरी) को अपडेट करता है और बाहर कुछ भी नहीं .git/(AKA: वर्किंग ट्री)। यह आपकी स्थानीय शाखाओं को नहीं बदलता है, और यह स्पर्श masterभी नहीं करता है । remotes/origin/masterहालांकि यह छूता है (देखें git branch -avv)। यदि आपके पास अधिक उपाय हैं, तो प्रयास करें git remote update। यह git fetchएक कमांड में सभी रीमोट के लिए है।
तिनो

24
@ आपका वास्तव में सबसे महत्वपूर्ण बिंदु है। लोगों को पता नहीं हो सकता है कि "रिमोट" शाखाएं वास्तव में हैश के एक समूह के रूप में संग्रहीत होती हैं .git/refs/remotes/origin/
क्रिस

13
जब आप लाते हैं, तो Git लक्ष्य शाखा से कोई भी कमिट इकट्ठा करता है जो आपकी वर्तमान शाखा में मौजूद नहीं है और उन्हें आपकी स्थानीय रिपॉजिटरी में संग्रहीत करता है - मैं कैसे देखता हूं कि रिमोट से क्या लाया गया था और मैं इसे अपनी स्थानीय शाखाओं में कैसे मिलाऊँ?
ア ッ ク

13
@ क्या मैं अभी भी समझ में नहीं आता है ... क्या बात है? यदि यह केवल अपडेट करता है, तो फ़िश का उपयोग क्यों करें .git? इच्छित लाभ क्या है और उसके बाद मुझे क्या करना चाहिए?
BadHorsie

1209

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

तोड़फोड़ को एक क्लाइंट / सर्वर मॉडल के साथ डिजाइन और निर्मित किया गया था। एक एकल रिपॉजिटरी है जो सर्वर है, और कई क्लाइंट सर्वर से कोड ला सकते हैं, उस पर काम कर सकते हैं, फिर इसे सर्वर पर वापस कर सकते हैं। धारणा यह है कि क्लाइंट को सर्वर से हमेशा संपर्क कर सकता है जब उसे ऑपरेशन करने की आवश्यकता होती है।

गिट को एक अधिक वितरित मॉडल का समर्थन करने के लिए डिज़ाइन किया गया था, जिसमें केंद्रीय भंडार के लिए कोई आवश्यकता नहीं है (हालांकि यदि आप चाहें तो आप निश्चित रूप से एक का उपयोग कर सकते हैं)। इसके अलावा git डिज़ाइन किया गया था ताकि क्लाइंट और "सर्वर" को एक ही समय में ऑनलाइन होने की आवश्यकता न हो। गिट डिजाइन किया गया था ताकि एक अविश्वसनीय लिंक पर लोग ईमेल के माध्यम से भी कोड का आदान-प्रदान कर सकें। पूरी तरह से डिस्कनेक्ट करने के लिए काम करना संभव है और गिट के माध्यम से कोड का आदान-प्रदान करने के लिए एक सीडी को जलाएं।

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

  • git fetch वह आदेश है जो कहता है कि "दूरस्थ रिपॉजिटरी की मेरी स्थानीय प्रति को अद्यतित करें।"

  • git pull कहते हैं, "जहां मैं अपना कोड रखता हूं, वहां दूरस्थ रिपॉजिटरी में बदलाव लाएं।"

आम तौर पर git pullएक कर करके करता है git fetchदूरस्थ भंडार ऊपर की स्थानीय प्रतिलिपि तारीख करने के लिए अपने काम की नकल लाने के लिए, और फिर अपने कोड भंडार में परिवर्तन विलय और संभवतः के लिए।

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


75
तकनीकी रूप से, स्थानीय और दूरस्थ रिपॉजिटरी वास्तव में एक और एक ही हैं। Git में, एक भंडार अपने माता-पिता की ओर इशारा करते हुए DAG है। शाखाएँ, तकनीकी रूप से, कमिट के सार्थक नामों से ज्यादा कुछ नहीं हैं। स्थानीय और दूरस्थ शाखाओं के बीच एकमात्र अंतर यह है कि दूरदराज के लोग remoteName/ ग्रिट से उपसर्ग करते हैं जमीन से ऊपर एक बहुत अच्छा पढ़ा है। एक बार जब आप समझ लेते हैं कि Git कैसे काम करता है - और यह खूबसूरती से सरल है , वास्तव में - सब कुछ सिर्फ समझ में आता है।
एमिल लुंडबर्ग

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

7
तो, इस पर आधारित, ISN'T यह एक अच्छा विचार के लिए एक क्रॉन नौकरी के साथ लाने के लिए क्यों है? हमेशा अपने स्थानीय मशीन पर काम कर रहे रिमोट की एक प्रति रखने से यह एक अच्छा विचार लगता है। वास्तव में, मुझे ऐसी स्क्रिप्ट लिखने का मन करता है जो यह देखने के लिए जांचती है कि क्या मैंने पिछले 24 घंटों में अपना रिमोट अपडेट किया है और इसे इंटरनेट कनेक्शन के लिए udv हुक के साथ लिंक कर रहा हूं।
ब्रायन पीटरसन

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

5
@ नोट थिंग वह है, गिट कंटेंट ओरिएंटेड है। यह केवल एक बार डेटा संग्रहीत करता है, और इसे कई बार इंगित करता है। यही कारण है कि Git में, यहां तक ​​कि एक मूल के ऊपर कई हिट भी रेपो के आकार को प्रभावित नहीं करते हैं, क्योंकि अधिकांश ऑब्जेक्ट समान हैं।
cst1992

887

यहाँ ओलिवर स्टील की छवि है कि यह सब कैसे एक साथ फिट होता है :

यहां छवि विवरण दर्ज करें

यदि पर्याप्त रुचि है, तो मुझे लगता है कि मैं जोड़ने के लिए छवि को अपडेट कर सकता हूं git cloneऔर git merge...


154
के साथ एक अद्यतन छवि git cloneऔर git mergeबहुत उपयोगी होगी!
मेमोरियल

19
हां, कृपया जोड़ें git merge- यह स्पष्ट रूप से दिखाना चाहिए कि mergeअलग से बुलाया गया कॉलिंग के समान नहीं है pullक्योंकि pullकेवल रिमोट से विलय हो रहा है और आपकी स्थानीय शाखा में आपके स्थानीय कमिट को अनदेखा करता है जो दूरस्थ शाखा से खींचा जा रहा है।
जस्टअमार्टिन

12
एक तस्वीर एक हजार शब्दों के बराबर होती है! क्या क्लोन और मर्ज डेटा प्रवाह के साथ अद्यतन छवि कहीं तैयार है? आरेख में पहले से क्या है इसके अलावा कोई अन्य डेटा प्रवाह?
शिखांशु

10
@ कोंटांगो कृपया क्लोन जोड़ें और मर्ज करें। मेरे जैसे नवाबी लोगों के लिए मददगार होगा।
किराए

11
Th3sly और thedarkpassenger द्वारा दो आरेख हैं जो क्लोन दिखा रहे हैं और अन्य उत्तरों (नीचे) में विलय कर रहे हैं।
intotecho

487

इसका एक उपयोग मामला git fetchयह है कि निम्नलिखित आपको अपनी पिछली खींचतान के बाद से दूरस्थ शाखा में कोई भी परिवर्तन बताएगा ... इसलिए आप वास्तविक पुल करने से पहले जांच कर सकते हैं, जिससे आपकी वर्तमान शाखा और कार्यशील प्रतिलिपि में फ़ाइलें बदल सकती हैं।

git fetch
git diff ...origin

देखें: अलग -अलग कमांड में डबल-और ट्रिपल-डॉट सिंटैक्स के बारे में https://git-scm.com/docs/git-diff


9
क्यों नहीं git diff ..origin?
एरिक कप्लून

3
git की उत्पत्ति और git में अंतर होता है ..origin काम करने लगता है, लेकिन यह अजीब नहीं ... सामान
Marc

19
@Compustretch कोई स्थान नहीं होना चाहिए था। git diff ...originके बराबर है git diff $(git-merge-base HEAD origin) origin( kernel.org/pub/software/scm/git/docs/git-diff.html#_description का git diff [--options] <commit>...<commit> [--] [<path>…]अनुभाग देखें ), जो इससे भिन्न है ; वैचारिक रूप से वर्तमान शाखा में किए गए बदलावों के कारण से , जबकि वर्तमान शाखा में किए गए परिवर्तनों का उल्टा भी शामिल है , क्योंकि यह शाखाएं हैं । git diff origingit diff ...originoriginorigingit diff originorigin
मैक्स नानसी

2
कोई भी .. कमांड मेरे लिए (विंडोज पर) git diff origin/masterकाम करता है, लेकिन काम करता है, जैसा कि नीचे उल्लेख किया गया है
ब्रायन बर्न्स

यहाँ OSX पर git 2.0.0 का उपयोग कर रहा हूँ। इनमें से किसी भी कमांड ने काम नहीं किया। क्या उन्हें पदावनत कर दिया गया है?
के।-माइकल ऐ

372

मुझे यह समझने में थोड़ा खर्च हुआ कि क्या अंतर था, लेकिन यह एक सरल व्याख्या है। masterआपकी लोकलहोस्ट में एक शाखा है।

जब आप एक रिपॉजिटरी क्लोन करते हैं तो आप पूरे रिपॉजिटरी को स्थानीय होस्ट को देते हैं। इसका मतलब यह है कि उस समय आपके पास एक मूल / मास्टर सूचक है HEADऔर उसी की ओर इशारा करते हुए HEAD

जब आप काम करना शुरू करते हैं और करते हैं, तो आप मास्टर पॉइंटर को आगे HEADबढ़ाते हैं। लेकिन मूल / मास्टर पॉइंटर अभी भी इंगित कर रहा है कि जब आपने क्लोन किया था तब यह क्या था।

तो अंतर होगा:

  • यदि आप ऐसा करते हैं तो git fetchयह दूरस्थ रिपॉजिटरी ( GitHub ) में सभी परिवर्तन लाएगा और मूल / सूचक को ले जाएगाHEAD । इस बीच आपका स्थानीय शाखा मास्टर यह बताता रहेगा कि उसके पास कहां है।
  • यदि आप एक करते हैं git pull, तो यह मूल रूप से प्राप्त करेगा (जैसा कि पहले बताया गया है) और अपनी मास्टर शाखा में किसी भी नए परिवर्तन को मर्ज करें और पॉइंटर को ले जाएं HEAD

14
मूल / मास्टर एक स्थानीय शाखा है जो मूल पर मास्टर की एक COPY है। जब आप लाते हैं, तो आप स्थानीय अपडेट करते हैं: / मूल / मास्टर। एक बार जब आप वास्तव में यह सोच लेते हैं कि सब कुछ एक शाखा है, तो यह बहुत मायने रखता है और विभिन्न परिवर्तनों को बनाए रखने के लिए एक बहुत शक्तिशाली तरीका है, त्वरित स्थानीय शाखाएं, मर्ज और रीबेस बनाएं, और आमतौर पर सस्ते ब्रांचिंग से बहुत अधिक मूल्य प्राप्त करते हैं। नमूना।
cam8001

3
अभी भी भ्रमित। मैंने सोचा git fetchथा कि रिमोट रेपो पर परिवर्तन को अपने स्थानीय रेपो में डाउनलोड करें, लेकिन उन्हें कमिट नहीं करें - यानी, उन्हें अभी भी आपके स्थानीय रेपो में जोड़ा / प्रतिबद्ध होना चाहिए।
krb686

3
दूरस्थ / मूल (github) से केवल आपके स्थानीय मूल तक ही खींचता है। लेकिन यह इसे आपकी वास्तविक कार्यशील फ़ाइलों में विलय नहीं करता है। यदि आप एक पुल बनाते हैं तो यह आपके वर्तमान कार्यशील फाइलों में विलय हो जाएगा
गेरार्डो

223

कभी-कभी एक दृश्य प्रतिनिधित्व मदद करता है।

यहां छवि विवरण दर्ज करें


17
मुझे लगता है कि चित्र से पता चला है कि यह स्थानीय रेपो को भी प्रभावित करता है। यही है, गिट पुल स्थानीय रेपो और काम की नकल को प्रभावित करने का एक संयोजन है। अभी यह लगता है कि यह सिर्फ काम की नकल को प्रभावित करता है।

10
@ @ - 無極 而 this सहमत - यह छवि बहुत ही भ्रामक है, क्योंकि इससे ऐसा लगता है कि यह भ्रूण git pullको छोड़ रहा है, जो निश्चित रूप से गलत है।
forresthopkinsa

8
'स्थानीय रिपोजिटरी' और 'वर्किंग कॉपी' के बीच क्या अंतर है? क्या वे दोनों कंप्यूटर पर स्थानीय नहीं हैं?
द आईट्वॉक

1
फिर git लाने का क्या उपयोग है? कैसे देखें कि स्थानीय रिपॉजिटरी और वर्किंग कॉपी में क्या अंतर है?
विकाश

1
@ यह नहीं है, यह नहीं है। एक स्थानीय रिपॉजिटरी वह जगह है जहाँ आपका कोड काम करने से (रिपॉजिटरी काम करने से) जाता है। (जब आप धक्का देते हैं तो यह रिमोट रेपो में चला जाता है)।
विकाश

219

संक्षिप्त

git fetchके समान है, pullलेकिन विलय नहीं करता है। यानी यह रिमोट अपडेट ( refsऔर objects) प्राप्त करता है, लेकिन आपका स्थानीय वही रहता है (यानी origin/masterअपडेट हो जाता है लेकिनmaster वही रहता है)।

git pull एक दूरस्थ से नीचे खींचता है और तुरन्त विलीन हो जाता है।

अधिक

git clone क्लोन एक रेपो।

git rebaseआपकी वर्तमान शाखा से सामान बचाता है जो एक अस्थायी क्षेत्र में अपस्ट्रीम शाखा में नहीं है। आपकी शाखा अब पहले की तरह ही है, इससे पहले कि आप अपने बदलाव शुरू करें। इसलिए,git pull -rebase दूरस्थ परिवर्तनों को नीचे खींचेंगे, अपनी स्थानीय शाखा को रिवाइंड करेंगे, अपने वर्तमान ब्रांच के शीर्ष पर एक-एक करके अपने परिवर्तनों को फिर से दोहराएंगे जब तक कि आप अप-टू-डेट न हों।

इसके अलावा, git branch -aआपको दिखाएगा कि आपकी सभी शाखाओं के साथ क्या हो रहा है - स्थानीय और दूरस्थ।

यह ब्लॉग पोस्ट उपयोगी थी:

गिट पुल, गिट लाने और गिट क्लोन (और गिट रीबेस) के बीच का अंतर - माइक पीयर्स

और कवर git pull, git fetch, git cloneऔर git rebase

====

अपडेट करें

मुझे लगा कि मैं यह दिखाने के लिए इसे अपडेट करूंगा कि आप वास्तव में इसका उपयोग कैसे करेंगे।

  1. अपने स्थानीय रेपो को रिमोट से अपडेट करें (लेकिन मर्ज न करें):

    git fetch 
    
  2. अपडेट डाउनलोड करने के बाद, आइए अंतर देखें:

    git diff master origin/master 
    
  3. यदि आप उन अपडेट से खुश हैं, तो मर्ज करें:

    git pull
    

टिप्पणियाँ:

चरण 2 पर: स्थानीय और रीमोट के बीच अंतर के बारे में अधिक जानने के लिए, देखें: किसी स्थानीय गिट शाखा की दूरस्थ शाखा से तुलना कैसे करें?

चरण 3 पर: यह शायद अधिक सटीक है (उदाहरण के लिए तेजी से बदलते रेपो पर) git rebase origin। एक अन्य उत्तर में @ जस्टिन ओह्स टिप्पणी देखें ।

इन्हें भी देखें: http://longair.net/blog/2009/04/16/git-fetch-and-merge/


1
मुझे लगता है जैसे अगर कोई चाहता है कि स्थानीय कोड "टिप" को प्रतिबिंबित करे, तो उन्हें उपयोग करना चाहिए git clone। मैंने टिप को उद्धरणों में रखा, जैसा कि मुझे लगता है कि इसका मतलब होगा कि जो भी मास्टर है और कोई क्या होगा "gipub के रूप में डाउनलोड करें" github.com
क्रिस के

3
क्या होगा अगर आप लाने के बाद परिवर्तन से खुश नहीं हैं? आगे क्या करना है?
कुगुट्सुमेन

आपका रिबेट पर पैराग्राफ बस वही था जो मैं खोज रहा था। सब कुछ शून्य करने के बारे में पूरा विचार, रिमोट से अपडेट करना, फिर पिछले कामों के दौरान आपके बदलावों को फिर से दोहराते हुए जब आप काम कर रहे थे। सही व्याख्या यह सही है। ;)
coblr

178
git-pull - दूसरी रिपॉजिटरी या किसी स्थानीय शाखा से प्राप्त और मर्ज करें
SYNOPSIS

पकड़ खींचो ...
विवरण

दिए गए मापदंडों के साथ git-fetch चलाता है, और git-merge को मर्ज करने के लिए कहता है 
वर्तमान शाखा में पुनः प्राप्त प्रमुख। --Rebase के साथ, git-rebase कहता है
बजाय मर्ज-मर्ज के।

ध्यान दें कि आप उपयोग कर सकते हैं। (वर्तमान निर्देशिका) खींचने के लिए <रिपॉजिटरी> के रूप में
स्थानीय रिपॉजिटरी से - स्थानीय शाखाओं को मर्ज करते समय यह उपयोगी है 
वर्तमान शाखा में।

यह भी ध्यान दें कि विकल्प गिट-पुल और अंतर्निहित गिट-मर्ज के लिए थे 
git-fetch के लिए विकल्प से पहले दिया जाना चाहिए।

यदि आप चाहते हैं कि इतिहास में विलय हो जाए तो आप खींच लेंगे, यदि आप 'कोडज़' चाहते हैं तो जैसे कि कोई व्यक्ति यहाँ कुछ लेखों को टैग कर रहा है।


5
बहुत दिलचस्प है, लेकिन मैं वास्तव में एक उपयोग के मामले को नहीं देख सकता हूं जहां आप "बस कोड" चाहते हैं। जब आप लाते हैं तो आपके कोड के साथ क्या होता है? क्या इसे मिटा दिया गया है? दूरस्थ परिवर्तनों के साथ क्या होता है? यदि आप विलय नहीं करते हैं तो यह आपके कोड को आपके कोड को मिटा देने में कैसे बदल जाता है?
ई-सतीस

11
@ ई-सिटिस: दूरस्थ शाखा भी आपकी मशीन पर स्थानीय रूप से संग्रहीत होती है। इसलिए जब आप git fetchइसे करते हैं तो भंडार से परिवर्तन लाते हैं और अपनी स्थानीय दूरस्थ शाखा को अपडेट करते हैं। यह आपकी स्थानीय शाखा को प्रभावित नहीं करता है जो स्थानीय दूरस्थ शाखा को ट्रैक करता है, इसलिए आपकी कार्यशील प्रति को प्रभावित नहीं करता है। अब, जब आप mergeइसे करते हैं, तो यह आपकी स्थानीय शाखा के साथ आए परिवर्तनों को मर्ज कर देगा।
जेफरीवोन

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

163

आप दूरस्थ रिपॉजिटरी से ला सकते हैं, अंतर देख सकते हैं और फिर खींच या मर्ज कर सकते हैं।

यह दूरस्थ रिपॉजिटरी के लिए एक उदाहरण है जिसे originएक शाखा कहा जाता है और रिमोट ब्रांच को masterट्रैक करने के लिए कहा जाता है origin/master:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

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

158

संक्षिप्त और आसान उत्तर यह है कि git pullबस git fetchइसके बाद git merge

यह नोट करना बहुत महत्वपूर्ण है कि स्वचालित रूप से विलयgit pull हो जाएगा कि आप इसे पसंद करते हैं या नहीं । यह निश्चित रूप से, मर्ज संघर्ष का परिणाम हो सकता है। मान लीजिए कि आपका रिमोट है originऔर आपकी शाखा है master। यदि आप git diff origin/masterखींचने से पहले, आप संभावित मर्ज संघर्ष का कुछ विचार होना चाहिए और तदनुसार अपनी स्थानीय शाखा तैयार कर सकते हैं।

खींचने और धकेलने के अलावा, कुछ वर्कफ़्लोज़ शामिल हैं git rebase, जैसे कि यह एक, जिसे मैं लिंक किए गए लेख से व्याख्या करता हूं:

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

यदि आप खुद को ऐसी स्थिति में पाते हैं, तो आपको लुभाया जा सकता है git pull --rebase। जब तक आप वास्तव में, वास्तव में नहीं जानते कि आप क्या कर रहे हैं, मैं उसके खिलाफ सलाह दूंगा। यह चेतावनी संस्करण के manलिए पेज से है :git-pull2.3.5

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


2
@JustinOhms यदि git pull --rebaseदी गई स्थिति में सही चीज़ नहीं है, तो क्या यह सही है अगर इसे दो चरणों में किया जाता है? यदि यह करना सही है, तो इसे दो चरणों में करने के लिए अतिरिक्त लाभ क्या है?
कज़

@ काज - क्योंकि रिबास स्वचालित नहीं है। परिवर्तनों को प्राप्त करने से पहले आपको निर्णय लेने की अनुमति मिलती है। यह उस समस्या को ठीक नहीं करता है जिसे आपने पहले से ही धकेले हुए इतिहास को पुन: प्रकाशित करने के साथ किया है। यह आपको यह देखने की अनुमति देगा कि क्या यह उन परिवर्तनों को वापस करने के लिए सुरक्षित है जिन्हें आपने पहले से धक्का नहीं दिया है।
जस्टिन ओम्स

2
@JustinOhms आप यह कैसे तय करेंगे कि बदलावों को रिबेस करना सुरक्षित है? मैं सिर्फ गिट रिबेस की कोशिश करूंगा, और अगर यह गड़बड़ी करता है तो बैकट्रैक करता है, इस मामले में मैं जीआईटी पुल - गैबेज भी कर सकता हूं। लेकिन शायद आपके पास कोई और रास्ता हो?
कज़

3
@ KaZ gitk आपको शाखा संरचना को नेत्रहीन रूप से देखने की अनुमति देता है। यह आपके स्थानीय मुखिया, पदच्युत, और आपकी शाखा संरचनाओं के संबंध में दिखाएगा कि आपने क्या प्राप्त किया है। इस तरह से आप यह सुनिश्चित कर सकते हैं कि आप उन पूर्वजों पर आधारित परिवर्तन नहीं कर रहे हैं जो पूर्वज पर आधारित हैं, जो कि आपके रिमोट (एस) को पहले से ही धक्का दे चुके हैं।
जस्टिन ओम्स

का प्रयोग करें rebaseजब आप एक स्थानीय शाखा पहले से ही धक्का दिया नहीं पर काम कर रहे हैं। यदि आप एक शाखा पर काम कर रहे हैं जो रिमोट में मौजूद है, rebaseतो कुछ खराब मुद्दों का परिणाम हो सकता है , इसलिए आपको नियमित रूप से पसंद करना चाहिए merge
जस्टुस रोमिज़न

151

ठीक है, यहाँ बारे में कुछ जानकारी कर रहे हैं git pullऔर git fetchहै, तो आप वास्तविक मतभेद ... कुछ सरल शब्दों में समझ सकते हैं लाने के नवीनतम डेटा हो जाता है, लेकिन नहीं कोड में परिवर्तन और अपने वर्तमान स्थानीय शाखा कोड के साथ गड़बड़ करने के लिए नहीं जा रहा है, लेकिन पुल प्राप्त कोड बदलता है और इसे अपनी स्थानीय शाखा में मर्ज करता है, प्रत्येक के बारे में अधिक जानकारी प्राप्त करने के लिए पढ़ें:

git fetch

यह सभी रेफरी और ऑब्जेक्ट्स और किसी भी नई शाखाओं को आपके स्थानीय रिपॉजिटरी में डाउनलोड करेगा ...

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

डिफ़ॉल्ट रूप से, कोई भी टैग जो इशारा किया जा रहा है उसे भी लाया जाता है; इसका प्रभाव उन टैग्स को प्राप्त करना है जो उन शाखाओं पर इंगित करते हैं जिन्हें आप रुचि रखते हैं। इस डिफ़ॉल्ट व्यवहार को --tags या --no- टैग विकल्पों का उपयोग करके या दूरस्थ..टैगऑप्ट को कॉन्फ़िगर करके बदला जा सकता है। स्पष्ट रूप से टैग्स लाने वाले एक refspec का उपयोग करके, आप उन टैगों को प्राप्त कर सकते हैं जो उन शाखाओं में इंगित नहीं होते हैं जिन्हें आप रुचि रखते हैं।

git fet एक ही नाम वाले रिपॉजिटरी या URL से, या कई रिपॉजिटरी से एक बार में, यदि दिया गया हो, और एक रीमोट हो सकता है। कॉन्फ़िगरेशन फ़ाइल में प्रविष्टि। (देखें git-config 1 )।

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

Refs के नाम जो प्राप्त किए गए ऑब्जेक्ट नामों के साथ, .IT / FETCH_HEAD को लिखे गए हैं। इस जानकारी का उपयोग स्क्रिप्ट या अन्य git कमांड द्वारा किया जा सकता है, जैसे git-pull।


पकड़ खींचो

यह रिमोट से लेकर करंट ब्रांच में लोकल ...

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

अधिक सटीक रूप से, git पुल दिए गए मापदंडों के साथ git fetch चलाता है और git मर्ज को वर्तमान शाखा में पुनः प्राप्त शाखा प्रमुखों को मिलाने के लिए कहता है। --Rebase के साथ, यह git मर्ज के बजाय git rebase चलाता है।

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

के लिए डिफ़ॉल्ट मान और "शाखा" और वर्तमान शाखा के लिए "मर्ज" कॉन्फ़िगरेशन से पढ़ा जाता है, जैसा कि गिट-शाखा - ट्रैक द्वारा निर्धारित किया गया है।


मैं आपको यह दिखाने के लिए नीचे दृश्य भी बनाता हूं कि कैसे git fetchऔर git pullएक साथ काम करना ...

गिट पुल और गिट लाने के लिए


9
अगर आपको छवि पसंद है तो git चीट शीट पर एक नज़र डालें, जो सभी git कमांड के लिए एक ही तरह की है ... ndpsoftware.com/git-cheatsheet.html
Tom

3
क्या क्लोन स्थानीय रिपॉजिटरी (रिमोट से सभी इतिहास की नकल) को भी प्रभावित नहीं करता है?
टॉम लोर्डो

135

यहां छवि विवरण दर्ज करें

यह इंटरैक्टिव चित्रमय प्रतिनिधित्व git को समझने में बहुत मददगार है: http://ndpsoftware.com/git-cheatsheet.html

git fetchबस रिमोट से आपके स्थानीय रिपॉजिटरी में परिवर्तन को "डाउनलोड" करता है। git pullपरिवर्तनों को डाउनलोड करता है और उन्हें आपकी वर्तमान शाखा में विलय करता है। "इसके डिफ़ॉल्ट मोड में, इसके बाद git pullशॉर्टहैंड git fetchकिया जाता है git merge FETCH_HEAD।"


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


126

बक्शीश:

उपरोक्त जवाबों में पुल और लाने की बात करते हुए, मैं एक दिलचस्प चाल साझा करना चाहता हूं,

git pull --rebase

यह उपरोक्त कमांड मेरे git जीवन में सबसे उपयोगी कमांड है जिसने बहुत समय बचाया।

अपने नए कमिट्स को सर्वर पर धकेलने से पहले, इस कमांड को आज़माएँ और यह स्वचालित रूप से लेटेस्ट सर्वर चेंजेस (एक भ्रूण + मर्ज के साथ) सिंक करेगा और आपकी कमिट को git लॉग में सबसे ऊपर रखेगा। मैनुअल पुल / मर्ज के बारे में चिंता करने की आवश्यकता नहीं है।

यहाँ विवरण प्राप्त करें: http://gitolite.com/git-pull--rebase


4
अच्छा टिप, हालांकि यह नए गिट उपयोगकर्ताओं का उल्लेख करने लायक है जो रिबास कमिट हैश को संशोधित करता है (मैंने पाया कि आश्चर्यजनक रूप से तोड़फोड़ से आ रहा है)।
एलेक्सा

1
क्या आप बता सकते हैं कि क्या अंतर है git pullऔर git pull --rebase?
शैजुत

2
ऊपर दिए गए उत्तर में इस विधि के बारे में स्टार्क को चेतावनी देखें: stackoverflow.com/a/6011169/241244

118

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

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
(ORIGIN)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
                  .
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
                  .
COMMIT            .                             *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
                  .
PUSH   *<---------------------------------------*
Synchronizes your changes back into the origin.

रिमोट का एक आईना रखने के लिए कुछ प्रमुख लाभ हैं:

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

git pullएक मर्ज भी नहीं करता है , यानी काम की नकल के लिए सभी तरह से जा रहा है?
कामिल वानरोइज

अच्छी बात है, हाँ यह आपके काम करने की कॉपी में सभी बदलाव करेगा, और फिर आप इसे स्थानीय रेपो में खुद कर सकते हैं। मैं दृश्य को अपडेट करूंगा।
Justus Romijn

@JustusRomijn क्या एक पुल भी स्थानीय भंडार को अद्यतन नहीं करता है? क्या मूल और काम करने वाले प्रतिलिपि तारांकन के बीच एक तारांकन नहीं होना चाहिए?
user764754

2
@ user764754 जब आप खींचते हैं, तो आपकी वर्किंग कॉपी में परिवर्तन हो जाते हैं (कुछ संघर्ष भी हो सकते हैं, जिन्हें आपको हल करने की आवश्यकता हो सकती है)। आपको अभी भी इसे अपने स्थानीय भंडार में रखना है।
Justus Romijn

@JustusRomijn: चित्रण के लिए धन्यवाद। यह बहुत अच्छा होगा यदि आप इस तरह के रीसेट, रिपॉजिटरी राज्यों पर चेरी पिक के संचालन के प्रभाव को चित्रित करके आरेख को अधिक व्यापक बना सकते हैं।
jith912

106

मैंने इसके साथ भी संघर्ष किया है। वास्तव में मैं यहाँ एक ही सवाल का एक गूगल खोज के साथ मिला। इन सभी जवाबों को पढ़कर अंत में मेरे सिर में एक तस्वीर चित्रित हुई और मैंने 2 रिपॉजिटरी और 1 सैंडबॉक्स की स्थिति को देखते हुए इसे नीचे लाने की कोशिश करने का फैसला किया और समय के साथ उनमें से संस्करण को देखते हुए प्रदर्शन किया। तो यहाँ है क्या मैं के साथ आया था। अगर मैंने कहीं गड़बड़ की तो कृपया मुझे सुधार दें।

एक भ्रूण के साथ तीन प्रतिनिधि:

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------

एक पुल के साथ तीन रिपोज

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - pull                -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     - merged with R02     -
- @ R01             -     - @ R01+              -     - @R02+               -
---------------------     -----------------------     -----------------------

इससे मुझे यह समझने में मदद मिली कि एक भ्रूण काफी महत्वपूर्ण क्यों है।


पढ़ने के लिए कठिन नहीं है: बक्से रेपो की स्थिति का प्रतिनिधित्व करते हैं, कि बॉक्स की पंक्ति 2 में रिपोर्ट किए गए ऑपरेशन के बाद बाएं से दाएं समय में प्रत्येक पंक्ति में परिवर्तन होता है। R0n लेबल git में टैग हैं, और A + वाला टैग अभी तक अनक्मिटेड सामान है। Sanbox का उपयोग आपके काम करने वाले फ़ोल्डर के लिए किया जाता है, जो कि रेपो फ़ोल्डर से अलग होता है, जहाँ कमिटेड सामान संग्रहीत होता है।
user1708042

96

GIT Fetch और GIT Pull के बीच के अंतर को निम्नलिखित परिदृश्य के साथ समझाया जा सकता है: (ध्यान में रखते हुए कि चित्र शब्दों से अधिक आकर्षक हैं!, मैंने सचित्र प्रतिनिधित्व प्रदान किया है)

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

तो, दो शाखाओं की प्रारंभिक अवस्था जब आपने अपने स्थानीय भंडार पर मुख्य परियोजना को फोर्क किया तो यह इस तरह होगा- ( और A, परियोजना के पहले से ही पूर्ण किए गए मॉड्यूल हैं)BC

यहां छवि विवरण दर्ज करें

अब, आपने नए मॉड्यूल (मान लीजिए D) पर काम करना शुरू कर दिया है और जब आपने Dमॉड्यूल पूरा कर लिया है तो आप इसे मुख्य शाखा में धकेलना चाहते हैं, लेकिन इस बीच ऐसा होता है कि आपके एक साथी ने नया मॉड्यूल विकसित किया है E, Fऔर संशोधित किया है C
तो अब जो हुआ है, वह यह है कि परियोजना की मूल प्रगति के पीछे आपके स्थानीय भंडार की कमी है और इस प्रकार आपके परिवर्तनों को मुख्य शाखा में धकेलने से संघर्ष हो सकता है और आपके मॉड्यूल Dमें खराबी हो सकती है ।

यहां छवि विवरण दर्ज करें

ऐसे मुद्दों से बचने और परियोजना की मूल प्रगति के समानांतर काम करने के लिए उनके दो तरीके हैं:

1. Git Fetch- यह उन सभी परिवर्तनों को डाउनलोड करेगा जो मूल / मुख्य शाखा परियोजना में किए गए हैं जो आपकी स्थानीय शाखा में मौजूद नहीं हैं। और आपके रिपॉजिटरी या शाखा में लाए गए परिवर्तनों को लागू करने के लिए Git Merge कमांड की प्रतीक्षा करेगा।

यहां छवि विवरण दर्ज करें

इसलिए अब आप फ़ाइलों को अपने भंडार में विलय करने से पहले सावधानीपूर्वक निगरानी कर सकते हैं। और आप संशोधित कर सकते हैं Dयदि आवश्यक हो तो संशोधित किया जा सकता है C

यहां छवि विवरण दर्ज करें

2. Git Pull- यह आपकी स्थानीय शाखा को मूल / मुख्य शाखा के साथ अद्यतन करेगा अर्थात वास्तव में यह जो करता है वह Git Fetch का संयोजन है और Git एक के बाद एक विलय करता है। लेकिन इसका कारण कॉनफ्लिक्ट्स हो सकता है, इसलिए यह एक साफ कॉपी के साथ गिट पुल का उपयोग करने की सिफारिश की जाती है।

यहां छवि विवरण दर्ज करें


1
यदि आप 'मुख्य शाखा' को 'रिमोट रेपो' में बदल सकते हैं, तो यह एक महान जवाब होगा।
किबिरोन हू

87

हम बस कहते हैं:

git pull == git fetch + git merge

यदि आप चलाते हैं git pull, तो आपको डेटा को स्थानीय में मर्ज करने की आवश्यकता नहीं है। यदि आप दौड़ते हैं git fetch, तो इसका मतलब है कि आपको दौड़ना चाहिएgit merge अपने स्थानीय मशीन के लिए नवीनतम कोड प्राप्त करने के लिए । अन्यथा, मर्ज किए बिना स्थानीय मशीन कोड नहीं बदला जाएगा।

इसलिए गिट गुई में, जब आप लाते हैं, तो आपको डेटा को मर्ज करना होगा। अपने स्थानीय में कोड परिवर्तन स्वयं न करें। आप यह देख सकते हैं कि जब आप एक बार लाने और देखने के द्वारा कोड को अपडेट करते हैं; कोड यह नहीं बदलेगा। फिर आप मर्ज करें ... आपको परिवर्तित कोड दिखाई देगा।


3
मैं बल्कि कहता हूँ git pull == git fetch + git merge:)
melvynkim

2
लेकिनgit pull --rebase = git fetch + git rebase
टिनो

83

git fetchआपके स्थानीय रिपॉजिटरी में रिमोट सर्वर से आपकी ट्रैकिंग शाखाओं तक कोड को खींचता है। अपने रिमोट का नाम है, तो origin(डिफ़ॉल्ट) तो इन शाखाओं के भीतर हो जाएगा origin/, उदाहरण के लिए origin/master, origin/mybranch-123आदि ये आपके मौजूदा शाखाओं वे कर रहे हैं नहीं कर रहे हैं, स्थानीय सर्वर से उन शाखाओं की प्रतियां।

git pullgit fetchलेकिन फिर भी उस शाखा के वर्तमान स्थानीय संस्करण में ट्रैकिंग शाखा से कोड को मर्ज करता है । यदि आप अभी उस परिवर्तन के लिए तैयार नहीं हैं, तो बस git fetchपहले।


78

git fetchदूरस्थ शाखाओं को पुनः प्राप्त करेगा ताकि आप वर्तमान शाखा के साथ git diffया git mergeउन्हें कर सकें। git pullकरंट ब्रांच द्वारा ट्रैक किए गए रिमोट ब्राच पर लाएगा और फिर परिणाम को मर्ज करेगा। आप यह git fetchदेखने के लिए उपयोग कर सकते हैं कि क्या आपके स्थानीय शाखा के साथ विलय के बिना दूरस्थ शाखा में कोई अपडेट है या नहीं।


73

गिट बुत

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

Git मर्ज

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

गिट पुल

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


52

केवल git pullऔर केवल इतना ही अंतर git fetchहै:

git pull एक दूरस्थ शाखा से खींचता है और इसे विलय करता है।

git fetch केवल दूरस्थ शाखा से प्राप्त होता है, लेकिन यह विलय नहीं करता है

यानी git पुल = git fetch + git मर्ज ...


1
और न ही मदद करें कि अगर git को लगता है कि आप कमिट्स के पीछे हैं और "फ़ास्ट-फ़ॉरवर्ड" कर सकते हैं, जिस पर मैंने rm -rfपूरी बात को शुरू कर दिया और शुरू कर दिया। बेवकूफ जीत, कृपया मुझे चालू होने दें ताकि मैं काम पर वापस जा सकूं?
क्रिस के

46

सरल शब्दों में, यदि आप किसी भी इंटरनेट कनेक्शन के बिना एक विमान पर चढ़ने वाले थे ... प्रस्थान करने से पहले आप बस कर सकते थे git fetch origin <master> । यह आपके कंप्यूटर के सभी परिवर्तनों को प्राप्त कर लेगा, लेकिन इसे आपके स्थानीय विकास / कार्यक्षेत्र से अलग रखेगा।

विमान पर, आप अपने स्थानीय कार्यक्षेत्र में परिवर्तन कर सकते हैं और फिर इसे अपने साथ मिला सकते हैं जो आपने प्राप्त किया है और इंटरनेट के कनेक्शन के बिना संभावित मर्ज संघर्ष को हल करता है। और जब तक किसी ने दूरस्थ रिपॉजिटरी में नए परस्पर विरोधी परिवर्तन नहीं किए थे, तब एक बार जब आप गंतव्य पर पहुंच git push origin <branch>जाते हैं तो आप अपनी कॉफी प्राप्त कर लेते हैं।


इस भयानक एटलसियन ट्यूटोरियल से :

git fetchआदेश डाउनलोड कमिट, फाइल और refs अपने स्थानीय भंडार में एक दूरस्थ रिपोजिटरी से।

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

दूरस्थ रिपॉजिटरी से सामग्री डाउनलोड करते समय, git pullऔर git fetchकमांड कार्य को पूरा करने के लिए उपलब्ध हैं। आप git fetchदो आदेशों के 'सुरक्षित' संस्करण पर विचार कर सकते हैं । यह दूरस्थ सामग्री को डाउनलोड करेगा, लेकिन आपके वर्तमान कार्यशील स्थिति को छोड़कर, अपने स्थानीय भंडार की कार्यशील स्थिति को अद्यतन नहीं करेगा। git pullअधिक आक्रामक विकल्प है, यह सक्रिय स्थानीय शाखा के लिए दूरस्थ सामग्री को डाउनलोड करेगा और git mergeनई दूरस्थ सामग्री के लिए मर्ज कमिट बनाने के लिए तुरंत निष्पादित करेगा। यदि आपके पास प्रगति में लंबित परिवर्तन हैं, तो यह संघर्ष का कारण बनेगा और मर्ज संघर्ष रिज़ॉल्यूशन प्रवाह को किकऑफ़ करेगा।


के साथ git pull:

  • आपको कोई अलगाव नहीं मिलता है।
  • यह आपके स्थानीय विकास को प्रभावित करता है।
  • इसे स्पष्ट रूप से जांचने की आवश्यकता नहीं है। क्योंकि यह निहित रूप से एक है git merge
  • यह मूल रूप से सुरक्षित नहीं है। यह आक्रामक है।
  • इसके विपरीत git fetchजहां यह केवल आपके को प्रभावित करता है .git/refs/remotes, गिट पुल आपके और दोनों को प्रभावित करेगा.git/refs/remotes .git/refs/heads/

हम्मम ... इसलिए अगर मैं साथ काम की कॉपी अपडेट नहीं कर रहा हूं git fetch, तो मैं कहां बदलाव कर रहा हूं? Git लाने के लिए नए कमिट कहाँ से लाएँ?

बड़ा सवाल है। यह कहीं न कहीं इसे आपकी वर्किंग कॉपी से अलग कर देता है। लेकिन फिर कहां? चलो पता करते हैं।

अपनी परियोजना निर्देशिका में (यानी, जहाँ आप अपनी gitआज्ञाएँ करते हैं) करते हैं:

  1. ls। यह फाइलों और निर्देशिकाओं को दिखाएगा। कुछ भी नहीं, मुझे पता है।

  2. अब करते हैं ls -a। यह दिखा देंगे डॉट फ़ाइलें , यानी, के साथ शुरुआत फ़ाइलों .इसके बाद आप नाम के एक निर्देशिका देखने के लिए सक्षम हो जाएगा: .git

  3. करते हैं cd .git। यह स्पष्ट रूप से आपकी निर्देशिका को बदल देगा।
  4. अब मज़े वाला हिस्सा आया; करते हैं ls। आपको निर्देशिकाओं की एक सूची दिखाई देगी। हम ढूंढ रहे हैं refs। करते हैं cd refs
  5. यह देखना दिलचस्प है कि सभी निर्देशिकाओं के अंदर क्या है, लेकिन आइए उनमें से दो पर ध्यान केंद्रित करें। headsऔर remotescdउनके अंदर भी जांच करने के लिए उपयोग करें ।
  6. जो भी git fetch आप करते हैं वह /.git/refs/remotesनिर्देशिका में आइटम को अपडेट करेगा । यह /.git/refs/headsनिर्देशिका में कुछ भी अद्यतन नहीं करेगा ।
  7. कोई भी git pull पहले डायरेक्टरी करेगा, डायरेक्टरी git fetchमें आइटम अपडेट करेगा /.git/refs/remotes, फिर अपने लोकल में मर्ज करेगा और फिर /.git/refs/headsडायरेक्ट्री के अंदर हेड को बदल देगा ।

एक बहुत अच्छा संबंधित जवाब यह भी पाया जा सकता है कि 'गिट भ्रूण' कहाँ पर है?

इसके अलावा, Git शाखा के नामकरण सम्मेलनों के बाद "स्लैश नोटेशन" देखें । यह आपको बेहतर तरीके से समझने में मदद करता है कि Git विभिन्न निर्देशिकाओं में चीजों को कैसे रखता है।


वास्तविक अंतर देखने के लिए

बस करो:

git fetch origin master
git checkout master

यदि दूरस्थ मास्टर अपडेट किया गया था, तो आपको इस तरह एक संदेश मिलेगा:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

यदि आपने नहीं किया fetchऔर अभी-अभी किया है git checkout masterतो आपके स्थानीय git को यह नहीं पता होगा कि 2 कमिट जोड़े गए हैं। और यह सिर्फ कहना होगा:

Already on 'master'
Your branch is up to date with 'origin/master'.

लेकिन यह पुराना और गलत है। ऐसा इसलिए है क्योंकि git आपको पूरी तरह से फीडबैक देगा कि यह क्या जानता है। यह नया है कि यह अभी तक नीचे नहीं खींचा है के लिए बेखबर है ...


क्या स्थानीय रूप से शाखा पर काम करते समय रिमोट में किए गए नए परिवर्तनों को देखने का कोई तरीका है?

कुछ IDE (जैसे Xcode) सुपर स्मार्ट होते हैं और परिणाम का उपयोग करते हैं git fetchऔर कोड की उन पंक्तियों को एनोटेट कर सकते हैं जिन्हें आपकी वर्तमान कार्यशील शाखा के दूरस्थ शाखा में बदल दिया गया है। यदि उस लाइन को स्थानीय परिवर्तन और दूरस्थ शाखा दोनों द्वारा बदल दिया गया है, तो वह रेखा लाल रंग से एनोटेट हो जाती है। यह मर्ज संघर्ष नहीं है। यह एक संभावित मर्ज संघर्ष है। यह एक हेडअप है जिसका उपयोग आप git pullदूरस्थ शाखा से करने से पहले भविष्य में मर्ज संघर्ष को हल करने के लिए कर सकते हैं ।

यहां छवि विवरण दर्ज करें


मज़ा टिप:

यदि आपने एक दूरस्थ शाखा प्राप्त की है जैसे कि:

git fetch origin feature/123

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

git checkout feature/123

अब आपको ऐसा करने की आवश्यकता नहीं है:

git checkout -b feature/123 origin/feature/123

उस पर और अधिक के लिए यहां पढ़ें


1
मुझे यह उत्तर पसंद है
१earning

44

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

  1. स्थानीय रेपो के अंदर इस दूरस्थ शाखा की नकल करने के लिए दूरदराज की शाखा से नए संचार की प्रतिलिपि बनाना।

    (रेपो ऑपरेशन के लिए रेपो) master@remote >> remote/origin/master@local

  2. स्थानीय शाखा में नए आवागमन को एकीकृत करना

    (अंदर-रेपो ऑपरेशन) remote/origin/master@local >> master@local

चरण 2 करने के दो तरीके हैं: आप कर सकते हैं:

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

में gitशब्दावली, चरण 1 है git fetch, चरण 2 है git mergeयाgit rebase

git pullहै git fetchऔरgit merge


36

Git रिमोट से लेटेस्ट वर्जन की ब्रांच को दो कमांड्स के जरिए लोकल तक पहुंचाता है:

  1. git fetch: Git को रिमोट से लोकल का लेटेस्ट वर्जन मिलने वाला है, लेकिन यह अपने आप मर्ज नहीं होता है।      git fetch origin master git log -p master..origin/master git merge origin/master

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

  2. गिट पुल: गिट रिमोट से नवीनतम संस्करण प्राप्त करने और स्थानीय में विलय करने जा रहा है।

        git pull origin master

         ऊपर का आदेश git fetchऔर के बराबर है git merge। व्यवहार में, git fetchशायद अधिक सुरक्षित क्योंकि मर्ज से पहले हम परिवर्तनों को देख सकते हैं और यह तय कर सकते हैं कि विलय करना है या नहीं।


36

बीच क्या अंतर है git pullऔर git fetch?

इसे समझने के लिए, आपको सबसे पहले यह समझने की जरूरत है कि आपका स्थानीय गिट न केवल आपकी स्थानीय रिपॉजिटरी का रखरखाव करता है, बल्कि यह रिमोट रिपॉजिटरी की एक स्थानीय प्रति भी रखता है।

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

git pullदूसरी ओर, दूरस्थ रिपॉजिटरी में उन परिवर्तनों को नीचे लाएगा जहाँ आप अपना कोड रखते हैं। आमतौर पर, दूरस्थ रिपॉजिटरी की स्थानीय प्रति को अद्यतित करने के लिए पहली बार git pullकरेगा git fetch, और फिर यह आपके अपने कोड रिपॉजिटरी और संभवत: आपकी वर्किंग कॉपी में बदलाव को मर्ज करेगा।


34

गिट पुल == (गिट लाने + गिट विलय)

git fetch स्थानीय शाखाओं में नहीं बदलता है।

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


33

स्पष्ट और सरल होने की कोशिश कर रहा है।

Git पुल आदेश वास्तव में एक है shortcutके लिए Git लाने के बाद Git मर्ज या Git रिबेस अपने कॉन्फ़िगरेशन के आधार पर आदेश। आप अपने गिट रिपॉजिटरी को कॉन्फ़िगर कर सकते हैं ताकि गिट पुल एक भ्रूण हो जो एक रिबेस के बाद हो।


33

शुरुआती लोगों के लिए एक सरल चित्रमय प्रतिनिधित्व,

यहां छवि विवरण दर्ज करें

यहाँ,

git pull  

अपने स्थानीय के साथ रिपॉजिटरी और रिबेस से कोड लाएंगे ... गिट पुल में नए कमिट बनने की संभावना है।

लेकीन मे ,

git fetch

रिपॉजिटरी से कोड लाएगा और हमें इसे मैन्युअल रूप से उपयोग करके रिबेट करना होगा git rebase

उदाहरण के लिए: मैं सर्वर मास्टर से लाने जा रहा हूं और अपने स्थानीय मास्टर में इसे वापस करूंगा।

1) गिट पुल (स्वचालित रूप से किया जाएगा)

git pull origin master

यहाँ मूल है आपका रिमोट रेपो मास्टर आपकी शाखा है

2) गिट लाने (मैन्युअल रूप से रिबेस करने की आवश्यकता):

git fetch origin master

यह मूल से सर्वर परिवर्तन लाएगा। और यह आपके स्थानीय में होगा जब तक आप इसे अपने दम पर वापस नहीं लेते। हमें कोड की जाँच करके मैन्युअल रूप से संघर्ष को ठीक करने की आवश्यकता है।

git rebase origin/master

यह कोड को लोकल में रीबेस कर देगा। इससे पहले कि आप सही शाखा में हैं यह सुनिश्चित करें।


अच्छा ग्राफ़, लेकिन आप यह बताना चाहते हैं कि जब आप "मर्ज" कहते हैं तो आप "रिबेस" का उपयोग क्यों करते हैं।
गुंटराम ब्लोह

1
मर्ज एक और शाखा कमेटी का प्रतिनिधित्व करेगा और नई कमिट का उत्पादन करेगा जिसमें एक संदर्भ के रूप में कमिट्स शामिल हैं। लेकिन रिबेट एक अन्य शाखा से आने वाले समय में पुनरावृत्ति करेगा, न कि यह दोहराए जाने के बजाय नई प्रतिबद्धता पैदा करेगा
मोहिदीन बिन मोहम्मद

33

वास्तव में Git आपके ही कोड और दूरस्थ रिपॉजिटरी की एक प्रति रखता है।

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

आदेश git pullदूरस्थ रिपॉजिटरी में उन परिवर्तनों को लाता है जहाँ आप अपना कोड रखते हैं। आम तौर पर, git pullदूरस्थ रिपॉजिटरी की स्थानीय कॉपी को तारीख तक लाने के लिए पहले एक 'गिट लाने' का काम करता है, और फिर यह आपके अपने कोड रिपॉजिटरी और संभवत: आपकी वर्किंग कॉपी में बदलाव को मर्ज कर देता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.