"निर्भर करता है।" सामान्य विकास ट्रैकिंग के लिए, नहीं। हालांकि, क्लाउड और DevOps परिनियोजन के लिए, यह अक्सर सुविधाजनक होता है, या यहां तक कि आवश्यक भी होता है।
ज्यादातर समय,
@ptyx सही है । वास्तव में, उनके "नहीं" को कुछ अधिक सशक्त रूप से कहा जा सकता है। "नहीं नहीं! OMG NO! "
जीआईटी जैसे स्रोत नियंत्रण प्रणाली में खनन या संपीड़ित संपत्तियों को क्यों नहीं स्टोर करें?
वे स्रोत कोड से मक्खी पर आपकी निर्माण प्रक्रिया द्वारा लगभग तुच्छ पुनर्जीवित हो सकते हैं। संपीड़ित संपत्तियों को संग्रहीत करना मूल रूप से एक ही तार्किक सामग्री को दो बार संग्रहीत करना है। यह "अपने आप को दोहराना नहीं" (उर्फ DRY ) सिद्धांत का उल्लंघन करता है ।
एक कम दार्शनिक लेकिन अधिक व्यावहारिक कारण यह है कि जीआईटी में संग्रहीत होने पर खनन / अनुकूलित संपत्तियों की बहुत खराब संपीड़ितता होती है। स्रोत नियंत्रण प्रणालियां संग्रहीत प्रत्येक फ़ाइल के विभिन्न संस्करणों के बीच परिवर्तनों ("डेल्टास") को पहचानकर काम करती हैं। ऐसा करने के लिए, वे पिछले संस्करण के साथ नवीनतम फ़ाइल को "अलग" करते हैं, और फ़ाइल के हर संस्करण की पूरी प्रतिलिपि संग्रहीत करने से बचने के लिए इन डेल्टास का उपयोग करते हैं। लेकिन मिनिफाइ / ऑप्टिमाइज़ स्टेप में किए गए ट्रांसफ़ॉर्मेशन अक्सर समानताओं को हटा देते हैं और डिफॉल्ट / डेल्टा एल्गोरिदम का उपयोग करते हैं। सबसे तुच्छ उदाहरण लाइन ब्रेक और अन्य व्हाट्सएप को हटा रहा है; परिणामी संपत्ति अक्सर सिर्फ एक लंबी लाइन होती है। वेब बनाने की प्रक्रिया के कई भाग - Babel , UglifyJS , Browserify जैसे उपकरण ,कम , और Sass / SCSS - आक्रामक रूप से परिसंपत्तियों को परिवर्तित करें। उनका उत्पादन खराब है; छोटे इनपुट परिवर्तन से आउटपुट में बड़े बदलाव हो सकते हैं। नतीजतन, डिफ-एल्गोरिदम अक्सर यह विश्वास करेगा कि यह हर बार लगभग पूरी तरह से अलग फाइल देखता है। परिणामस्वरूप आपके रिपॉजिटरी अधिक तेज़ी से विकसित होंगे। आपके डिस्क काफी बड़े हो सकते हैं और आपके नेटवर्क काफी तेजी से बढ़ते हैं जो एक बड़ी चिंता का विषय नहीं है, खासकर अगर दो बार की गई / अनुकूलित संपत्तियों को संग्रहीत करने के लिए एक मूल्य था - हालांकि बिंदु 1 पर आधारित, अतिरिक्त प्रतियां सिर्फ 100% व्यर्थ हो सकती हैं ब्लोट।
हालांकि, इसके लिए एक बड़ा अपवाद है: DevOps / क्लाउड परिनियोजन। क्लाउड विक्रेताओं और देवओप्स की कई टीमें Git का उपयोग करती हैं और इसी तरह न केवल विकास अपडेट को ट्रैक करने के लिए, बल्कि परीक्षण और उत्पादन सर्वर के लिए अपने अनुप्रयोगों और परिसंपत्तियों को सक्रिय रूप से तैनात करने के लिए भी उपयोग करती हैं। इस भूमिका में, गिट की कुशलता से "क्या फाइलें बदल गईं?" यह निर्धारित करने के लिए अपनी अधिक दानेदार क्षमता के रूप में महत्वपूर्ण है "प्रत्येक फ़ाइल के भीतर क्या बदल गया है?" यदि गिट को छोटी / अनुकूलित संपत्तियों के लिए लगभग पूरी फाइल कॉपी करनी होती है, तो इससे थोड़ा अधिक समय लगता है, लेकिन कोई बड़ी बात नहीं है क्योंकि यह अभी भी उत्कृष्ट काम कर रहा है, जो प्रत्येक परियोजना में "हर फाइल की प्रतिलिपि" से बचने में मदद करता है। साइकिल चलाना।
यदि आप Git को परिनियोजन इंजन के रूप में उपयोग कर रहे हैं, तो Git में की गई / अनुकूलित संपत्तियों को संग्रहीत करना "नहीं!" से स्विच हो सकता है। वांछनीय के लिए। वास्तव में, इसकी आवश्यकता हो सकती है, यदि आपके पास सर्वर / सेवाओं पर मजबूत बिल्ड / पोस्ट-प्रोसेसिंग अवसरों की कमी है, जिसे आप तैनात करते हैं। (उस मामले में विकास और परिनियोजन परिसंपत्तियों को कैसे अलग किया जा सकता है? यह कीड़े का एक अलग प्रकार है। अभी के लिए, यह पता है कि इसे एक ही एकीकृत रिपॉजिटरी, कई शाखाओं, उप-केंद्रों, या एकाधिक ओवरलैपिंग रिपॉजिटरी सहित कई तरीकों से प्रबंधित किया जा सकता है। )
/dev/null:।