हर कोई केंद्रीकृत तरीके से Git का उपयोग क्यों करता है?

Question

मैंने अपने पिछले दो कंपनियों में संस्करण नियंत्रण के लिए Git का उपयोग किया है। ऐसा लगता है कि मैंने सुना है कि लगभग 90% कंपनियां अन्य संस्करण नियंत्रण प्रणालियों पर Git का उपयोग करती हैं।

Git का सबसे बड़ा विक्रय बिंदु यह है कि यह विकेंद्रीकृत है, अर्थात सभी रिपॉजिटरी समान हैं; सत्य का कोई केंद्रीय भंडार / स्रोत नहीं है। यह एक फीचर था लिनुस टॉर्वाल्ड्स चैंपियन।

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

मेरे प्रश्न हैं:

1. लोग व्यवहार में Git के लिए वितरित वर्कफ़्लो का उपयोग क्यों नहीं करते हैं?
2. क्या आधुनिक संस्करण नियंत्रण के लिए भी वितरित तरीके से काम करने की क्षमता महत्वपूर्ण है, या क्या यह सिर्फ अच्छा लगता है?

संपादित करें

मैंने महसूस किया कि मुझे अपने मूल प्रश्न में सही स्वर नहीं मिला। ऐसा लग रहा था जैसे मैं पूछ रहा था कि जब कोई वितरित संस्करण नियंत्रण प्रणाली (डीवीसीएस) इतना स्पष्ट रूप से बेहतर था तो कोई भी केंद्रीकृत तरीके से काम क्यों करेगा । वास्तविकता में, मेरे कहने का मतलब यह था कि मुझे डीवीसीएस से कोई लाभ नहीं है । फिर भी मैं अक्सर लोगों को अपनी श्रेष्ठता का प्रचार करते सुनता हूं, जबकि वास्तविक दुनिया मेरे विचार से सहमत है।

Comments

मैं ठीक उसी तरह महसूस करता हूं, और यह नहीं समझता।

— स्नूप

निजी तौर पर, मैं सिर्फ कई रिमोट के लिए किसी भी उपयोग के मामलों के बारे में नहीं जानता, मुख्य रिमोट के लिए पीआर बनाने के लिए कांटे के अलावा अन्य। वितरित चीज़ अभी भी उपयोगी है क्योंकि इसका मतलब है कि मुझे अपनी मशीन पर नेटवर्क से बात किए बिना एक पूरा इतिहास मिलता है, और अगर मैं वास्तव में चाहता हूं, तो मैं कुछ काम ऑफ़लाइन कर सकता हूं, और एक ऑनलाइन रेपो होस्ट से माइग्रेट करना बहुत आसान है एक और। जब आप "वितरित वर्कफ़्लो" का संदर्भ लेते हैं तो वास्तव में आपके मन में क्या होता है?

— 15 अगस्त को Ixrec

मैं काफी निश्चित Torvalds शुरू से ही एक "सत्य का स्रोत" लिनक्स कर्नेल भंडार है।

— स्टीवन बर्नैप 16

अंत में, सॉफ्टवेयर में ही है केंद्रीकृत। ग्राहक शाखाएं या उपाय नहीं खरीदते हैं, वे एक अंतिम, पुट-एक, निर्मित उत्पाद खरीदते हैं। हमेशा कुछ केंद्रीय मार्ग आगे बढ़ाने की जरूरत है।

— ब्रैंडन

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

— Jay

Answer 1

आह, लेकिन वास्तव में आप विकेंद्रीकृत तरीके से गिट का उपयोग कर रहे हैं !

आइए हम मानस, svn में git के पूर्ववर्ती की तुलना करें। तोड़फोड़ का केवल एक "रेपो" था, सच्चाई का एक स्रोत। जब आपने एक कमिट किया था, तो यह एक सिंगल, सेंट्रल रेपो था, जिसमें हर दूसरे डिवेलपर के रूप में भी काम कर रहा था।

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

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

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

तथ्य यह है कि, बजाय अन्य डेवलपर्स के लिए सीधे धक्का के बजाय , आप एक अन्य दूरस्थ रेपो के माध्यम से उन्हें अप्रत्यक्ष रूप से परिवर्तन धक्का, ज्यादा मायने नहीं रखता है। हमारे दृष्टिकोण से महत्वपूर्ण हिस्सा यह है कि रेपो की आपकी स्थानीय प्रति अपने आप में रेपो है। Svn में, सिस्टम के डिजाइन द्वारा सत्य का केंद्रीय स्रोत लागू किया जाता है। Git में, सिस्टम के पास यह अवधारणा भी नहीं है; यदि सत्य का कोई स्रोत है, तो यह बाहरी रूप से तय किया जाता है।

