901

मैंने Git के साथ खेलना शुरू कर दिया है और "अपस्ट्रीम" और "डाउनस्ट्रीम" शब्दों में आ गया हूं। मैंने इन्हें पहले भी देखा है लेकिन कभी भी इन्हें पूरी तरह से नहीं समझा। SCM ( सॉफ़्टवेयर कॉन्फ़िगरेशन मैनेजमेंट टूल) और स्रोत कोड के संदर्भ में इन शब्दों का क्या अर्थ है ?

— ब्रेंडन
स्रोत

13

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

— charlesreid1

6

संबंधित: 'अपस्ट्रीम' का क्या अर्थ है? OS पर

— kenorb

5

संबंधित: gitHub पर मूल और अपस्ट्रीम के बीच अंतर

— RBT

703

स्रोत नियंत्रण के संदर्भ में, जब आप रिपॉजिटरी से कॉपी (क्लोन, चेकआउट आदि) करते हैं तो आप " डाउनस्ट्रीम " होते हैं। सूचना आपके लिए "डाउनस्ट्रीम" प्रवाहित हुई।

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

कभी-कभी आप "अपस्ट्रीम" में परिवर्तन प्रस्तुत करने की बात करते हुए पैकेज या रिलीज़ मैनेजर (लोगों, उपकरण नहीं) के बारे में पढ़ेंगे। आमतौर पर इसका मतलब है कि उन्हें मूल स्रोतों को समायोजित करना था ताकि वे अपने सिस्टम के लिए एक पैकेज बना सकें। वे उन परिवर्तनों को जारी नहीं रखना चाहते हैं, इसलिए यदि वे उन्हें मूल स्रोत पर "अपस्ट्रीम" भेजते हैं, तो उन्हें अगले रिलीज में उसी मुद्दे से नहीं निपटना चाहिए।

— ब्रायन डी फ़ोय
स्रोत

115

"डाउनलोड करें और" अपलोड करें "क्रिया हैं। "अपस्ट्रीम" और "डाउनस्ट्रीम" एक सापेक्ष स्थिति का वर्णन करते हैं।

— ब्रायन डी फॉय

2

मैं कहूंगा कि अपस्ट्रीम और डाउनस्ट्रीम विशेषण हैं

— Crt

8

वे विशेषण हैं जब उन्हें संशोधक के रूप में उपयोग किया जाता है, लेकिन उन शब्दों को अक्सर संज्ञा के रूप में उपयोग किया जाता है।

— ब्रायन डी फॉय

2

@MycrofD शब्दों का इस्तेमाल विशेषण और संज्ञा के रूप में किया जा सकता है जो संदर्भ के आधार पर है

— reggaeguitar

1

यह तकनीकी आवश्यकता के बजाय ज्यादातर एक सामाजिक मुद्दा है । फिर क्यों एक विकल्प है -uजैसे git push --set-upstream origin masterकि यह एक तकनीकी आवश्यकता नहीं है ? हम कर सकते हैं push -u originया बिना push origin, तो यह एक तकनीकी आवश्यकता है। लेकिन फर्क क्या है?

— ग्रीन

249

जब आप git tagमैन पेज में पढ़ते हैं :

गिट का एक महत्वपूर्ण पहलू यह वितरित किया जाता है, और बड़े पैमाने पर वितरित किया जा रहा है इसका मतलब है कि सिस्टम में कोई अंतर्निहित "अपस्ट्रीम" या "डाउनस्ट्रीम" नहीं है।

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

यदि "yourRepo" ने "otherRepo" को दूरस्थ रूप से घोषित किया है, तो :

आप कर रहे हैं नदी के ऊपर से खींच "otherRepo" ( "otherRepo" "नदी के ऊपर है से आप", और आप "नीचे की ओर कर रहे हैं के लिए otherRepo")।
आप अपस्ट्रीम पर जोर दे रहे हैं ("otherRepo" अभी भी "अपस्ट्रीम" है, जहां जानकारी अब वापस जाती है)।

"से" और "के लिए" पर ध्यान दें: आप सिर्फ "डाउनस्ट्रीम" नहीं हैं, आप " से / के लिए डाउनस्ट्रीम " हैं, इसलिए सापेक्ष पहलू।

डीवीसीएस (डिस्ट्रीब्यूटेड वर्जन कंट्रोल सिस्टम) ट्विस्ट यह है: आपको इस बात का कोई अंदाजा नहीं है कि वास्तव में आपके द्वारा घोषित रिमोट रिपोज के सापेक्ष अपने स्वयं के रेपोस्ट के नीचे क्या है।

