GIT में HEAD, वर्किंग ट्री और इंडेक्स में क्या अंतर है?

Question

क्या कोई मुझे GAD में HEAD, वर्किंग ट्री और इंडेक्स के बीच का अंतर बता सकता है?

जो मैं समझता हूं, वे सभी विभिन्न शाखाओं के नाम हैं। क्या मेरी धारणा सही है?

---

संपादित करें

मुझे मिला

एक एकल गिट रिपॉजिटरी शाखाओं की एक मनमानी संख्या को ट्रैक कर सकती है, लेकिन आपका कामकाजी पेड़ उनमें से सिर्फ एक ("वर्तमान" या "चेक आउट" शाखा) से जुड़ा है, और हेड उस शाखा को इंगित करता है।

क्या इसका मतलब यह है कि हेड और वर्किंग ट्री हमेशा एक जैसे होते हैं?

Comments

आपके संपादन के संबंध में: बिल्कुल नहीं। HEADवर्तमान शाखा की नोक पर प्रतिबद्ध है। यदि आपने अभी-अभी शाखा की जाँच की है, अर्थात कोई संशोधित फ़ाइल नहीं है, तो इसकी सामग्री कार्यशील वृक्ष से मेल खाती है। जैसे ही आप कुछ भी संशोधित करते हैं, यह अब मेल नहीं खाता।

— कैसबेल

मुझे लगता है कि आपको इसे पढ़ना होगा: think-like-a-git.net

— Andrzej Du have

मैं Staging Areaउस सूची में एक भी जोड़ूंगा । क्या है HEAD, Working Tree, Indexऔर एकStaging Area

— ग्रीन

@ Jefromi का अंतिम वाक्य अधिक स्पष्ट होगा:> जैसे ही आप कुछ भी संशोधित करते हैं, वर्किंग ट्री अब HEAD कमिट से मेल नहीं खाता

— starscream_disco_party

किसी भी भविष्य में इसे पढ़ने के लिए, इन उत्तरों में से कुछ को समझने और महसूस करने का सबसे अच्छा तरीका यह है कि जो कुछ चल रहा है, उसे देखें और महसूस करें: यह अब तक सीखने का सबसे अच्छा साधन है: onlywei.github.io/explain.gov/with -d3 / # fetchrebase

— BKSpurgeon

Answer 1

उन विषयों पर कुछ अन्य अच्छे संदर्भ:

• मेरा गिट वर्कफ्लो

मैं इंडेक्स का उपयोग चेकपॉइंट के रूप में करता हूं ।

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

टिप्पणियाँ:

1. कार्यक्षेत्र (स्रोत) की निर्देशिका वृक्ष है फ़ाइलें है कि आप देख सकते हैं और संपादित करें।

2. सूचकांक एक एकल, बड़े, द्विआधारी में फ़ाइल है <baseOfRepo>/.git/index, जो वर्तमान शाखा में सभी फाइलों, उनके सूचीबद्ध करता है SHA1 चेकसम, समय टिकटों और फ़ाइल नाम - यह उस में फ़ाइलों की एक प्रतिलिपि के साथ एक और निर्देशिका नहीं है।

3. स्थानीय भंडार एक छिपा निर्देशिका (है .git) एक सहित objectsनिर्देशिका एक संकुचित "ब्लॉब" फ़ाइल के रूप में रेपो में हर फ़ाइल के सभी संस्करणों (स्थानीय शाखाओं और दूरदराज शाखाओं की प्रतियां) युक्त।

रेपो फाइलों की अलग-अलग प्रतियों के रूप में ऊपर दी गई छवि में दर्शाए गए चार 'डिस्क' के बारे में न सोचें।

• Git X से बेहतर क्यों है

• Git इज़ योर फ्रेंड नॉट ए फ़े वॉल्यूम। 3: Refs and Index

उन्हें मूल रूप से Git commits के लिए संदर्भ दिए गए हैं। रेफ के दो प्रमुख प्रकार हैं: टैग और प्रमुख।

• टैग निश्चित संदर्भ हैं जो इतिहास में एक विशिष्ट बिंदु को चिह्नित करते हैं, उदाहरण के लिए v2.6.29।
• इसके विपरीत, सिर हमेशा परियोजना विकास की वर्तमान स्थिति को प्रतिबिंबित करने के लिए ले जाया जाता है।