Comments

SVN मर्ज केवल विरोधाभासी परिवर्तनों से जुड़े डेवलपर्स को प्रभावित करता है। एक प्रतिबद्ध इसे रेपो में बनाता है, कोई भी परस्पर विरोधी विलय रेपो में नहीं जा सकता है जब तक कि टकरावों का समाधान नहीं हो जाता है (आप एक अलग शाखा / पथ के समानांतर भी कर सकते हैं, लेकिन यह वास्तव में संघर्ष नहीं करता है?)

— बेन Voigt

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

— बेन वोइग्ट

@BenVoigt ओह, यह सब सही रोक काम है। याद रखें svn upकि आपको चेक-इन करने से पहले रेपो के साथ डेट करना होगा। जब आप मर्ज टकराव को हल करने का प्रयास कर रहे हैं, तो दूसरे भी चेक करते रहेंगे, और आपको मर्ज टकराव का एक और सेट देंगे ... आप या तो उस पर रोक लगा दें। या आप खो देते हैं जो आपके विवेक से बचा हुआ है।

— माइकल हैम्पटन

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

— बेन वोइग्ट

बेन का अधिकार। एक एसवीएन रेपो ठीक से प्रबंधित होता है , और एक टीम द्वारा उपयोग किया जाता है जो सॉफ्टवेयर को विकसित करने के तरीके में ठीक से शिक्षित किया गया है, ट्रंक पर प्रभावी रूप से विलय संघर्ष नहीं होना चाहिए। आप केवल उन्हें प्राप्त करेंगे जब किसी ने कुछ गलत किया हो और उसे निकाल दिया जाए (: P)। inb4 यह आसान है जब आपको लोगों को अपने उपकरणों का उपयोग करने के लिए शिक्षित करने की आवश्यकता नहीं है। हाँ, ठीक है, एसवीएन के बारे में जीआईटी के बारे में सिखाने के लिए बहुत कुछ है!

— १०:१४ पर कक्षा

Answer 2

जब आपका बिल्ड सर्वर (आप CI का उपयोग कर रहे हैं , तो सही?) एक बिल्ड बनाता है, यह कहां से खींचता है? यकीन है, एक एकीकरण निर्माण आप तर्क कर सकते हैं कि "एक सच्चे रेपो" की आवश्यकता नहीं है, लेकिन निश्चित रूप से एक वितरण निर्माण (यानी आप ग्राहक को क्या देते हैं)।

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

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

पारंपरिक CVCS के साथ या तो आप प्रतिबद्ध हैं या आप नहीं हैं। यह कुछ वर्कफ़्लोज़ के लिए ठीक है (मैं विभिन्न परियोजनाओं के लिए दोनों वीसीएस प्रकारों का उपयोग करता हूं), लेकिन किसी सार्वजनिक या आरएसएस परियोजना के लिए इसके चेहरे पर सपाट पड़ता है। कुंजी डीवीसीएस के कई चरण हैं, जो अधिक काम करते हैं, लेकिन एक अंतर्निहित प्रक्रिया के माध्यम से अजनबियों से कोड को एकीकृत करने के लिए एक बेहतर तरीका प्रदान करते हैं जो कि जाँच की जा रही में बेहतर दृश्यता की अनुमति देता है। इसे केंद्रीकृत तरीके से उपयोग करने का मतलब है कि आप अभी भी कर सकते हैं। परियोजना की वर्तमान स्थिति का वह स्वर्ण मानक है, जबकि एक बेहतर कोड साझाकरण तंत्र भी प्रदान करता है।

Comments

कुल मिलाकर अच्छा जवाब, लेकिन मुझे पूरा यकीन है कि निरंतर एकीकरण से पहले Git व्यापक उपयोग में था; हमारी टीम सीआई का उपयोग करती है, वैसे, जाँच के लिए धन्यवाद: डी।

— गार्डेनहेड

@gardenhead: आप इस बिंदु से चूक गए: यदि तर्क एकीकरण का निर्माण करता है तो वही तर्क रखता है। "CI" एक प्रक्रिया के लिए सिर्फ एक स्वचालितकरण है जो कि पुराने से बहुत पुराना है।

— डॉक ब्राउन

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

— स्टीव जेसप

क्योंकि लिनक्स कर्नेल का कोई "एक सच्चा निर्माण" नहीं है। चूंकि हर कोई इसे खुद बनाता है, लिनुस का रेपो किसी और की तुलना में अधिक विहित नहीं है। यदि आप एक ऐसा उत्पाद बेच रहे हैं जो इतनी अच्छी तरह से काम नहीं करता है।

— माइल्स बुडनेक