आप जानते हैं कि अपस्ट्रीम क्या है (जिस रिपॉज को आप खींच रहे हैं या धक्का दे रहे हैं)
आप नहीं जानते कि बहाव किस चीज से बना है (दूसरे रेपो से खींचकर या अपने रेपो को धक्का देकर )।

मूल रूप से:

" डेटा के प्रवाह " के कार्यकाल में , आपका रेपो, अपस्ट्रीम रेपोस ("पुल") से आने वाले प्रवाह के निचले ("डाउनस्ट्रीम") पर है और वापस (उसी या अन्य) अपस्ट्रीम रेपो ("पुश टू") पर जा रहा है )।

आप git-rebaseमैन पेज में एक चित्र "UPSTREAM REBASE से प्राप्त करें" के साथ देख सकते हैं :

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

यह बुरा है क्योंकि एक "अपस्ट्रीम" रेपो के लिए, कई डाउनस्ट्रीम रेपो हो सकते हैं (जैसे कि अपस्ट्रीम एक से ऊपर की ओर खींचते हुए, रीजेड ब्रांच के साथ), उनमें से सभी डुप्लिकेट कमिट से निपटने के लिए संभावित रूप से हो सकते हैं।

फिर, डीवीसीएस में "डेटा के प्रवाह" के साथ, एक खराब कमांड "अपस्ट्रीम" में एक " लहर प्रभाव " हो सकता है।

नोट: यह डेटा तक सीमित नहीं है।
यह मापदंडों पर भी लागू होता है , जैसे कि git कमांड ("चीनी मिट्टी के बरतन" वाले) अक्सर आंतरिक रूप से अन्य git कमांड ("प्लंबिंग") कहते हैं। rev-parseमैन पेज देखें :

कई गिट पोर्सिलेनश कमांड्स झंडे का मिश्रण लेते हैं (अर्थात एक डैश के साथ शुरू होने वाले -पैरामीटर) और पैरामीटर अंतर्निहित git rev-listकमांड के लिए हैं जो वे आंतरिक रूप से उपयोग करते हैं और झंडे और अन्य मापदंडों के लिए जो वे नीचे की ओर उपयोग करते हैंgit rev-list । इस कमांड का इस्तेमाल उनके बीच अंतर करने के लिए किया जाता है।

— VonC
स्रोत

15

आप ऊपर की ओर से खींचते हैं , और आप ऊपर की तरफ धक्का देते हैं । नीचे की ओर धकेलना मुझे बहुत गलत लगता है

— knittl

1

@ एकिटल: आप सही कह रहे हैं। मैंने अपने उत्तर को अपने स्वयं के स्थानीय (और "डाउनस्ट्रीम") रेपो के सापेक्ष "अपस्ट्रीम" रेपो की भूमिका को बेहतर ढंग से दर्शाने के लिए प्रतिरूपित किया है।

— वॉन

85

अपस्ट्रीम (ट्रैकिंग से संबंधित)

अपस्ट्रीम शब्द का कुछ असंदिग्ध अर्थ भी है जैसा कि जीआईटी उपकरणों के सुइट में आता है, विशेष रूप से ट्रैकिंग के सापेक्ष

उदाहरण के लिए :

   $git rev-list --count --left-right "@{upstream}"...HEAD
   >4   12
प्रिंट होगा (के अंतिम कैश्ड मूल्य) प्रतिबद्ध के पीछे (बाएं) (दाएं) अपने वर्तमान कार्यशील शाखा के (संख्या और आगे, के सापेक्ष यदि कोई हो ) वर्तमान में दूरदराज के शाखा पर नज़र रखने के लिए इस स्थानीय शाखा के लिए। यह एक त्रुटि संदेश मुद्रित करेगा अन्यथा:
    >error: No upstream branch found for ''

जैसा कि पहले ही कहा जा चुका है, आपके पास एक स्थानीय रिपॉजिटरी के लिए किसी भी संख्या में रीमोट हो सकते हैं, उदाहरण के लिए, यदि आपने गितुब से रिपॉजिटरी का कांटा लिया है, तो 'पुल अनुरोध' जारी करें, आपके पास निश्चित रूप से कम से कम दो हैं: origin(आपका जाली वाला रेपो github) और upstream(github पर रेपो जिसे आपने कांटा था)। वे केवल विनिमेय नाम हैं, केवल 'git @ ...' url उन्हें पहचानता है।

आपकी .git/configपढ़ी:

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git@github.com:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = git@github.com:authorname/reponame.git

दूसरी ओर, GIT के लिए @ {upstream} का अर्थ अद्वितीय है:

यह 'कहा गया रिमोट' पर ' शाखा' (यदि कोई हो) है , जो आपके 'स्थानीय भंडार' पर 'वर्तमान शाखा' को ट्रैक कर रहा है ।

जब भी आप एक सादा git fetch/ जारी करते हैं git pull, तो यह वह शाखा होती है जिसे आप खींचते हैं / खींचते हैं ।

मान लें कि आपने जिस स्थानीय मास्टर शाखा की जाँच की है, उसके लिए दूरस्थ शाखा उत्पत्ति / मास्टर को ट्रैकिंग शाखा बनाना चाहते हैं। बस मुद्दा:

   $ git branch --set-upstream  master origin/master
   > Branch master set up to track remote branch master from origin.
इसमें 2 पैरामीटर जोड़े गए हैं .git/config:
   [branch "master"]
       remote = origin
       merge = refs/heads/master
अब प्रयास करें (बशर्ते 'अपस्ट्रीम' रिमोट में 'देव' शाखा हो)
   $ git branch --set-upstream  master upstream/dev
   > Branch master set up to track remote branch dev from upstream.
.git/config अब पढ़ता है:
   [branch "master"]
       remote = upstream
       merge = refs/heads/dev
git-push(1)मैनुअल पेज :
   -u
   --set-upstream
प्रत्येक शाखा के लिए जो अद्यतित है या सफलतापूर्वक धकेल दी गई है, अपस्ट्रीम (ट्रैकिंग) संदर्भ जोड़ें , जिसका उपयोग तर्क-कम गिट-पुल (1) और अन्य कमांड द्वारा किया जाता है। अधिक जानकारी के लिए, branch.<name>.mergegit-config (1) देखें।

git-config(1)मैनुअल पेज :
   branch.<name>.merge
परिभाषित करता है, साथ में branch.<name>.remote, दी गई शाखा के लिए अपस्ट्रीम शाखा। यह git fetch / git pull / git rebase को बताता है कि किस ब्रांच को मर्ज करना है और यह git पुश को भी प्रभावित कर सकता है (push.default देखें)। \ (...)
   branch.<name>.remote
जब शाखा में <name>, यह git fetch और git push को बताता है कि कौन से रिमोट को / पुश से लाना है। यदि कोई दूरस्थ कॉन्फ़िगर नहीं किया गया है, तो यह मूल के लिए डिफ़ॉल्ट है। यदि आप किसी शाखा पर नहीं हैं, तो मूल का भी उपयोग किया जाता है।

अपस्ट्रीम और पुश (गोत्चा)

मैनुअल पेज पर एक नज़र डालेंgit-config(1)

   git config --global push.default upstream
   git config --global push.default tracking  (deprecated)
यह उन शाखाओं के लिए आकस्मिक धक्का को रोकने के लिए है जिन्हें आप अभी तक धक्का देने के लिए तैयार नहीं हैं।

— पीटर होस्ट
स्रोत

4

git branch --help2018 तक के अंश :As this option had confusing syntax, it is no longer supported. Please use --track or --set-upstream-to instead.

— zezollo

59

यह अनौपचारिक शब्दावली का एक सा है।

जहां तक गिट की बात है, हर दूसरा रिपॉजिटरी सिर्फ एक रिमोट है।

आम तौर पर बोलना, अपस्ट्रीम वह जगह है जहां से आपको क्लोन किया गया है (उत्पत्ति)। डाउनस्ट्रीम कोई भी परियोजना है जो आपके काम को अन्य कार्यों के साथ एकीकृत करती है।

शब्द Git रिपॉजिटरी तक सीमित नहीं हैं।

उदाहरण के लिए, उबंटू एक डेबियन व्युत्पन्न है, इसलिए डेबियन उबंटू के लिए अपस्ट्रीम है।

— hasen
स्रोत

51

अपस्ट्रीम को हानिकारक कहा जाता है

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

उदाहरण के लिए, वह एक मर्ज के बारे में कहता है, जिसके परिणामस्वरूप ऐसा होता है

आपके द्वारा मर्ज की गई शाखा द्वारा बताई गई कमेटी आपके द्वारा किए गए कमिट के सीधे ऊपर थी

