2011-04-11 9 views
248

अक्सर, Git और रेल जादू की तरह दिखता है ... इस तरह के first chapter of Rails 3 Tutorial book में के रूप में, यह Git बारे में बात करती:"गिट रिमोट एड ..." और "गिट पुश मूल मास्टर" क्या है?

git remote add origin [email protected]:peter/first_app.git 
git push origin master 

और यह काफी कहते हैं, "यह सिर्फ काम करता है" वे क्या कर रहे हैं के बारे में बहुत ज्यादा कह बिना और शाखाकरण के बारे में बात करना शुरू करें। नेट शो पर खोज करना कि git remote add एक "छोटा नाम" जोड़ना है, जैसे कि origin, और यह कोई भी नाम हो सकता है, जो किसी यूआरएल के उपनाम की तरह है। और origin रिमोट रेपो कहां से सामान्य मार्ग है। (http://git-scm.com/book/en/Git-Basics-Working-with-Remotes में "रिमोट रेपॉजिटरीज जोड़ना" के तहत)

तो यूआरएल git://[email protected]/peter/first_app.git क्यों नहीं है लेकिन अन्य वाक्यविन्यास में - यह वाक्यविन्यास क्या है? यह .git के साथ क्यों समाप्त होना चाहिए? मैंने अंत में .git का उपयोग नहीं करने की कोशिश की और यह भी काम करता है। यदि .git नहीं है, तो यह और क्या हो सकता है? git[email protected] में गिट सर्वर पर एक उपयोगकर्ता खाता प्रतीत होता है?

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

कभी-कभी यह स्पष्टीकरण के बिना बहुत सारे जादू की तरह लगता है ... और कभी-कभी इसका उपयोग करने वाला व्यक्ति इतना आत्मविश्वासपूर्ण होता है और जब पूछा जाता है कि क्यों इसे समझा नहीं सकता है, और "जैसा तरीका है" जैसा कुछ जवाब देता है। कभी-कभी बहुत व्यावहारिक और व्यावहारिक। व्यावहारिक होना बुरा नहीं है, लेकिन संभवत: यह जानने के लिए व्यावहारिक नहीं है कि क्या हो रहा है।

उत्तर

293

git यूनिक्स की तरह है। उपयोगकर्ता के अनुकूल लेकिन अपने दोस्तों के बारे में picky। यह एक शक्तिशाली पाइपलाइन के रूप में शक्तिशाली और उपयोगकर्ता के अनुकूल है।

कहा जा रहा है कि, एक बार जब आप इसके प्रतिमान और अवधारणाओं को समझ लेते हैं, तो यह वही ज़ेन जैसी स्पष्टता है कि मैं यूनिक्स कमांड लाइन टूल्स से अपेक्षा करता हूं। आपको ऑनलाइन उपलब्ध कई अच्छे गिट ट्यूटोरियल में से एक को पढ़ने के लिए कुछ समय निकालना चाहिए। प्रो गिट बुक शुरू करने के लिए एक अच्छी जगह है।

अपने पहले प्रश्न का उत्तर देने के लिए।

  1. क्या git remote add ...

    कि आप जानते ही है, git एक वितरित संस्करण नियंत्रण प्रणाली है। अधिकांश ऑपरेशन स्थानीय रूप से किए जाते हैं। बाहरी दुनिया के साथ संवाद करने के लिए, gitremotes कहलाता है। ये आपकी स्थानीय डिस्क पर एक के अलावा भंडार हैं जो आप push में अपने परिवर्तन (ताकि अन्य लोग उन्हें देख सकें) या pull (ताकि आप दूसरों को बदल सकें)। git remote add origin [email protected]:peter/first_app.git पर स्थित origin नामक एक नया रिमोट बनाता है। एक बार ऐसा करने के बाद, अपने पुश कमांड में, आप पूरे URL को टाइप करने के बजाय origin पर जा सकते हैं।

  2. क्या git push origin master

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

अब परिवहन के बारे में (यानी git://) का अर्थ है। रिमोट रिपोजिटरी यूआरएल कई प्रकार के हो सकते हैं (file://, https:// इत्यादि)। गिट बस अनुमतियों और सामानों का ख्याल रखने के लिए परिवहन द्वारा प्रदान की गई प्रमाणीकरण तंत्र पर निर्भर करता है। इसका मतलब है कि file:// यूआरएल के लिए, यह यूनिक्स फ़ाइल अनुमतियां इत्यादि होगी। git:// योजना गिट को अपने आंतरिक परिवहन प्रोटोकॉल का उपयोग करने के लिए कह रही है, जिसे आसपास के गिट परिवर्तन भेजने के लिए अनुकूलित किया गया है। सटीक यूआरएल के लिए, जिस तरह से जीथ्यूब ने git सर्वर स्थापित किया है, वैसे ही यह तरीका है।

अब शब्दशः। आपके द्वारा टाइप किया गया आदेश सामान्य है। गिट कुछ ऐसा कहना संभव है जैसे "master नामक शाखा को foo नामक शाखा का स्थानीय दर्पण bar कहा जाता है"। गिट बोलने में, इसका मतलब है कि masterbar/foo ट्रैक करता है। जब आप पहली बार क्लोन करते हैं, तो आपको master नामक शाखा मिल जाएगी और मूल पर मास्टर को ट्रैक करने के लिए स्थानीय मास्टर सेट के साथ origin (जहां से आप क्लोन किया गया) नामक एक शाखा प्राप्त करेंगे। एक बार यह स्थापित हो जाने के बाद, आप बस git push कह सकते हैं और यह ऐसा करेगा। यदि आपको इसकी आवश्यकता हो तो लंबी कमांड उपलब्ध है (उदा। git push आधिकारिक सार्वजनिक रेपो को धक्का दे सकता है और git push review master का उपयोग एक अलग रिमोट को धक्का देने के लिए किया जा सकता है, जिसे आपकी टीम कोड की समीक्षा करने के लिए उपयोग करती है)। git branch कमांड के --set-upstream विकल्प का उपयोग करके आप अपनी शाखा को एक ट्रैकिंग शाखा के रूप में सेट कर सकते हैं।

मुझे लगा है कि गिट (मैंने उपयोग किए गए अधिकांश अन्य ऐप्स के विपरीत) अंदरूनी से बेहतर समझा जाता है। एक बार जब आप समझते हैं कि भंडार के अंदर डेटा कैसे संग्रहीत और बनाए रखा जाता है, तो आदेश और वे क्या करते हैं क्रिस्टल स्पष्ट हो जाते हैं। मैं आपसे सहमत हूं कि git उपयोगकर्ताओं के बीच कुछ elitism है, लेकिन मैंने यह भी पाया कि यूनिक्स उपयोगकर्ताओं के साथ एक समय पर, और सिस्टम को सीखने के लिए उनके पीछे खेती करने लायक था। सौभाग्य!

+6

आप अपने अनुच्छेद में एक नोट जोड़ना चाहते हैं कि '[email protected]: पीटर/first_app.git' गिट में एसएसआर यूआरएल के लिए' एसपीपी 'शैली वाक्यविन्यास है। एक अन्य बिंदु यह है कि, डिफ़ॉल्ट रूप से, 'मास्टर' की अपस्ट्रीम कॉन्फ़िगरेशन' गिट पुश 'के व्यवहार को प्रभावित नहीं करता है * जब तक आपके पास' push.default' 'ट्रैकिंग' पर सेट नहीं होता है (या बाद के संस्करणों में' अपस्ट्रीम ') - मैंने भ्रम के इस स्रोत के बारे में एक ब्लॉग पोस्ट किया: http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/ –

+1

एक छोटा सुधार उस टिप्पणी - 'push.default' के बिना अपस्ट्रीम कॉन्फ़िगरेशन का उपयोग डिफ़ॉल्ट रिमोट को खोजने के लिए किया जाएगा जब आप' गिट पुश 'का उपयोग करते हैं, लेकिन रेफरी के मैपिंग को प्रभावित नहीं करेंगे। –

+0

क्या यह सही है ... अन्य VCS I जैसे TortoiseSVN का उपयोग बहुत ही "ब्लैक बॉक्स" लगता है ... कुछ सरल कमांड जो बहुत स्पष्ट परिभाषित तरीकों से काम करते हैं। इसे सीखना एक घंटे से भी कम समय लेता है, और हर कोई इस बारे में काफी स्पष्ट है कि यह कैसे है। गिट या एचजी के साथ, यह 1-यूनिट सेमेस्टर कक्षा की तरह लगता है। और जब कुछ भी होता है, तो लोग इतने निश्चित नहीं होते कि क्या हो रहा है और इसे कैसे ठीक किया जाए। [cont'd] –

5
  1. भंडार नाम के अंत में .git सिर्फ एक सम्मेलन है। आमतौर पर, गिट सर्वर भंडारों पर project.git नामक निर्देशिकाओं में रखा जाता है। गिट क्लाइंट और प्रोटोकॉल project.git के लिए परीक्षण करके इस सम्मेलन का सम्मान करता है जब केवल project निर्दिष्ट होता है।

  2. git://[email protected]/peter/first_app.git मान्य गिट यूआरएल नहीं है। here निर्दिष्ट विभिन्न यूआरएल योजनाओं के माध्यम से गिट भंडारों की पहचान और उपयोग किया जा सकता है। [email protected]:peter/first_app.git उस पृष्ठ पर उल्लिखित ssh यूआरएल है।

  3. git लचीला है। यह आपको किसी भी भंडार की लगभग किसी भी शाखा के खिलाफ अपनी स्थानीय शाखा को ट्रैक करने की अनुमति देता है। master (आपकी स्थानीय डिफ़ॉल्ट शाखा) ट्रैकिंग origin/master (रिमोट डिफ़ॉल्ट शाखा) एक लोकप्रिय स्थिति है, यह सार्वभौमिक नहीं है। कई बार आप ऐसा नहीं करना चाहेंगे। यही कारण है कि पहला git push इतना वर्बोज़ है। यह git pull या git push पर स्थानीय master शाखा के साथ क्या करना है, यह बताता है।

  4. git push और git pull के लिए डिफ़ॉल्ट वर्तमान शाखा के रिमोट के साथ काम करना है। यह मूल मास्टर की तुलना में एक बेहतर डिफ़ॉल्ट है। जिस तरह से गिट पुश निर्धारित करता है यह here समझाया गया है।

git काफी सुंदर और सुबोध है, लेकिन वहाँ एक सीखने की अवस्था के माध्यम से चलने के लिए है।

+1

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

35

अपडेट: ध्यान दें कि वर्तमान में स्वीकृत उत्तर common misunderstanding को git push के व्यवहार के बारे में बताता है, जिसे किसी टिप्पणी के बावजूद ठीक नहीं किया गया है।

आपके रिमोट के यूआरएल के लिए उपनाम की तरह - क्या रिमोट्स का सारांश है - सही है।

तो यूआरएल क्यों गिट नहीं करता है: //[email protected]/peter/first_app.git लेकिन अन्य वाक्यविन्यास में - यह वाक्यविन्यास क्या है? इसे अंत में क्यों समाप्त करना चाहिए? मैंने अंत में .git का उपयोग नहीं करने की कोशिश की और यह भी काम करता है। यदि नहीं .git, यह और क्या हो सकता है? शुरुआत में गिट गिट सर्वर पर उपयोगकर्ता खाता प्रतीत होता है?

आपके द्वारा वर्णित दो यूआरएल इंगित करते हैं कि दो अलग-अलग परिवहन प्रोटोकॉल का उपयोग किया जाना चाहिए। git:// से शुरू होने वाला एक गिट प्रोटोकॉल के लिए है, जिसे आम तौर पर केवल भंडारों तक केवल पढ़ने के लिए उपयोग के लिए उपयोग किया जाता है। दूसरा, [email protected]:peter/first_app.git, एसएसएच पर एक भंडार तक पहुंच निर्दिष्ट करने के विभिन्न तरीकों में से एक है - यह the documentation में वर्णित "एसपीपी-शैली वाक्यविन्यास" है। एसपीपी-शैली सिंटैक्स में उपयोगकर्ता नाम git है जिस तरह से गिटहब उपयोगकर्ताओं को पहचानने के तरीके से संबंधित है - अनिवार्य रूप से उपयोगकर्ता नाम को अनदेखा किया जाता है, और उपयोगकर्ता को एसएसएच कुंजी-जोड़ी के आधार पर पहचाना जाता है जिसे वे प्रमाणित करते थे।

git push origin master की वर्बोजिटी के लिए, आपने देखा है कि पहले पुश के बाद, आप बस git push कर सकते हैं। इस मुश्किल से याद बल्कि आम तौर पर-उपयोगी चूक की एक श्रृंखला :)

  • तो कोई रिमोट निर्दिष्ट किया जाता है, दूरस्थ (आपके मामले में remote.master.url में) वर्तमान शाखा के लिए कॉन्फ़िगर प्रयोग किया जाता है की वजह से है। यदि यह सेट नहीं है, तो origin का उपयोग किया जाता है।
  • यदि कोई "रेफस्पेक" नहीं है (उदा। master, master:my-experiment, आदि) निर्दिष्ट है, तो रिमोट पर शाखा के समान नाम वाली प्रत्येक स्थानीय शाखा को धक्का देने के लिए डिफ़ॉल्ट गिट करें। यदि आपके पास अपनी रिपोजिटरी और रिमोट एक के बीच आम तौर पर master नामक शाखा है, तो यह आपके master को दूरस्थ master पर धक्का देने जैसा ही होगा।

व्यक्तिगत रूप से, के बाद से मैं कई विषय शाखाओं (और अक्सर कई रिमोट) हो जाते हैं मैं हमेशा फार्म का उपयोग करें:

git push origin master 

... गलती से अन्य शाखाओं को आगे बढ़ाने से बचने के लिए।


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

मेरा विचार है कि git साथ, यह सीखने की अवस्था यह बिल्कुल लायक है। यह सिर्फ दुर्भाग्यपूर्ण है कि:

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

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

+0

@Noufal इब्राहिम: मैं आपके सभी बिंदुओं पर सहमत हूं। मैं गिट लोगों पर एसवीएन अवधारणाओं को "मानचित्रण" करने का सुझाव नहीं दे रहा था, क्योंकि मुझे पता है कि भयानक भ्रम पैदा हो सकता है - हालांकि शीर्ष-नीचे से गिट को पढ़ाने के बेहतर तरीके हैं। –

संबंधित मुद्दे