व्यक्तिगत (वन-मैन) परियोजनाओं के लिए git। Overkill?


84

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

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

क्या मेरे पास व्यक्तिगत परियोजनाओं पर गिट का उपयोग करने का कोई अच्छा कारण है, या क्या यह सिर्फ ओवरकिल है?


61
नहीं, मैं निजी परियोजनाओं के लिए git और hg का उपयोग करता हूं। स्थानीय पुनरीक्षण नियंत्रण होने से एक देवता है।
-'११ को १

7
Git कई मायनों में सभी परियोजनाओं के लिए बेहतर है, चाहे उनके पास बड़ी संख्या में योगदानकर्ता हों या न हों: git बहुत अधिक कुशलता से कंप्रेस करता है, (svn की तुलना में अधिक कुशलता से!) यदि कोई और योगदान करना चाहता है तो वह एक बाधा है।
Artefact2

4
मैं अपने कोड को गितुब या बिटबकेट में पुश करने के लिए संस्करण नियंत्रण का उपयोग करता हूं, यह मेरे लिए बैकअप के रूप में सर्वर करता है, और शायद किसी दिन मैं वास्तव में कुछ लोगों को लिखूंगा जिसमें रुचि होगी।
महमूद होसाम

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

1
@ आर्टपर्सन हाँ, आप ऐसा कर सकते हैं, लेकिन मुझे वास्तव में अधिक पसंद है, भले ही मुझे बिटबकैट से अधिक गिथब पसंद है।
महमूद होसाम

जवाबों:


155

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

नया प्रोजेक्ट शुरू करना चाहते हैं?

> git init

BAM! एक रिपॉजिटरी सर्वर स्थापित करने की आवश्यकता नहीं है और न ही तोड़फोड़ रिपॉजिटरी में ब्रांचिंग और टैग का समर्थन करने के लिए एक फ़ोल्डर संरचना में जाँच करें।

बाद में अपनी परियोजना साझा करना केवल एक मामला है: git push(एक दूरस्थ भंडार होने के अलावा)। जल्दी से तोड़फोड़ के साथ करने की कोशिश करो!


24
स्वीकार किए जाते हैं। मैं इस बारे में अधिक गलत होने के बारे में अधिक गलत साबित नहीं किया जा सकता था;)
Anto

7
स्टीव 341: मैं आमतौर पर "प्रोजेक्ट्स" नामक फ़ोल्डर में सभी स्रोत कोड प्रोजेक्ट रखता हूं। यही कारण है कि मैं सभी रिपॉजिटरी रखता हूं, प्रत्येक स्रोत कोड परियोजना के लिए एक। मुझे एक और एक समान वीसीएस रिपॉजिटरी में एक साथ कई परियोजनाओं का ट्रैक रखने की आवश्यकता नहीं थी; यही निर्भरता प्रबंधन प्रणाली जैसे कि आइवी या मावेन के लिए है।
Spoike

3
@ स्टीव 341 इस सामान पर नज़र रखना कितना मुश्किल है? आपके पास बस एक फ़ोल्डर है जिसमें आपके सभी प्रतिनिधि हैं। यह आपके सिस्टम से अलग नहीं है, इस तथ्य से अलग कि जीआईटी का उपयोग करते समय आपका सिस्टम एक बहुत बुरा अभ्यास है ...
वैकल्पिक

2
@ echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all
स्टीव ३१४

2
git initऔर बाम! ओह हाँ और फिर cp ../the-other-project/.gitignore .शुरुआती कमिट से पहले। बैम!
डैन रोसेनस्टार्क

46

मैं तर्क दूंगा कि स्थानीय व्यक्तिगत परियोजनाओं के लिए सबवर्सन का उपयोग ओवरकिल है, जबकि गिट निश्चित रूप से नहीं है। गिट कम जगह लेगा (एसवीएन के अकुशल "संशोधन" अवधारणा बनाम गिट की वस्तु स्नैपशॉट के कारण), कम सेटअप ( git initबनाम एक दर्जन svnadminकमांड और अनुमतियों की स्थापना और इतने पर) की आवश्यकता होती है, बैक अप करना आसान है ( git clone --bare[ git push originयदि आप गीथब का उपयोग करते हैं) या समान] और आपका काम हो गया है), और आपके कोड को प्रबंधित करने के लिए बेहतर उपकरण हैं (ब्रांचिंग मुफ्त है, और विलय आसान और क्लीनर है)। सिर्फ इसलिए कि किसी और के पास आपकी रिपॉजिटरी का क्लोन नहीं है, इसका मतलब यह नहीं है कि किसी भी डीवीसीएस का लाभ "ओवरकिल" है।

