गिटहब पर फोर्किंग और क्लोनिंग के बीच क्या अंतर है?

Question

मैं एक परियोजना के कांटा करने और इसके बारे में करने के बीच के अंतरों को जानना चाहता हूं clone।

अगर मैंने एक प्रोजेक्ट कांटा किया है तो क्या मैं केवल GitHub के माध्यम से पुल अनुरोध भेज सकता हूं?

Comments

के संभावित डुप्लिकेट Are Git कांटे वास्तव में Git क्लोन?

— j08691

उन लोगों के लिए जो यहां "कांटा" के स्पष्टीकरण के लिए Git (GitHub नहीं) के साथ तलाश कर रहे हैं। Git पर कोई "fork" कमांड नहीं है। यह अधिक GitHub (Git नहीं), अवधारणा है। एक भेद आसानी से भूल गया।

— 13

Answer 1

असल में, हाँ। ए forkसिर्फ गिटहब के लिए एक अनुरोध है कि परियोजना को क्लोन करें और इसे अपने उपयोगकर्ता नाम के तहत पंजीकृत करें ; GitHub भी दो रिपॉजिटरी के बीच संबंधों का ट्रैक रखता है, इसलिए आप दो प्रोजेक्ट्स (और अन्य कांटे) के बीच कमिट और पुल की कल्पना कर सकते हैं।

आप अभी भी अनुरोध कर सकते हैं कि लोग आपके क्लोन किए गए भंडार से खींच लें, भले ही आप उपयोग न करें fork- लेकिन आपको इसे स्वयं सार्वजनिक रूप से उपलब्ध कराने से निपटना होगा। या डेवलपर्स पैच (देखें git format-patch) भेजें कि वे अपने पेड़ों पर लागू कर सकते हैं।

Comments

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

— jww

@jww को क्लोन के साथ चिपकाने के लिए सबसे अच्छा लगता है - कांटा का उपयोग क्यों करें?

— सेरुप

@serup - इसका कारण यह है कि कांटे की नकल git pulled हो सकती है , इसलिए अभी भी किसी प्रकार का संबंध मौजूद है। यदि आपने पूरी प्रति को अपने स्वयं के स्थानीय मशीन पर बैठा दिया और मूल रेपो से डिस्कनेक्ट कर दिया।

— जॉन

Answer 2

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

संक्षेप में:

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

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

अन्य रोचक किस्सों की जोड़ी -

क्या वास्तव में गिट क्लोन हैं?

मैं एक GitHub रिपॉजिटरी को कैसे अपडेट करूं?

Comments

"यहाँ ध्यान देने की मुख्य बात यह है कि मूल भंडार में किए गए कोई भी परिवर्तन आपके कांटे हुए भंडार में वापस दिखाई देंगे।" मुझे लगता है कि थोड़ा भ्रामक है। AFAIK, कांटा के बाद मूल भंडार में किए गए परिवर्तन स्वचालित रूप से कांटे में परिलक्षित नहीं होते हैं ; आपको उन परिवर्तनों को मैन्युअल रूप से स्थानांतरित करना होगा। जब आप कांटा बटन पर क्लिक करते हैं तो कांटे से पहले हुए परिवर्तन नए कांटे में कॉपी हो जाते हैं।

— अजादि32

"मूल रिपॉजिटरी में किए गए किसी भी परिवर्तन को आपके फोर्क्ड रिपॉजिटरी में वापस दिखाया जाएगा" .. वास्तव में ?? स्वचालित रूप से मुझे आशा नहीं है

— KansaiRobot

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

— user3075740 7

कांटा के बाद मूल रिपॉजिटरी में किए गए परिवर्तन स्वचालित रूप से कांटा में परिलक्षित नहीं होते हैं, लेकिन ऐसा करने के लिए, इस ब्लॉग के चरण 3 की जांच करें: - help.github.com/articles/fork-a-repo

— Suhas

"मूल रिपॉजिटरी में किए गए किसी भी परिवर्तन को आपके फोर्क्ड रिपॉजिटरी में वापस प्रतिबिंबित किया जाएगा" - क्या आपको लगता है कि क्लोन के बाद यह संभव नहीं है?

— चर

Answer 3

• फोर्कड प्रोजेक्ट आपके ऑनलाइन रिपॉजिटरी (रेपो) पर है।
• आपके स्थानीय मशीन पर क्लोन प्रोजेक्ट है (मैं आमतौर पर रेपो को फोर्क करने के बाद क्लोन करता हूं)।

