संक्षिप्त और आसान जवाब यह है कि git pull बस git merge बाद git fetch ।

यह ध्यान रखना बहुत महत्वपूर्ण है कि 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 को git pull --rebase करने के लिए लुभाने वाले हो सकते हैं। जब तक आप वास्तव में नहीं जानते, आप वास्तव में जानते हैं कि आप क्या कर रहे हैं, मैं इसके खिलाफ सलाह दूंगा। यह चेतावनी man पेज से git-pull , संस्करण 2.3.5 :

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

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

एक fetch के साथ तीन repos:

---------------------     -----------------------     -----------------------
- 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+               -
---------------------     -----------------------     -----------------------

एक पुल के साथ तीन repos

---------------------     -----------------------     -----------------------
- 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+               -
---------------------     -----------------------     -----------------------

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

असल में गिट आपके अपने कोड और रिमोट रिपोजिटरी की एक प्रति रखता है।

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

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

git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS

git pull   …
DESCRIPTION

Runs git-fetch with the given parameters, and calls git-merge to merge the 
retrieved head(s) into the current branch. With --rebase, calls git-rebase 
instead of git-merge.

Note that you can use . (current directory) as the <repository> to pull 
from the local repository — this is useful when merging local branches 
into the current branch.

Also note that options meant for git-pull itself and underlying git-merge 
must be given before the options meant for git-fetch.

अगर आप इतिहास को विलय करना चाहते हैं तो आप खींचेंगे, अगर आप सिर्फ 'कोडेज़ चाहते हैं' तो आप कुछ लोग यहां कुछ लेख टैग कर रहे हैं।

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

git fetch
git diff ...origin

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

                                         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.

रिमोट के लेटे हुए दर्पण के लिए कुछ प्रमुख फायदे हैं:

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

शुरुआती के लिए एक साधारण ग्राफिकल प्रतिनिधित्व,

यहाँ,

git pull  

भंडार से कोड लाएगा और आपके स्थानीय के साथ पुन: प्रयास करेगा ... गिट खींचने में नए कामों की संभावना है।

लेकीन मे ,

गिट fetch

भंडार से कोड लाएगा और हमें इसका उपयोग करके इसे मैन्युअल रूप से रीबेज करने की आवश्यकता है git rebase

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

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

git pull origin master

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

2) गिट fetch (मैन्युअल रूप से rebase की जरूरत है):

git fetch origin master

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

git rebase origin/master

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

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

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

बोनस:

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

git pull --rebase

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

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

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

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

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

गिट पुल == (गिट fetch + गिट मर्ज)

गिट फ़ेच स्थानीय शाखाओं में नहीं बदलता है।

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

संक्षिप्त

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

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

अधिक

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

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

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

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

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

और git pull , git fetch , git clone और git rebase कवर शामिल हैं।

====

अद्यतन करें

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

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

   गिट fetch

2. अपडेट डाउनलोड करने के बाद, अंतरों को देखते हैं:

   गिट diff मास्टर मूल / मास्टर

3. यदि आप उन अपडेट से खुश हैं, तो विलय करें:

   गिट खींचो

टिप्पणियाँ:

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

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

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

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

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

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

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

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

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

आम तौर पर git pull रिमोट रिपोजिटरी की स्थानीय प्रतिलिपि को अद्यतित करने के लिए git fetch करके ऐसा करता है, और उसके बाद परिवर्तनों को अपने कोड भंडार में और संभवतः आपकी कार्यशील प्रति में विलय कर देता है।

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

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

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

सबसे सरल शब्दों में, git pull एक git merge करता है जिसके बाद git merge ।

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

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

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

गिट दस्तावेज: गिट पुल

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

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

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

गिट लाओच

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

गिट मर्ज

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

गिट पुल

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

git pull = git fetch + git merge 

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

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

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

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

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

git pull == git fetch + git merge

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

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

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

गिट fetch

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

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

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

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

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

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

गिट खींचो

यह स्थानीय से स्थानीय शाखा में रिमोट से परिवर्तन लागू करेगा ...

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

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

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

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

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

1

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

जब आप एक रिपॉजिटरी क्लोन करते हैं तो आप स्थानीय होस्ट में संपूर्ण भंडार प्राप्त करते हैं। इसका मतलब है कि उस समय आपके पास HEAD लिए मूल / मास्टर पॉइंटर होता है और मास्टर एक ही HEAD इंगित करता है।

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