इसके अलावा, मैं कहूंगा कि Git की ब्रांचिंग का समर्थन SVN की तुलना में कम जटिल है, जिसमें अधिक पुरस्कार हैं।


मुझे लगता है कि मुझे "कॉम्प्लेक्स" के बजाय "शक्तिशाली" का उपयोग करना चाहिए था
Anto

3
@ एंटो: कोई बात नहीं। मैं अभी भी मूल रूप से एक ही बात कहूंगा: एसवीएन की तुलना में, गिट की बेहतर ब्रांचिंग में कोई गिरावट नहीं है।
ग्रेफेड

3
न ही आपके उप ट्री को हर उपनिर्देशिका में ट्रैकिंग के साथ आपके स्रोत पेड़ को "प्रदूषित" करेगा।
वॉरेन टीटी

4
स्रोत पेड़ "प्रदूषण" svarrenT svn संस्करणों 1.7 और बाद में नहीं होता है।
pllee

4
तोड़फोड़ में एक फाइलसिस्टम रिपॉजिटरी बनाना एक कमांड है ( svnadmin createप्रारंभिक चेकआउट या आयात करने के लिए एक प्लस), अनुमतियों को सेट करने की आवश्यकता नहीं है और इसी तरह। मैं इस बात से इनकार नहीं करता कि Git का एक बेहतर उपकरण है, लेकिन तोड़फोड़ के बारे में गलतियाँ मददगार नहीं हैं।
जोश केली

34

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

यह एक लंबे समय से तोड़फोड़ उपयोगकर्ता से आ रहा है। एक उपकरण पर समेकन वास्तव में आपके जीवन को आसान बनाने में मदद कर सकता है।


2
हाँ मेरा मानना ​​है कि यह शाखाओं, प्रयोग का बिंदु है। Op का प्रश्न पढ़ते समय यह मेरा पहला आरक्षण था। यदि आप अपने रिपॉजिटरी में शाखा नहीं कर रहे हैं तो आप अपने सिर में "ब्रांचिंग" कर रहे हैं और जब आप जगह पर संस्करण नियंत्रण रखते हैं तो यह केवल संवेदनहीन होता है।
क्रिस

3
आप तोड़फोड़ के साथ शाखा कर सकते हैं। और मर्ज हो जाता है। की तरह। वास्तव में, जब मैंने कोशिश की तो मैंने एक भ्रष्ट भंडार के साथ काम किया जिसे मैं किसी भी अधिक काम नहीं कर सकता था, और एक बैकअप से उबरने (शाखा के साथ पहले से लागू) से मदद नहीं मिली, इसलिए मैंने अपना सारा इतिहास खो दिया। एक नया भंडार शुरू करना ... लेकिन मैंने 1.4 से संक्रमण पर दोष दिया? 1.5 करने के लिए (मुझे लगता है - यह अब से कुछ साल पहले था)। संभवतः शाखामिलन और विलय कार्य, वास्तव में। यदि आप इसे आज़माने के लिए पर्याप्त बहादुर हैं। अगर मुझे svn डंप वापस के बारे में पता है, तो मैं निश्चित रूप से कुछ प्रयास के साथ समस्या को ठीक कर सकता था।
स्टीव ३४

@ क्रिस, मुझे एक काम करने वाला संस्करण पसंद है जिसे मैं किसी भी समय वापस कर सकता हूं। सुनिश्चित करें कि आप टैग के साथ इसे पूरा कर सकते हैं, लेकिन ऐसे समय होते हैं जब एक शाखा सही अर्थ बनाती है। Git / mercurial के अन्य लाभों को भी न भूलें।
बेरिन लोरिट्श

9

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


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

1
ओवरकिल का उपयोग तब भी किया जाता है जब समाधान को लागू करने के लिए उपयोग किया जाने वाला प्रयास अनुपात से बाहर हो। यकीनन, यदि आप पहले से ही स्थानीय परियोजनाओं के लिए तोड़फोड़ का उपयोग कर रहे हैं, तो प्रयास सीखने की जरूरत है या जो कुछ भी अधिक है। या संभवतः हस्तांतरणीय कौशल विकसित करने वाला एक उपयोगी पाठ, निश्चित रूप से। व्यक्तिगत रूप से, मैं अभी भी तोड़फोड़ का उपयोग करता हूं - यह मुझे कुछ बार थोड़ा सा है, लेकिन केवल मामूली निशान छोड़ दिया है। मुझे Git सीखने में दिलचस्पी है, लेकिन हर बार जब मैं देख रहा था, तो मुझे जो ट्यूटोरियल मिल रहे थे वे गूढ़ थे या मुझे विंडोज के लिए स्थिर टूल नहीं मिल रहे थे या कुछ अन्य अवरोधक थे जिससे यह सब अच्छा लगता था, ठीक है, ओवरकिल।
स्टीव ३४