आप अपने ऑनलाइन रेपो पर (या अपने स्थानीय रेपो पर कमिट कर सकते हैं और फिर अपने ऑनलाइन रेपो पर पुश कर सकते हैं), फिर पुल अनुरोध भेजें।

प्रोजेक्ट मैनेजर इसे अपने मुख्य ऑनलाइन संस्करण में आपके परिवर्तन प्राप्त करने के लिए स्वीकार कर सकता है।

Answer 4

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

जब आप किसी सर्वर पर रेपो फोर्क करते हैं, तो सामग्री के दोहराव की कोई आवश्यकता नहीं होती है क्योंकि दोनों रेपो उसी सर्वर से समान [निश्चित वस्तु] सामग्री का उपयोग करेंगे। 'चाल' अलग-अलग उपयोगकर्ता के दृष्टिकोण को प्रबंधित करने में है ताकि प्रत्येक उपयोगकर्ता का मानना ​​है कि उनके पास रेपो की एक पूरी व्यक्तिगत प्रति है। कांटे के बीच पुश और भ्रूण बस उपयोगकर्ता के संकेत को अपडेट करता है।

निचले स्तर पर, गिट आंतरिक रूप से एक ही काम करता है। यदि आपके पास तीन अलग-अलग फाइलें हैं, जिनमें से प्रत्येक में है Hello World, तो हैलो वर्ल्ड ब्लॉब की अपनी एकल प्रति 'कांटे' की 'कॉपी' करें और आवश्यकतानुसार तीनों स्थानों में से प्रत्येक में इसे प्रस्तुत करें।

सर्वर पर कांटे की क्षमता का मतलब है कि गितुब का बड़ा भंडारण भत्ता औसत रूप से उतना बड़ा नहीं है जितना कि हर शरीर एक एकल रेपो को साझा करता है।

Answer 5

संक्षेप में, फोर्किंग संभवतः "आपके गिटहब आईडी / प्रोफाइल के तहत क्लोनिंग" के समान है। कुछ अपवादों के साथ एक कांटा कभी भी क्लोन से बेहतर होता है, जाहिर है। कांटे हुए रिपॉजिटरी को हमेशा क्लोन किए गए रिपॉजिटरी के विपरीत मूल रिपॉजिटरी के साथ निगरानी / तुलना की जा रही है। यह आपको परिवर्तनों को ट्रैक करने में सक्षम बनाता है, पुल अनुरोधों को आरंभ करता है और अपने forked के साथ मूल भंडार में किए गए परिवर्तनों को मैन्युअल रूप से सिंक करता है।

Answer 6

जबकि @ अनिकेतखाकुर का जवाब बहुत अच्छा है। निम्नलिखित प्रश्न का उत्तर अभी तक किसी ने नहीं दिया है।

अगर मैंने एक प्रोजेक्ट कांटा किया है तो क्या मैं केवल GitHub के माध्यम से पुल अनुरोध भेज सकता हूं?

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

Answer 7

मामले में आपने वह किया जो प्रश्नकर्ता ने संकेत किया था (कांटा भूल गए और सिर्फ स्थानीय रूप से एक रेपो का क्लोन बनाया, परिवर्तन किए और अब एक पुल अनुरोध जारी करने की आवश्यकता है) आप ट्रैक पर वापस आ सकते हैं:

1. आप जिस रीपो को भेजना चाहते हैं उसे फोर्क करें
2. अपने स्थानीय परिवर्तनों को अपने रिमोट पर धकेलें
3. मुद्दा पुल अनुरोध

Answer 8

GitHub पर एक और अजीब सूक्ष्म अंतर यह है कि जब तक आपके परिवर्तनों को मूल रेपो में खींच नहीं लिया जाता तब तक कांटों में परिवर्तन आपकी गतिविधि लॉग में नहीं गिना जाता है। क्या अधिक है, एक कांटा को एक उचित क्लोन में बदलने के लिए, आपको जाहिरा तौर पर जीथब समर्थन से संपर्क करना होगा।

से क्यों मेरी योगदान दिखाई नहीं दे रहे :

एक कांटे में कमिट किया गया था

एक कांटा में किए गए कमिट आपके योगदान की ओर नहीं गिने जाएंगे। उन्हें गिनने के लिए, आपको निम्नलिखित में से एक करना होगा:

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

Answer 9

संक्षेप में, "कांटा" अपने खुद के GitHub खाते पर होस्ट की गई परियोजना की एक प्रति बनाता है।

"क्लोन" स्रोत कोड डाउनलोड करने के लिए आपके कंप्यूटर पर git सॉफ़्टवेयर का उपयोग करता है और यह उस कंप्यूटर पर संपूर्ण संस्करण इतिहास है