@ सुपरब्रिज: बिट डिज़ाइनर के आस-पास गिट के डिज़ाइन का बहुत (यदि सभी नहीं) है। लिनट-बिटकॉइर विवाद के बाद गिट का निर्माण हुआ।

— whatsisname

Answer 3

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

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

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

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

डीवीसीएस सिस्टम को भी मजबूर किया जाता है , क्योंकि वे विकेंद्रीकृत होते हैं, इस तथ्य के आधार पर कुछ सुविधाजनक सुविधाएँ प्रदान करने के लिए कि आपको कुछ भी करने के लिए आवश्यक रूप से एक पूरा इतिहास (यानी रेपो) होना चाहिए। लेकिन अगर आपको लगता है कि इसके बारे में कोई मौलिक कारण नहीं है कि आप एक स्थानीय कैश के साथ एक केंद्रीकृत वीसीएस को कॉन्फ़िगर क्यों नहीं कर सकते हैं, जो पूरे इतिहास को केवल पढ़ने के लिए संचालन से बाहर रखने की अनुमति देता है (मुझे लगता है कि पीएफआरएस में इस मोड के लिए एक विकल्प है, लेकिन मैंने कभी भी पेरिफेरल का इस्तेमाल नहीं किया)। या सिद्धांत रूप में आप gitअपने साथ कॉन्फ़िगर कर सकते हैं.git/एसवीएन की "सुविधा" का अनुकरण करने के लिए एक रिमोट-माउंटेड फाइलसिस्टम पर निर्देशिका जो आपके पास नेटवर्क कनेक्शन नहीं होने पर काम नहीं करती है। वास्तव में, DVCS प्लंबिंग को अधिक मजबूत बनाता है क्योंकि आप केंद्रीकृत वीसीएस के साथ दूर जा सकते हैं। यह एक (बहुत स्वागत योग्य) साइड इफेक्ट है और DVCS डिजाइन को प्रेरित करने में मदद करता है, लेकिन तकनीकी स्तर पर जिम्मेदारी का वितरण सभी मानव जिम्मेदारी को पूरी तरह से विकेंद्रीकृत करने के समान नहीं है ।

Comments

वे तकनीकी रूप से समकक्ष हैं, सामाजिक रूप से समकक्ष नहीं हैं ।

— जिज्ञासु ०१

पैचिंग ईमेल करना काफी दर्द रहित होता है, बस अगर कोई इस पर विचार कर रहा है, तो बस git फॉर्मेट-पैच और फिर git सेंड-ईमेल का उपयोग करें । क्या तब हुआ जब मैं गितुब के अभिगम नियंत्रण के साथ इधर-उधर नहीं होना चाहता था और यह बहुत सीधा था, सभी के पास ईमेल है।

— रुडोल्फ ओलह

"आवश्यक रूप से पूरा इतिहास होना चाहिए [...] स्थानीय रूप से कुछ भी करने के लिए" - सच नहीं; आधुनिक DSCM आंशिक रिपोज (bzr शब्दों में "उथले चेकआउट", "उथले क्लोन" को गज़ शब्दों में) का समर्थन करते हैं।

— चार्ल्स डफी

Answer 4

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

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

• कोर डेवलपर्स की एक बहुत छोटी सूची है, जो प्रत्येक माइक्रोसेवा के लिए "केंद्रीय" रेपो तक पहुंच के साथ है। बाकी सभी लोग कांटे से बाहर काम कर सकते हैं और पुल अनुरोधों के माध्यम से जमा कर सकते हैं।
• बहुत अधिक बार कर सकते हैं , आमतौर पर प्रति घंटे एक बार या प्रति दिन दो बार।
• सहकर्मियों के साथ अस्थायी रूप से समन्वय करने के लिए किसी भी कारण से शाखाएं बना सकते हैं, और इसे धक्का दे सकते हैं और इसे प्रति दिन कई बार खींच सकते हैं, फिर इसे बड़े समूह के साथ साझा करने के लिए तैयार होने पर स्क्वैश कर सकते हैं। क्या आपके पास कोई विचार है कि पारंपरिक सीवीसीएस में इस तरह की चीज़ के लिए एक अस्थायी शाखा बनाने की अनुमति प्राप्त करना कितना कठिन है?

यह कहने के लिए पुराने लगने के जोखिम पर, आपको वास्तव में यह पता नहीं है कि आपके पास यह कितना आसान है।

Comments

