कम और संस्करण नियंत्रण का उपयोग करना: उत्पन्न सीएसएस को रेपो में शामिल किया जाना चाहिए?

Question

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

सीएसएस फ़ाइलों को संस्करण नियंत्रण में शामिल किया जाना चाहिए या नहीं? कृपया ध्यान रखें कि कुछ ढांचे को एक विशेष कारण के लिए एक सीएसएस फ़ाइल मौजूद होने की आवश्यकता होती है (यानी WordPress विषयों को पहचानने के लिए style.css फ़ाइल की आवश्यकता होती है)।

चीयर्स!

संपादित करें: जब मैं 'कम उपयोग करने पर विचार करना' कहता हूं, मेरा मतलब है कि यह एक आवश्यकता बन जाती है। पसंद के बाद पसंद के बाद नए डेवलपर्स के पास वेनिला सीएसएस का विकल्प नहीं होगा।

Answer 1

आपने अपने खुद के प्रश्न का बहुत अधिक जवाब दिया है। यह इस बात पर निर्भर करता है कि आप अपनी वेबसाइट को कैसे तैनात करते हैं।

सर्वर सिर्फ Git भंडार से सीधे खींचने के लिए जा रहा है:

1) यह कम से सीएसएस उत्पन्न करने के लिए स्थापित सॉफ्टवेयर की जरूरत है।

2) या आपको भंडार में सीएसएस फ़ाइलों को शामिल करने की आवश्यकता है।

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

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

सॉफ़्टवेयर विकास के मामले में, आपके पास मेकफ़ाइल के साथ मेकफ़ाइल होगा और .एच फाइलें (उदाहरण के लिए) आपके गिट रिपोजिटरी में। डेवलपर्स और बिल्ड सर्वर में एक कंपाइलर स्थापित है जो निष्पादन योग्य या संकलित लाइब्रेरी बनायेगा। जब फ़ाइलों को वितरण के लिए पैक किया जाता है, तो स्रोत कोड संग्रह का हिस्सा नहीं होता है।

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

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

Answer 2

मैं हाँ कहूंगा - क्योंकि यदि आप अपने वर्कफ़्लो में डेवलपर जोड़ना चाहते हैं तो वे क्या होते हैं और वे बनाना चाहते हैं या बनाने की आवश्यकता नहीं है। उनके लिए केवल जेनरेट की गई फ़ाइल तक पहुंच होगी।

Answer 3

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

Answer 4

व्युत्पन्न कलाकृतियों में जांच लगभग हमेशा उप-इष्टतम है।

मैं .css में जांच करने के लिए वोट नहीं देता हूं। यह केवल समय की बात है जब तक कि आपके साथियों में से कोई भी उत्तराधिकारी .css में संपादित नहीं करता है, न कि .less। फिर जब आप बदलते हैं। पूर्व परिवर्तन खो जाता है।

Answer 5

सीएसएस फ़ाइलों को संस्करण नियंत्रण में शामिल किया जाना चाहिए या नहीं?

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

1. आप git add --patch उपयोग नहीं कर सकते (या तुम सच में ऐसा करते हुए बहुत सावधान रहना चाहिए)
2. आप .css संशोधित नहीं करना चाहिए:

   अब, वहाँ ऐसा करने पर कमियां हैं सीधे; इसके बजाय मैं आमतौर पर प्राथमिक .less या .css फ़ाइल को संशोधित किए बिना मामूली संशोधन करने के लिए एक माध्यमिक .css फ़ाइल का उपयोग करता हूं। जेनरेट सीएसएस को संशोधित करने के लिए इसे कम आकर्षक बनाने के लिए, आप सीधे एक मिनीफाइड सीएसएस में फ़ाइल को संकलित भी कर सकते हैं।

3. डेवलपर्स को स्वचालित रीकंपाइल टूल (जैसे सिम्पलेस या कम.एप) का उपयोग करने के लिए अपनी मशीन सेट अप करना है, इसलिए .css फ़ाइल को .less फ़ाइल में सहेजने के तुरंत बाद अद्यतन किया जाता है। स्वचालन के बिना, आप सीएसएस के जोखिम में भाग लेंगे जो चेक-इन कम फ़ाइल से मेल नहीं खाता है।

जब हालांकि .सी और एच फाइलों से संकलन, क्योंकि उन के लिए उत्पन्न द्विआधारी मंच विशिष्ट हैं मैं भी ऐसा ही नहीं होता, और भी .less/.css फ़ाइल आम तौर पर एक बड़ा का एक बहुत छोटा हिस्सा है वेब प्रोजेक्ट ताकि अतिरिक्त फ़ाइल का स्पेस ओवरहेड छोटा हो।