(ध्यान दें: जैसा कि टिमो हुओवेन ने टिप्पणी की थी , वे तीर वे नहीं हैं जो कमिट्स को इंगित करते हैं, यह वर्कफ़्लो ऑर्डर है , मूल रूप से तीर दिखा रहा है कि पहली प्रतिबद्ध कहाँ है और अंतिम है)1 -> 2 -> 3 -> 414

अब हम जानते हैं कि परियोजना में क्या हो रहा है।
लेकिन यहाँ क्या हो रहा है, यह जानने के लिए, अभी एक विशेष संदर्भ है जिसे हेड कहा जाता है। यह दो प्रमुख उद्देश्य प्रदान करता है:

• यह बताता है कि Git कौन सी फाइल लेने के लिए प्रतिबद्ध है जब आप चेकआउट करते हैं, और
• यह बताता है कि आपके द्वारा किए जाने पर नए कमिट्स को कहां रखा जाए।

जब आप git checkout refइसे HEADरेफरी को इंगित करते हैं तो आपने इसे निर्दिष्ट किया है और इससे फाइलें निकाली हैं। जब आप git commitइसे चलाते हैं तो एक नई प्रतिबद्ध वस्तु बनती है, जो करंट का बच्चा बन जाती है HEAD। आम तौर पर HEADसिर में से एक को इंगित करता है, इसलिए सब कुछ ठीक काम करता है।

Comments

बहुत बार git के बारे में पढ़ने के बाद मुझे कभी भी यह पूरी तरह से समझ में नहीं आया कि मैं वास्तव में निराश हो गया हूँ मैं f शब्द का उपयोग करना चाहता हूँ; लेकिन समुदाय में im! यूएई ने प्रमुखों का उल्लेख किया है, लेकिन ऊपर की छवियों में हमेशा एक ही हेड होता है, जहां आर शेष एफ ** एनजी हेड होता है? "आम तौर पर सिर में से एक को इंगित करता है, इसलिए सब कुछ ठीक काम करता है।" मैं आपको यह समझाने के लिए आग्रह करता हूं, उर बयान।

— नेकटविली

@neckTwi HEAD वह वर्तमान कमेंट है जिसके साथ आप काम कर रहे हैं ( stackoverflow.com/a/964927/6309 )। यह आमतौर पर "शाखा प्रमुखों" में से एक है (शाखाओं द्वारा संदर्भित कमिट्स में से एक, उक्त शाखाओं के सिरे का प्रतिनिधित्व करना )। लेकिन आप किसी भी कमिटमेंट को चेकआउट (और काम कर सकते हैं) कर सकते हैं। यदि आप एक कमिट की जांच करते हैं, जो (शाखा) प्रमुखों में से एक नहीं है, तो आप "अलग" मोड में हैं: stackoverflow.com/a/3965714/6309

— VonC

@ मैं सहमत हूँ, लेकिन मैं इस तरह से उन चित्रों को 5 साल पहले मिला ( hases.name/blog/2010/01/28/… )

— VonC

सूचकांक के बारे में, मुझे लगता है कि सबसे उपयोगी चीज जो कहा जा सकता है वह है "सूचकांक मंचन क्षेत्र के लिए सिर्फ एक और नाम है," @ @ अशरफ-आलम ने कहा। मुझे लगता है कि चर्चा के अधिकांश समय इसे मंचन क्षेत्र के रूप में संदर्भित किया जाता है, यही वजह है कि मैंने स्वचालित रूप से यह कनेक्शन नहीं बनाया कि यह सूचकांक के समान ही था।

— पीट

@Pete मैं सहमत हूँ। कैश और इंडेक्स के बीच अंतर के बारे में अधिक जानने के लिए, मेरे अन्य उत्तर stackoverflow.com/a/6718135/6309

— VONC

Answer 2

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

यहाँ इस अध्याय से यह चित्र दिखाया गया है:

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

ध्यान दें कि git commit -aएक चरण में परिवर्तन और प्रतिबद्ध होंगे।

Comments

"एक तस्वीर एक हजार शब्दों के बराबर होती है"। धन्यवाद जैकब .. और लिंक के लिए धन्यवाद।

— जॉयस बाबू

नोट: आजकल working treeपसंद किया जा रहा working directoryहै। देखें github.com/git/git/commit/...

— VonC

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

— Jazimov