यह सवाल कि पारंपरिक CVCS में एक शाखा बनाना कितना कठिन है, यह पूरी तरह से नीति के लिए है: मैं एक अपस्ट्रीम SVN रेपो (स्वाभाविक रूप से git-svn क्लोन के माध्यम से) के साथ काम करने के लिए होता हूं! और मुझे कोई भी निर्माण करने का पूरा अधिकार है चाहते हैं, भले ही यह काफी बड़ी परियोजना है। मुझे केवल अपने वरिष्ठ अधिकारियों से बात किए बिना, कई नामित एकीकरण शाखाओं को छूने की अनुमति नहीं है, अकेले ट्रंक को छोड़ दें। अन्य कंपनियों में अन्य नीतियां हो सकती हैं जो अधिक प्रतिबंधक हो सकती हैं, लेकिन वे निश्चित रूप से नहीं होनी चाहिए।

— 7

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

— गार्डेनहैड

@gardenhead आप हमेशा अपना स्वयं का SVN रेपो बना सकते हैं और इसे तोड़ने का प्रयास कर सकते हैं;) (और ध्यान दें कि यह git रेपो बनाने और इसे क्लोन करने की तुलना में कितना कठिन है ...) - एक अन्य प्रमुख विशेषता जिसे मैंने देखा है (कम से कम विशेष रूप से कॉर्पोरेट वातावरण) यह है कि फ़ाइल साझाकरण या तो थोड़ा अजीब है, या यह इस तरह से किया जाता है कि रिपॉजिटरी को horks करता है (क्योंकि वायरस स्कैनर नेटवर्क ड्राइव पर लॉक होता है, उदाहरण के लिए)।

— वेन वर्नर

@gardenhead: ठीक है, अपने आप को भाग्यशाली समझें कि आप एक विरासत परियोजना में नहीं फंसे हैं, पुराने सॉफ्टवेयर डेवलपर्स के साथ जो आपको बता रहे हैं कि काम करने का पुराना तरीका ठीक है ... कभी-कभी आप मदद नहीं कर सकते हैं लेकिन महसूस करते हैं कि वे सिर्फ हैं खुशी है कि उन्हें कोई नई तकनीक सीखने की जरूरत नहीं है!

— लेफ्टरेंबाउट

@gardenhead जाहिरा तौर पर परियोजनाओं को एक सुंदर पागल दर पर जारी किया जा रहा है। यदि आप एक भयानक नौकरी खोजने में सक्षम होना चाहते हैं तो सीखने को जारी रखने की क्षमता आवश्यक है।

— वेन वर्नर

Answer 5

मुझे लगता है कि आप सवाल कर रहे हैं एक (समझने योग्य) हमेशा जुड़े मानसिकता से आता है । यानी केंद्रीय 'सत्य' ci सर्वर हमेशा (या हमेशा पास) उपलब्ध होता है। जबकि यह अधिकांश वातावरणों में सच है, मैंने कम से कम एक में काम किया है जो इससे दूर था।

एक सैन्य सिमुलेशन परियोजना मेरी टीम ने कई साल पहले काम किया था। सभी कोड (हम एक बात कर रहे हैं> अमेरिका $ 1b codebase) किया था (कानून / अंतरराष्ट्रीय समझौते से, काले सूट में पुरुषों आ अगर तुम नहीं करते हैं) मशीनों पर हो शारीरिक रूप से से अलग किसी भी इंटरनेट कनेक्शन । इसका मतलब था कि हम में से प्रत्येक की स्थिति 2 पीसी की थी, एक कोड लिखने / चलाने / परीक्षण करने के लिए, दूसरा Google चीजों के लिए, ई-मेल की जाँच करने के लिए और ऐसे। और इन मशीनों की टीम के भीतर एक स्थानीय नेटवर्क था , जाहिर है कि किसी भी तरह से इंटरनेट से जुड़ा नहीं था।

"सत्य का केंद्रीय स्रोत" एक आर्मी बेस पर एक मशीन थी, जो एक सब-सिंड्रेक्टर भूमिगत खिड़की रहित कमरे (प्रबलित भवन, यदा-यदा) में थी। उस मशीन का कोई इंटरनेट कनेक्शन भी नहीं था।

समय-समय पर, सेना के अड्डे पर git repo (हमारे सभी कोड परिवर्तन वाले) के साथ एक ड्राइव (शारीरिक रूप से) परिवहन करना किसी का काम होगा - जो कई सौ किलोमीटर दूर था, इसलिए, आप कल्पना कर सकते हैं।

---

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

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

Git की डिस्कनेक्ट की गई प्रकृति का अर्थ है कि इसका उपयोग उन वातावरणों में किया जा सकता है जहां कनेक्टेड मॉडल सोर्स-कंट्रोल टूल्स ( यानी SVN, एक के लिए) का उपयोग नहीं किया जा सकता है - या आसानी से उपयोग नहीं किया जा सकता है।

Comments