7

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


7

मैंने डीवीसीएस से पहले कभी भी निजी परियोजनाओं पर स्रोत नियंत्रण का उपयोग नहीं किया, इसलिए किसी को विपरीत दृश्य लेने की कल्पना करना थोड़ा अजीब है। मेरे कुछ कारण हैं:

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

6

मुझे बताया गया है कि git-bisectआपके इनपुट के आधार पर कमिट्स में आगे और पीछे नेविगेट करके, एक सटीक व्यवहार खोजने के लिए वास्तव में अच्छा है।

आपको यह करना होगा कि किसी दिन उन चीजों के लिए जिन्हें आप समझ नहीं सकते कि क्या हुआ है।


EDIT: इसके अलावा, शाखा की क्षमता बहुत महत्वपूर्ण है जब आपको पुराने संस्करणों में बगफिक्स करना होता है जो ग्राहक उपयोग करते हैं। आपको "बस इस छोटी सी बात को ठीक करने में सक्षम होना चाहिए, लेकिन मुझे नवीनतम संस्करण नहीं चाहिए क्योंकि मैं इसे फिर से परीक्षण नहीं करना चाहता"।


2

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

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


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

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

Git बाइनरी फ़ाइलों के साथ ठीक काम करता है, diffs सिर्फ कम दिलचस्प हैं। सौभाग्य से गिट में भिन्नता बिल्कुल लॉक-डाउन नहीं है - यदि आप एक बाइनरी डिफ टूल से प्यार करते हैं, तो आप इसे बहुत आसानी से (कमांड लाइन से)
क्रिस मोसचीनी

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

यह केवल बेकार है अगर आप द्विआधारी फ़ाइलों को संस्करण करने के लिए मतलब नहीं था। यदि आपको उन्हें संस्करणित करने की आवश्यकता है, तो संस्करण इतिहास बेकार नहीं है। मुझे लगता है कि वे गलती से git को लागू कर रहे हैं जब इसके संस्करण इतिहास को बायनेरिज़ पर नज़र रखते हुए - यह गलत है। git.wiki.kernel.org/index.php/GitSvnComparsion
क्रिस मोशिनिनि

2

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

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

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


1

केवल इसलिए कि किसी ने इसका उल्लेख नहीं किया है: व्यक्तिगत परियोजनाओं के लिए, डार्क्स वास्तव में अच्छा है, और सीधा संस्करण नियंत्रण करने के लिए गिट से कम शामिल है। यह बड़ी परियोजनाओं के लिए उतनी तेजी से नहीं है, लेकिन तब, न तो तोड़फोड़ है!


1
यह इस बात से संबंधित है कि आप कितनी अच्छी तरह से डार्क्स को जानते हैं। मैंने कभी इसका इस्तेमाल नहीं किया है, लेकिन बहुत इस्तेमाल किया है। मुझे करने के लिए git बहुत आगे है, लेकिन मुझे यकीन है कि अगर मैं darcs का उपयोग करना था तो मैं अपना सिर खरोंच कर दूंगा।
सैम

1
यदि आप पहले से ही git के पागल ui में महारत हासिल कर चुके हैं, तो डार्के एक cakewalk होगा।
wlangstroth

1
क्या आप कृपया बता सकते हैं कि छोटी परियोजनाओं के लिए दरख्वास्त बेहतर क्यों है?
shabunc

0

यह समझने के लिए एक शक्तिशाली मानसिक प्रतिमान बदलाव हो सकता है कि हम क्या करते हैं। इसका समर्थन करने के लिए एक सस्ता / आसान उपकरण होने से, आगे बढ़ने की आपकी क्षमता बढ़ जाती है, भाग में क्योंकि यह किसी भी प्रयोग से बाहर निकलने की आपकी क्षमता को बढ़ाता है जब यह खराब हो जाता है।

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

यह सब तब और अधिक मूल्यवान हो जाता है जब प्रयोग कई फाइलों में समन्वित परिवर्तनों को लागू करता है। और जब यह एक एकल pfoject है, तो Git का उपयोग करना और भी सरल हो जाता है।

यह सोचने के बजाय कि क्या मुझे इसे एक एकल परियोजना पर उपयोग करना चाहिए, मुझे अब लगता है कि इस शर्म की बात क्या है कि मुझे यह जल्दी पता नहीं चला।


इस पर डिजाइनर के विचारों के लिए, YouTube पर लाइनस को YouTube पर देखें (~ 70 मिनट)
वॉरेनटी सेप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.