तो अंतर होगा:

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

के बीच एकमात्र अंतर git pullऔर git fetchयह है कि:

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

git fetch केवल रिमोट शाखा से लाता है लेकिन यह विलय नहीं करता है

यानी गिट पुल = गिट fetch + गिट विलय ...

एक प्रतिबद्धता पूर्ववत करें और फिर से करें

$ git commit -m "Something terribly misguided"             # (1)
$ git reset HEAD~                                          # (2)
<< edit files as necessary >>                              # (3)
$ git add ...                                              # (4)
$ git commit -c ORIG_HEAD                                  # (5)

1. यही वह है जिसे आप पूर्ववत करना चाहते हैं
2. यह आपके काम करने वाले पेड़ (डिस्क पर आपकी फाइलों की स्थिति) को अपरिवर्तित छोड़ देता है लेकिन प्रतिबद्धता को कम करता है और आपके द्वारा किए गए परिवर्तनों को छोड़ देता है (इसलिए वे git status में "प्रतिबद्धता के लिए चरणबद्ध नहीं होते" के रूप में दिखाई देंगे, और आपको इसकी आवश्यकता होगी काम करने से पहले उन्हें फिर से जोड़ें)। यदि आप केवल पिछले प्रतिबद्धता में और अधिक परिवर्तन जोड़ना चाहते हैं, या प्रतिबद्ध संदेश ^{1 को} बदलना चाहते हैं, तो आप git reset --soft HEAD~ उपयोग कर सकते हैं, जो कि git reset HEAD~ तरह है git reset HEAD~ जहां HEAD~ HEAD~1 जैसा ही है ) लेकिन आपके मौजूदा परिवर्तन चरणबद्ध छोड़ देता है।
3. पेड़ की फाइलों में काम करने के लिए सुधार करें।
4. git add कुछ भी git add जो आप अपनी नई प्रतिबद्धता में शामिल करना चाहते हैं।
5. पुराने प्रतिबद्ध संदेश का पुन: उपयोग करते हुए परिवर्तनों को प्रतिबद्ध करें। reset पुराने सिर को .git/ORIG_HEAD कॉपी किया गया; -c ORIG_HEAD साथ commit एक संपादक खुल जाएगा, जिसमें प्रारंभ में पुराने प्रतिबद्धता से लॉग संदेश होता है और आपको इसे संपादित करने की अनुमति देता है। अगर आपको संदेश को संपादित करने की आवश्यकता नहीं है, तो आप -C विकल्प का उपयोग कर सकते हैं।

सावधान रहें कि अगर आपने इंडेक्स में कोई नया बदलाव जोड़ा है, तो commit --amend का उपयोग करके उन्हें आपकी पिछली प्रतिबद्धता में जोड़ दिया जाएगा।

यदि कोड पहले से ही आपके सर्वर पर धकेल दिया गया है और आपके पास इतिहास (रीबेस) को ओवरराइट करने की अनुमति है तो:

git push origin master --force

आप यह जवाब भी देख सकते हैं:

हेड वापस पिछले स्थान पर कैसे स्थानांतरित करें? (अलग सिर)

उपर्युक्त उत्तर आपको git reflog दिखाएगा जिसका उपयोग यह पता लगाने के लिए किया जाता है कि SHA-1 क्या है जिसे आप वापस करना चाहते हैं। एक बार जब आप उस बिंदु को पाते हैं जिसे आप ऊपर वर्णित आदेशों के अनुक्रम का उपयोग करने के लिए पूर्ववत करना चाहते हैं।

¹ नोट, हालांकि, अगर आपने अभी अपने प्रतिबद्ध संदेश में कोई गलती की है तो आपको पहले की प्रतिबद्धता पर रीसेट करने की आवश्यकता नहीं है। आसान विकल्प git reset (आपके द्वारा किए गए किसी भी बदलाव को git commit --amend ) और फिर git commit --amend , जो आपके डिफ़ॉल्ट प्रतिबद्ध संदेश संपादक को अंतिम प्रतिबद्ध संदेश के साथ पूर्व-पॉप्युलेट करेगा।