मैं माइल हाई (सॉफ्टवेयर) क्लब का सदस्य हूं - मैंने 35,000 फीट पर कोड लगाया है। ज़रूर, विमानों में अब Wifi है , लेकिन हमेशा ऐसा नहीं था। और यह जानकर अच्छा लगा कि कम से कम अगर हम दुर्घटना करते हैं तो संभावना है कि मेरी टीम को मेरा कोड बरकरार रहेगा।

— वेन वर्नर

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

— Tersosauros

Answer 6

अंततः, आप एक उत्पाद का निर्माण कर रहे हैं। यह उत्पाद एक समय में आपके कोड का प्रतिनिधित्व करता है। यह देखते हुए कि आपके कोड को कहीं न कहीं समेटना चाहिए । प्राकृतिक बिंदु एक ci सर्वर या केंद्रीय सर्वर है जिसमें से उत्पाद बनाया जाता है, और यह समझ में आता है कि यह केंद्रीय बिंदु एक गिट रिपॉजिटरी है।

Answer 7

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

किसी विशिष्ट आधिकारिक रिलीज़ के साथ एक ठोस उत्पाद बनाते समय यह एक बहुत ही सामान्य उपयोग का मामला नहीं है, लेकिन F / OSS दुनिया में यह आदर्श है, अपवाद नहीं।

Comments

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

— साल्स्के

@ Luaan कुछ समय के लिए इस बारे में सोचने के बाद, मुझे एहसास हुआ कि आप सही हैं। मैंने शब्द को थोड़ा बदल दिया है - क्या इससे भेद थोड़ा बेहतर होता है?

— शराबी

@ फुलफी मुझे अच्छी लगती है;)

— लुआण

Answer 8

हर कोई केंद्रीकृत तरीके से गिट का उपयोग क्यों करता है?

हम कभी नहीं मिले हैं, कैसे आता है कि आप सभी को कहते हैं? ;)

दूसरी बात, ऐसी और भी विशेषताएं हैं जो आपको Git में मिलती हैं लेकिन CVS या SVN में नहीं। शायद यह सिर्फ आप मान रहे हैं कि यह सभी के लिए एकमात्र विशेषता होनी चाहिए ।

यकीन है कि बहुत से लोग इसका उपयोग सीवीएस या एसवीएन की तरह केंद्रीकृत कर सकते हैं। लेकिन अन्य विशेषता को न भूलें जो स्वाभाविक रूप से एक ditributed VCS के साथ आती है: सभी प्रतियां अधिक या कम "पूर्ण" (सभी शाखाएं और पूरा इतिहास उपलब्ध है) और सभी शाखाओं को एक सर्वर से कनेक्ट किए बिना चेक आउट किया जा सकता है।

मेरी राय यह एक और विशेषता है जिसे नहीं भूलना चाहिए।

हालांकि आप आउट ऑफ बॉक्स CVS और SVN के साथ ऐसा करने में सक्षम नहीं हैं, लेकिन Git को बिना किसी समस्या के पूर्व की तरह केंद्रीकृत किया जा सकता है।

इसलिए मैं अपने बदलाव करने में सक्षम हूं, हो सकता है कि स्क्वैश वर्क-इन-प्रोग्रेस एक साथ शुरू हो, फिर मुख्य विकास शाखा में मेरे काम को लाने और रिबास करें।

अन्य सुविधाएँ जो Git के साथ बॉक्स से बाहर आती हैं:

• क्रिप्टोग्राफिक रूप से हस्ताक्षर करता है
• रिबासिंग (पुनरावृत्ति और स्क्वैश शुरू होता है; केवल संदेश ही नहीं, संपादित करें)
• चेरी उठा रहा हैं
• इतिहास की व्याख्या
• स्थानीय शाखाएँ और परिवर्तन (जिसे "विकिपीडिया में आश्रय" कहा जाता है)

विकिपीडिया में इन तीन तालिकाओं को भी देखें - संस्करण नियंत्रण सॉफ्टवेयर की तुलना :

• विशेषताएं

• मूल आज्ञा

• उन्नत आदेश

तो फिर, हो सकता है कि विकेंद्रीकृत तरीके से केवल वही सुविधा न हो जो लोगों को इसका उपयोग करने के लिए तैयार करती है।

1. लोग व्यवहार में Git के लिए वितरित वर्कफ़्लो का उपयोग क्यों नहीं करते हैं?

Bitbucked, GitHub आदि पर किसी बड़े प्रोजेक्ट को योगदान देने या होस्ट करने वाला कोई भी व्यक्ति विशेष रूप से ऐसा करेगा। अनुरक्षक "मुख्य" भंडार रखते हैं, एक योगदानकर्ता क्लोन करता है, कमिट करता है और फिर एक पुल अनुरोध भेजता है।

