GET में FETCH_HEAD का क्या अर्थ है?

Question

git pull --help कहते हैं:

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

यह क्या है FETCH_HEADऔर वास्तव में किस दौरान विलय होता है git pull?

Comments

नोट: git 1.8.4 (अगस्त 2013) के बाद से, git fetch origin masterवास्तव में अपडेट होगा origin/master, न कि सिर्फ FETCH_HEAD। देखें stackoverflow.com/a/20967347/6309

— VonC

अधिक git merge FETCH_HEAD(Git 2.5, Q2 2015 के बाद से) के लिए, stackoverflow.com/a/30425991/6309 पर

— VonC

Answer 1

FETCH_HEADरिमोट रिपॉजिटरी से अभी-अभी जो प्राप्त हुआ है, उस पर नज़र रखने के लिए एक अल्पकालिक रेफरी है। git pullपहले आह्वान git fetch, सामान्य मामलों में रिमोट से एक शाखा लाने; FETCH_HEADइस शाखा के सिरे की ओर इशारा करता है (यह प्रतिबद्ध शा के SHA1 को संग्रहीत करता है, जैसे शाखाएँ करती हैं)। git pullफिर आह्वान git merge, FETCH_HEADवर्तमान शाखा में विलय ।

परिणाम वही है जो आप उम्मीद करेंगे: उपयुक्त दूरस्थ शाखा की नोक पर प्रतिबद्ध को आपकी वर्तमान शाखा की नोक पर मर्ज किया जाएगा।

यह थोड़ा सा है जैसे git fetchतर्कों के बिना (या git remote update), अपनी सभी दूरस्थ शाखाओं को अपडेट करना, फिर चलाना git merge origin/<branch>, लेकिन FETCH_HEADचीजों को नाम देने की आवश्यकता के बजाय जो भी एक रेफरी प्राप्त किया गया था, उसे संदर्भित करने के लिए आंतरिक रूप से उपयोग करना।

Comments

@ जेफ्रोमी: क्षमा करें, मुझे लगता है कि आप गलत हैं: जहां तक ​​मैं समझता हूं, git fetchरिमोट स्टोरेज से सभी ऑब्जेक्ट डेटा को अपडेट (विलय) करता है, न कि केवल एक ब्रंच। इसलिए मुझे आपके उत्तर से यह समझ में नहीं आता है कि किस दिशा में किस बिंदु की ओर इशारा किया जाए FETCH_HEAD। मैं FETCH_HEADgit प्रलेखन (परिभाषा, उदाहरण नहीं) में नहीं मिल सकता है । के अस्तित्व FETCH_HEADअधिक एक समाधान की तरह मेरे लिए दिखता है, बनाने के लिए git pullकाम किसी भी तरह ।

— एलेक्सी

एलेक्सी: स्थानीय रिपॉजिटरी कॉन्फ़िगरेशन FETCH_HEADद्वारा निर्दिष्ट दूरस्थ शाखा के सिरे से मेल खाती है branch.<BRANCH>.merge। इसलिए जब fetchवास्तव में दूरस्थ संग्रहण से सभी ऑब्जेक्ट डेटा प्राप्त होता है, तो FETCH_HEADयह इंगित करने के लिए उपयोग किया जाता है कि स्थानीय शाखा द्वारा ट्रैक की गई रिमोट शाखा कहाँ उन्नत हुई है। इसलिए यदि आप स्थानीय masterशाखा में हैं और दौड़ते हैं git fetch, और branch.master.mergeइशारा करते हैं refs/heads/master, तो भ्रूण ऑपरेशन के तुरंत बाद FETCH_HEADसमान मूल्य होगा origin/master।

— लार्क्स

@alexy FETCH_HEAD का वर्णन इसके मैन पेज में git लाने के दूसरे पैराग्राफ में किया गया है। मेरा उत्तर सही है। और तर्क के बिना git लाने से डिफ़ॉल्ट रिमोट के लिए सभी दूरस्थ शाखाओं को अपडेट किया जाता है ... लेकिन यह निश्चित रूप से विलय के समान नहीं है।

— कैस्केबेल जूल 27'12

FETCH_HEADयदि आप सभी दूरस्थ शाखाओं को प्राप्त करते हैं तो क्या होगा git fetch -a?

— स्टिगी

@stigi दूरस्थ ट्रैकिंग शाखा की टिप जो आपकी वर्तमान में जांची गई शाखा है, जो git config में इंगित कर रही है। ऊपर टिप्पणी में कृपया लार्क्स का जवाब देखें।

— अंकुर अग्रवाल

Answer 2

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

इसलिए अगर मैं जारी करता हूं:

git fetch https://github.com/ryanmaxwell/Fragaria

FETCH_HEAD हो सकता है

3cfda7cfdcf9fb78b44d991f8470df56723658d3        https://github.com/ryanmaxwell/Fragaria

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

git merge FETCH_HEAD

Comments

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

— टॉर्ज

Answer 3

जैसा कि जोनाथन के उत्तर में उल्लेख किया गया है , FETCH_HEAD फ़ाइल से मेल खाती है .git/FETCH_HEAD। आमतौर पर, फ़ाइल इस तरह दिखाई देगी:

71f026561ddb57063681109aadd0de5bac26ada9                        branch 'some-branch' of <remote URL>
669980e32769626587c5f3c45334fb81e5f44c34        not-for-merge   branch 'some-other-branch' of <remote URL>
b858c89278ab1469c71340eef8cf38cc4ef03fed        not-for-merge   branch 'yet-some-other-branch' of <remote URL>

ध्यान दें कि सभी शाखाएँ कैसे चिह्नित की जाती हैं not-for-merge। विषम एक वह शाखा है जिसे लाने से पहले जांच की गई थी। सारांश में: FETCH_HEAD अनिवार्य रूप से उस शाखा के दूरस्थ संस्करण से मेल खाती है जिसे वर्तमान में चेक आउट किया गया है।

Answer 4

मैंने अभी-अभी खोजा और उपयोग किया है FETCH_HEAD। मैं एक सर्वर से कुछ सॉफ्टवेयर की एक स्थानीय प्रतिलिपि चाहता था और मैंने किया

git fetch gitserver release_1

gitserverमेरी मशीन का नाम है जो गिट रिपॉजिटरी को स्टोर करता है। release_1सॉफ्टवेयर के एक संस्करण के लिए एक टैग है। मेरे आश्चर्य के लिए, release_1तब मेरे स्थानीय मशीन पर कहीं नहीं पाया गया था। मुझे टाइप करना था

 git tag release_1 FETCH_HEAD 

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

मेरी राय में यह उस उद्देश्य के लिए सबसे अच्छा है और जो मैं करने की कोशिश कर रहा था उसे प्राप्त करने का एक बेहतर तरीका है

git fetch gitserver release_1:release_1

रिलीज़ करने के लिए रिलीज़ 1_1 और इसे स्थानीय रूप से रिलीज़ 1 कहा जाता है। (यह स्रोत है: भाग्य, देखें https://git-scm.com/book/en/v2/Git-Internals-The-Refspec ; बस मामले में आप इसे एक अलग नाम देना चाहेंगे!)

आप FETCH_HEADकई बार उपयोग करना चाह सकते हैं : -

git fetch gitserver bugfix1234
git cherry-pick FETCH_HEAD

आपके Git सर्वर से बग फिक्स नंबर 1234 का उपयोग करने का एक अच्छा तरीका हो सकता है, और Git के कचरा संग्रह को छोड़कर सर्वर से कॉपी का निपटान करने के लिए एक बार फिक्स को आपके वर्तमान शाखा पर चेरी-पिक किया गया है। (मैं मान रहा हूँ कि सर्वर पर बग फिक्स के पूरे युक्त एक अच्छा स्वच्छ टैग है!)

Comments

दिलचस्प प्रतिक्रिया। +1

— वॉन

धन्यवाद। मैंने अपनी मूल पोस्ट को संपादित किया, जब मैंने पहली बार FETCH_HEAD की कुछ साल पहले खोज की थी, क्योंकि यह स्रोत के बजाय FETCH_HEAD का उपयोग करके टैग को कॉपी करने के लिए प्रोत्साहित करने के लिए प्रकट हुआ: Refspecs के लिए सिंटैक्स को नष्ट करें। उम्मीद है कि मैंने अब बेहतर उदाहरण दिया है कि कैसे FETCH_HEAD का उपयोग किया जा सकता है।

— इवान

Answer 5

गिट पुल एक मर्ज के बाद एक भ्रूण का संयोजन है। जब git fetch होता है तो यह FETCH_HEAD (सिर्फ एक फ़ाइल जो उस नाम में .git) में प्राप्त करता है, के सिर को नोट करता है और फिर ये कमिट्स आपके वर्किंग डायरेक्टरी में मर्ज हो जाते हैं।

Comments

@ मैनजॉल्ड्स, "आपके द्वारा प्राप्त किए गए सिर की प्रतिबद्धता " से आपका क्या तात्पर्य है ? गिट से सब कुछ मिलता है।

— एलेक्सी

@ मैनुअल से गिट मैनुअल: git-scm.com/docs/git-fetch : जिन

— JJ_Finnegan