@ जाजिमोव आप शायद सही हैं, लेकिन जैसा कि उन्होंने लिखा है, उन्होंने उस तस्वीर को प्रसिद्ध प्रो गिट बुक से लिया है, और उन्होंने एक लिंक प्रदान किया है। इस प्रकार, अगर तस्वीर में सुधार किया जा सकता है या यह गलत है, तो किसी को उस पुस्तक के लेखकों को बताना चाहिए ... सामान्य तौर पर, मैं ऐसा करने के लिए तैयार होऊंगा, लेकिन ईमानदार होने के लिए, मैं अभी भी एक शुरुआती शुरुआत हूं और अभी तक नहीं हूं समझ गए कि आपने क्या कहा, इसलिए मैं निश्चित रूप से उस मामले में गलत व्यक्ति हूं।

— बिनरूस

@ बाइनर्स: इस तरह की छवियों के थोक प्रजनन में खतरा यह है कि यह एक लेखक / पुस्तक द्वारा बनाई गई "गलत बयानी" का प्रचार करने का काम करता है। मुझे लगता है कि यह शाब्दिक बनाम कार्यात्मक व्याख्याओं का मामला है: शाब्दिक अर्थ में, सूचकांक वास्तव में रेपो में निहित है यदि आप रेपो फ़ोल्डर के तहत सब कुछ के रूप में रेपो को परिभाषित करते हैं। कार्यात्मक अर्थों में, हालांकि, सूचकांक GIT को रेपो में DAG को बनाए रखने में मदद करता है और इसे इसके बाहरी होने के बारे में सोचा जा सकता है।

— Jazimov

Answer 3

आपका काम करने वाला पेड़ वह है जो वास्तव में उन फाइलों में है, जिन पर आप अभी काम कर रहे हैं।

HEADशाखा के लिए एक संकेतक है या जिसे आपने अंतिम बार देखा था, और यदि आप इसे बनाते हैं, तो यह एक नई प्रतिबद्धता का जनक होगा। उदाहरण के लिए, यदि आप masterशाखा पर हैं, तो HEADइंगित करेंगे master, और जब आप प्रतिबद्ध होंगे, तो वह नई प्रतिबद्धता उस संशोधन का वंशज होगी जो masterइंगित किया गया है, और masterनई प्रतिबद्ध को इंगित करने के लिए अद्यतन किया जाएगा।

सूचकांक एक मचान क्षेत्र में जहां नए प्रतिबद्ध तैयार है। अनिवार्य रूप से, सूचकांक की सामग्री वह है जो नई कमिट में जाएगी (हालांकि यदि आप ऐसा करते हैं git commit -a, तो यह स्वचालित रूप से उन फ़ाइलों में सभी परिवर्तन जोड़ देगा जो Git को कमिट करने से पहले इंडेक्स के बारे में जानते हैं, इसलिए यह आपके काम करने वाले पेड़ की वर्तमान सामग्री को कम कर देगा। )। git addआपके अनुक्रमणिका में कार्यशील ट्री से फ़ाइलों को जोड़ेगा या अपडेट करेगा।

Comments

ब्रायन स्पष्टीकरण के लिए बहुत बहुत धन्यवाद। तो, काम करने वाले पेड़ में सभी अनकमिज़्ड परिवर्तन होते हैं। यदि मैं git प्रतिबद्ध -a के साथ अपने परिवर्तन करता हूं, तो उस विशिष्ट समय में मेरा कार्य ट्री और इंडेक्स समान होगा। जब मैं अपने केंद्रीय रेपो पर धकेलूंगा, तो तीनों समान होंगे। क्या मैं सही हूँ?

— जॉयस बाबू

@ विनोद बहुत। आपके पास काम करने वाले पेड़ में फाइलें हो सकती हैं, जिनके बारे में Git को पता नहीं है, और वे उन लोगों के साथ प्रतिबद्ध नहीं होंगे git commit -a( जिनके साथ आपको उन्हें जोड़ने की आवश्यकता है git add), इसलिए आपके काम करने वाले पेड़ में अतिरिक्त फाइलें हो सकती हैं जो आपके सूचकांक, आपके स्थानीय रेपो, या आपका रिमोट रेपो नहीं है।

— ब्रायन कैंपबेल

@ विनोद: वर्किंग ट्री और इंडेक्स बिना कमिटमेंट के समान हो सकते हैं (git add working index से इंडेक्स को अपडेट करता है, और git checkout <path> इंडेक्स से वर्किंग ट्री अपडेट करता है)। HEADसबसे हालिया प्रतिबद्ध को संदर्भित करता है, इसलिए जब आप प्रतिबद्ध होते हैं, तो आप HEADअपनी नई कमेटी को अपडेट कर रहे होते हैं , जो सूचकांक से मेल खाता है। पुश करने का इससे कोई लेना-देना नहीं है - यह आपके स्थानीय रेपो में दूरस्थ मिलान शाखाओं में शाखाएँ बनाता है।