वह यह कहना चाहता है कि प्रतिबद्ध बी, ए के एकमात्र बच्चे का ... इकलौते बच्चे का एकमात्र बच्चा है, इसलिए बी को ए में विलय करना बी को इंगित करने के लिए रेफरी ए को स्थानांतरित करने के लिए पर्याप्त है। यह दिशा क्यों है "डाउनस्ट्रीम" के बजाय "अपस्ट्रीम" कहा जाना चाहिए, या इस तरह के शुद्ध सीधी-रेखा ग्राफ की ज्यामिति को "सीधे अपस्ट्रीम" क्यों कहा जाना चाहिए, पूरी तरह से अस्पष्ट है और शायद मनमाना है। ( git-mergeजब वह कहता है कि इस संबंध को समझाने के लिए पुरुष पृष्ठ इस संबंध को समझाने का एक बेहतर काम करता है, "वर्तमान शाखा प्रमुख नामित कमेटी का पूर्वज है।"

वास्तव में, चाकोन खुद को "डाउनस्ट्रीम" का उपयोग करने के लिए बाद में बिल्कुल उसी चीज का मतलब प्रतीत करता है, जब वह सभी बच्चों को हटाए गए प्रतिबद्ध के पुनर्लेखन की बात करता है:

इस फ़ाइल को पूरी तरह से अपने Git इतिहास से हटाने के लिए आपको 6df76 से सभी कमियों को फिर से लिखना होगा

मूल रूप से उन्हें ऐसा कोई स्पष्ट विचार नहीं है कि समय के साथ कमिट्स के इतिहास का जिक्र करने पर उन्हें "अपस्ट्रीम" और "डाउनस्ट्रीम" से क्या मतलब है। यह उपयोग अनौपचारिक है, तब, और प्रोत्साहित नहीं किया जाना चाहिए, क्योंकि यह सिर्फ भ्रमित है।

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

[अतिरिक्त ध्यान दें: मैं पहले चाकोन वाक्य के बीच के संबंध के बारे में सोच रहा हूं जो मैं ऊपर और git-mergeमैन पेज का हवाला देता हूं , और यह मेरे लिए होता है कि पूर्व बाद की गलतफहमी पर आधारित हो सकता है। मैन पेज एक ऐसी स्थिति का वर्णन करता है, जहां "अपस्ट्रीम" का उपयोग वैध है: तेजी से अग्रेषण अक्सर तब होता है जब "आप एक अपस्ट्रीम रिपॉजिटरी पर नज़र रख रहे हैं, तो आपने कोई स्थानीय परिवर्तन नहीं किया है, और अब आप एक नए में अपडेट करना चाहते हैं। ऊपर की ओर संशोधन। " इसलिए शायद चाकोन ने "अपस्ट्रीम" का इस्तेमाल किया क्योंकि उन्होंने इसे मैन पेज में देखा। लेकिन मैन पेज में एक रिमोट रिपॉजिटरी है; चॉकोन के तेजी से अग्रेषण के उद्धृत उदाहरण में कोई दूरस्थ रिपॉजिटरी नहीं है, बस स्थानीय रूप से निर्मित शाखाओं का एक जोड़ा है।]

— मैट
स्रोत

14

Git-rebase man पेज भी इस ओवरलोडिंग से ग्रस्त है: रिबासिंग से पहले चेक किए गए कमिट को "अपस्ट्रीम" कहा जाता है। यह भी, Chacon के उपयोग को प्रभावित कर सकता है।

— 22

@outis अजीब - git html डॉक्यूमेंटेशन में, रिबासिंग के रूप में संदर्भित करने से पहले शाखा की जाँच की जाती है <branch>।

— जेस्पर मथेसेन

अच्छी बात। कहीं न कहीं आम "गिट-शब्दावली" को इकट्ठा करने में मददगार होगा। विशेष रूप से newbies के लिए (या गिट में योगदान करने के लिए पीपीएल)। मुझे अच्छा समय बचा लिया होगा git मैन पेजों के शब्दांकन के लिए।

— सेबनाग

@ SebNag कुछ इस तरह? linuxacademy.com/blog/linux/git-terms-explained

— reggaeguitar

1

git-rebaseडॉक्स से यहाँ आया क्योंकि मैं पूरी तरह से उलझन में था कि क्यों एक कमिट रिफ को वहां "अपस्ट्रीम" कहा जाएगा (वास्तव में, मैं खुद पर संदेह कर रहा था क्योंकि मैंने इस शब्दावली को पहले नहीं देखा है)। चीजों को साफ़ करने के लिए @outis & @matt का धन्यवाद!

— बोरक बर्नार्ड

"डाउनस्ट्रीम" और "अपस्ट्रीम" की परिभाषा

अपस्ट्रीम (ट्रैकिंग से संबंधित)

अपस्ट्रीम और पुश (गोत्चा)

अपस्ट्रीम को हानिकारक कहा जाता है