कंपनियों में, यहां तक ​​कि छोटी परियोजनाओं या टीमों के साथ, एक वितरित वर्कफ़्लो एक विकल्प होता है जब वे या तो मॉड्यूल को आउटसोर्स करते हैं और बाहरी नहीं चाहते हैं कि उनके परिवर्तनों की समीक्षा किए बिना पवित्र विकास शाखा (एस) को संशोधित किया जाए।

2. क्या क्षमता वितरित रूप में आधुनिक संस्करण नियंत्रण के लिए भी महत्वपूर्ण है, ...

हमेशा की तरह: यह आवश्यकताओं पर निर्भर करता है।

यदि कोई बिंदु लागू होता है तो विकेंद्रीकृत VCS का उपयोग करें:

• इतिहास को ऑफ़लाइन करना या नेविगेट करना चाहते हैं (जैसे छुट्टी के दौरान पहाड़ के केबिन में सबमॉड्यूल को पूरा करना)
• केंद्रीय भंडार प्रदान करें, लेकिन बदलावों की समीक्षा के लिए "सही" भंडार रखना चाहते हैं (यानी बड़ी परियोजनाओं या वितरित टीमों के लिए)
• केंद्रीय रेपो (दूसरी बार के समान) तक सीधी पहुंच को रोकने के दौरान कभी-कभार पूरे इतिहास और शाखाओं की एक प्रति प्रदान करना चाहते हैं।
• दूरस्थ रूप से या एक समर्पित भंडार स्थापित करने के लिए कुछ करने के बिना कुछ संस्करण बनाना चाहते हैं (विशेष रूप से जीट के साथ केवल git init .कुछ संस्करण के लिए तैयार होने के लिए पर्याप्त होना चाहिए)

कुछ और भी हैं लेकिन चार पर्याप्त होने चाहिए।

... या यह सिर्फ अच्छा लगता है?

बेशक यह अच्छा लगता है - शुरुआती लोगों के लिए।

Comments

svn initकुछ बिंदु पर SVN हासिल नहीं किया ?

— इमिविस

Answer 9

लचीलापन एक अभिशाप होने के साथ-साथ एक आशीर्वाद भी है। और जैसा कि Git अत्यंत लचीला है, यह लगभग हमेशा दूर भी ठेठ स्थिति के लिए लचीला। विशेष रूप से, अधिकांश Git प्रोजेक्ट लिनक्स नहीं हैं।

परिणामस्वरूप, स्मार्ट विकल्प Git को लागू करते समय उस सैद्धांतिक लचीलेपन में से कुछ को दूर करना है। सिद्धांत रूप में रिपॉजिटरी किसी भी ग्राफ को बना सकते हैं, व्यवहार में सामान्य पसंद एक पेड़ है। हम ग्राफ सिद्धांत का उपयोग करके स्पष्ट लाभ देख सकते हैं: रिपॉजिटरी के एक पेड़ में, कोई भी दो रिपॉजिटरी बिल्कुल एक पूर्वज साझा करते हैं। एक यादृच्छिक ग्राफ में, पूर्वज का विचार भी मौजूद नहीं है!

आपका git क्लाइंट हालांकि लगभग निश्चित रूप से "सिंगल आंसर" मॉडल को डिफॉल्ट करता है। और ग्राफ जिसमें नोड्स में एक एकल पूर्वज (रूट नोड को छोड़कर) बिल्कुल पेड़ हैं। तो आपका गिट क्लाइंट खुद ट्री मॉडल को डिफॉल्ट करता है, और इसलिए केंद्रीकृत रिपोजिटरी।

Comments

मैं मानता हूं कि अधिकांश उपयोग के मामलों के लिए गिट के लचीलेपन को कम करने की आवश्यकता है। मेरी पिछली नौकरी में, हमारे पास गिट का उपयोग करने के तरीके के बारे में दिशानिर्देश नहीं थे, और इसके कारण लगातार संघर्ष और टूटना थे। मेरी नई कंपनी में, हम Git Flow मॉडल का उपयोग करते हैं, और यह विकास को बहुत अधिक सुव्यवस्थित और तनाव मुक्त बनाता है।

— गार्डेनहेड

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

— वाइल्डकार्ड

@Wildcard: विलय पेड़ों के साथ कोई समस्या नहीं है, ऐसा क्यों होगा? आप केवल माता-पिता / बच्चे के बीच, यादृच्छिक नोड्स के बीच विलय नहीं कर सकते।

— MSalters