— कैसबेल

Answer 4

काम करने का पेड़

आपका काम करने वाला पेड़ वो फाइलें हैं जिन पर आप अभी काम कर रहे हैं।

Git सूचकांक

• Git "index" वह जगह है जहां आप उन फ़ाइलों को रखते हैं जिन्हें आप git रिपॉजिटरी के लिए प्रतिबद्ध करना चाहते हैं।

• इंडेक्स को कैशे , डायरेक्टरी कैशे , करंट डायरेक्टरी कैशे , स्टेजिंग एरिया , स्टेज्ड फाइल्स के रूप में भी जाना जाता है ।

• इससे पहले कि आप "रिपीट" (चेकइन) फाइलों को गिट रिपॉजिटरी में करें, आपको पहले फाइल को "इंडेक्स" में रखना होगा।

• सूचकांक है नहीं कार्यशील निर्देशिका: आप इस तरह के रूप में एक आदेश टाइप कर सकते हैं git status, और Git आपको बता देंगे कि आपके काम कर निर्देशिका में फ़ाइलों Git सूचकांक में जोड़ा गया है (उदाहरण के लिए, का उपयोग करके git add filenameआदेश)।

• इंडेक्स git रिपॉजिटरी नहीं है: git इंडेक्स की फाइलें ऐसी फाइल होती हैं जो git रिपॉजिटरी के लिए प्रतिबद्ध होती हैं यदि आपने git कमिट का उपयोग किया है।

Comments

ध्यान दें कि Git 2.5 कई कार्यशील पेड़ों ( stackoverflow.com/a/30185564/6309 ) को लाएगा । +1

— वॉन

मुझे यकीन नहीं है कि "इंडेक्स इज़ द वर्किंग डायरेक्टरी" 100% सही है। यह "इंडेक्स इज़ द वर्किंग डायरेक्टरी नहीं होना चाहिए, लेकिन इसमें संपूर्ण वर्किंग डायरेक्टरी + बदलाव शामिल हैं जिन्हें आप आगे करना चाहते हैं"। सबूत? git रिपॉजिटरी में जाएं, reset --hard HEADयह सुनिश्चित करने के लिए कि आपका इंडेक्स == आपका वर्किंग ट्री है। mkdir history && git checkout-index --prefix history/ -aa : परिणाम आपकी history/निर्देशिका में आपके संपूर्ण कार्यशील वृक्ष का दोहराव है । एर्गो गिट इंडेक्स> = गिट वर्किंग डायरेक्टरी

— एडम कुर्कविक्ज़

अनुक्रमणिका कार्यशील निर्देशिका नहीं है और इसमें कार्यशील निर्देशिका शामिल नहीं है। अनुक्रमणिका सिर्फ गिट रिपॉजिटरी के भीतर एक फ़ाइल है जो जानकारी को संग्रहीत करती है कि आप क्या करना चाहते हैं।

— बून

"इंडेक्स" वर्किंग ट्री की सामग्री का एक स्नैपशॉट रखता है, और यह स्नैपशॉट है जिसे अगले कमेंट की सामग्री के रूप में लिया जाता है। इस प्रकार वर्किंग डायरेक्टरी में कोई भी बदलाव करने के बाद, और कमिट कमांड चलाने से पहले, आप किसी भी नई या संशोधित फ़ाइलों को इंडेक्स में जोड़ने के लिए ऐड कमांड का उपयोग करना चाहिए "( git-scm.com/docs/git-add )

— anth

@AdamKurkiewicz: सबूत विफल रहता है अगर आप पहले echo untracked-data > untracked-file, पहले या बाद में git reset --HARDऔर git checkout-indexकदम दूर है। आप पाएंगे कि अनुपलब्ध फ़ाइल निर्देशिका में नहीं है history। आप इंडेक्स और वर्क-ट्री दोनों को स्वतंत्र रूप से संशोधित कर सकते हैं, हालांकि पहली बार वर्क-ट्री को छूए बिना इंडेक्स को संशोधित करना कठिन है (उपयोग करने की आवश्यकता है git update-index --index-info)।

— torek