मैं स्पष्ट रूप से पर्याप्त नहीं था। मैं कमिट्स के पेड़ की बात कर रहा था, न कि फाइलसिस्टम के पेड़ की। परिभाषा के अनुसार, एक मर्ज कमिटमेंट में एक से अधिक माता-पिता होते हैं, और आपका इतिहास ग्राफ़ अब एक पेड़ नहीं है, बल्कि एक DAG है।

— वाइल्डकार्ड 19

@Wildcard: MSalters ने कहा कि रिपॉजिटरी आमतौर पर पेड़ों के रूप में जुड़े होते हैं, न कि यह कि कमिट होते हैं। वह कह रहा है कि रेपोस में आमतौर पर केवल एक "अपस्ट्रीम" रिमोट होता है जिसे वे पुश करते हैं (या पुल अनुरोध जारी करते हैं)। मेरे पास कोई आँकड़े नहीं हैं कि यह सच है या नहीं, लेकिन यह कितने माता-पिता के लिए एक मर्ज कमिटमेंट है, इसके बारे में किसी भी चीज़ से पूरी तरह से अलग दावा है।

— स्टीव जेसोप

Answer 10

व्यापार तर्क एक केंद्रीकृत सर्वर को पुरस्कृत करता है। लगभग सभी यथार्थवादी व्यापार परिदृश्यों के लिए, एक केंद्रीकृत सर्वर वर्कफ़्लो की एक मूलभूत विशेषता है।

सिर्फ इसलिए कि आपके पास DVCS करने की क्षमता है, इसका मतलब यह नहीं है कि आपके प्राथमिक कार्य प्रवाह को DVCS होना चाहिए। जब मैं काम पर गिट का उपयोग करता हूं, तो हम इसे केंद्रीकृत तरीके से उपयोग करते हैं, उन अजीब अजीब मामलों को छोड़कर जहां चीजों को साथ रखने के लिए वितरित बिट आवश्यक था।

चीजों का वितरित पक्ष जटिल है। आमतौर पर आप चीजों को सहज और आसान रखना चाहते हैं। हालांकि, git का उपयोग करके आप यह सुनिश्चित करते हैं कि आपके पास सड़क के नीचे उत्पन्न होने वाली ख़तरनाक स्थितियों से निपटने के लिए वितरित पक्ष तक पहुंच है।

Answer 11

एक सहकर्मी के लिए मेरी मशीन पर गिट रेपो से खींचने का मतलब है कि मुझे पृष्ठभूमि कार्य के रूप में रूट स्तर पर एक git डेमॉन की आवश्यकता है। मैं अपने स्वयं के कंप्यूटर, या मेरी कंपनी द्वारा प्रदान किए गए लैपटॉप पर चलने वाले डेमॉन का बहुत ही हिस्सा हूं। सबसे आसान उपाय है "NO"! एक सहकर्मी के लिए मेरी मशीन पर गिट रेपो से खींचने का मतलब यह है कि मेरे इंटरनेट पते को ठीक करने की आवश्यकता है। मैं यात्रा करता हूं, मैं घर से काम करता हूं, और मैं कभी-कभार अपने कार्यालय से काम करता हूं।

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

तीसरे स्थान पर, मेरा स्थानीय गिट रेपो एक पूर्ण विशेषताओं वाला भंडार है। मैं नया काम कर सकता हूं, प्रायोगिक कार्य के लिए एक नई शाखा बना सकता हूं, और काम की वापसी कर सकता हूं जब मैं चीजों की गड़बड़ी करता हूं, तब भी जब मैं कहीं और बीच में 30,000 फीट की ऊंचाई पर उड़ने वाले हवाई जहाज में काम कर रहा हूं। एक केंद्रीकृत संस्करण नियंत्रण प्रणाली के साथ ऐसा करने का प्रयास करें।

Comments

"मैं अपने कंप्यूटर पर, या अपनी कंपनी द्वारा उपलब्ध कराए गए लैपटॉप पर चलने वाले डेमॉन का बहुत बड़ा हिस्सा हूं।" - क्योंकि किसी भी चीज़ से अलग होने पर, मेरे लैपटॉप पर एक सेवा चलाने का मतलब है कि ढक्कन बंद करने पर सेवा अनुपलब्ध है! DynDNS कई स्थानों पर मदद कर सकता है (एक हद तक, आप अभी भी एक NAT के पीछे फंस सकते हैं), लेकिन यह आपके नेटवर्क कार्ड को कम करने में मदद नहीं करता है ...

— स्टीव जेसप

किसी विशेष डेमॉन को चलाने के बिना गिट रेपो बनाने के बहुत सारे तरीके हैं; इसे बहुत अधिक किसी भी फ़ाइल शेयर (smb, sshfs, आदि) के माध्यम से एक्सेस किया जा सकता है, और यहां तक ​​कि इसे सादे ol 'HTTP स्टोर के रूप में भी उपलब्ध कराया जा सकता है।

— शराबी

Answer 12

जटिलता:

केंद्रीय भंडार के साथ, एक विशिष्ट कार्य प्रवाह हो सकता है

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

हे (1) में डेवलपर्स की संख्या के संबंध में जटिलता।

यदि इसके बजाय प्रत्येक डेवलपर की अपनी स्वयं की मास्टर शाखा है, तो डेवलपर 0 के लिए:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

सहकर्मी से सहकर्मी दृष्टिकोण ओ (एन) है।

संगति:

अब विचार करें कि क्या एलिस की मास्टर ब्रांच और बॉब की मास्टर ब्रांच के बीच कोई मर्ज है। एन डेवलपर्स में से प्रत्येक संघर्ष को अलग तरीके से हल कर सकते थे। परिणाम: अराजकता। अंततः स्थिरता प्राप्त करने के तरीके हैं, लेकिन जब तक ऐसा नहीं होता, तब तक डेवलपर समय के सभी प्रकार बर्बाद हो सकते हैं।

Comments

यदि आप वोट कम करने जा रहे हैं, तो क्या आप इस पर टिप्पणी छोड़ सकते हैं?

— थियोडोर नॉरवेल

ऐसा नहीं है कि मैं अपमानित मन हूँ। मैं सिर्फ यह जानना चाहता हूं कि क्या उत्तर किसी तरह गलत है।

— थियोडोर नॉरवेल

Answer 13

सरल:

कंपनियां केंद्रीकृत वर्कफ़्लो के साथ केंद्रीकृत संगठन हैं।

हर प्रोग्रामर का एक बॉस होता है और उसके पास उसका बॉस इत्यादि सीटीओ तक होता है। सीटीओ तकनीकी सत्य का अंतिम स्रोत है। जो भी उपकरण कंपनी उपयोग करती है, उसे कमांड की इस श्रृंखला को प्रतिबिंबित करना चाहिए। एक कंपनी एक सेना की तरह है - आप एक सामान्य को निजीकरण नहीं होने दे सकते।

GIT ऐसी सुविधाएँ प्रदान करता है जो कंपनियों के लिए उपयोगी होती हैं (जैसे कि कोड समीक्षा के लिए अनुरोधों को खींचना) और यह अकेले उन्हें GIT में बदल देती है। विकेन्द्रीकृत भाग बस एक विशेषता है जिसकी उन्हें आवश्यकता नहीं है - इसलिए वे इसे अनदेखा करते हैं।

आपके प्रश्न का उत्तर देने के लिए: वितरित भाग वितरित वातावरण में वास्तव में श्रेष्ठ है, जैसे ओपन-सोर्स। परिणाम किसकी बात पर निर्भर करता है। लिनस टॉर्वाल्ड्स वास्तव में आपका क्यूबिकल चूहा नहीं है, यही कारण है कि जीआईटी की विभिन्न विशेषताएं आपके गिथब-केंद्रित कंपनी की तुलना में उसके लिए महत्वपूर्ण हैं।

Answer 14

शायद यह इसलिए है क्योंकि वह पेरोल प्रसंस्करण केंद्रीकृत है, इसलिए हमें एक केंद्रीय व्यक्ति को खुश रखना होगा यदि हम भुगतान करना चाहते हैं।

शायद यह इसलिए है क्योंकि हम एक उत्पाद बना रहे हैं, इसलिए हमें ग्राहकों के लिए सॉफ़्टवेयर की एक मास्टर कॉपी की आवश्यकता है।

हो सकता है कि ऐसा इसलिए हो क्योंकि एक प्रोग्रामर के लिए एक ही जगह पर जाकर हर किसी के बदलावों को प्राप्त करना बहुत आसान हो जाता है, बजाय इसके कि वह बहुत सारी अलग-अलग मशीनों से जुड़ जाए।

हो सकता है कि यह इसलिए है क्योंकि बग डेटाबेस केंद्रीकृत है, और कोड के साथ सिंक में रखा जाना चाहिए ।

केंद्रीकृत होना महान है, जब तक कि कोई समस्या न हो ...

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

नेटवर्क डाउन होने पर एक रिपॉजिटरी की स्थानीय कॉपी पर मर्ज आदि करने में सक्षम होने के नाते, लेकिन एक वितरित प्रणाली की आवश्यकता नहीं है; इसके लिए बस एक ऐसी प्रणाली की जरूरत होती है जो सभी डेटा की एक स्थानीय प्रति रखती है। इसी तरह उड़ान आदि के साथ कोड में जाँच के साथ।

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