क्या जनरेट किए गए दस्तावेज़ को Git रिपॉजिटरी में संग्रहीत किया जाना चाहिए?

49

जब आप jsdocs जैसे टूल का उपयोग करते हैं , तो यह आपके कोड में टिप्पणियों के आधार पर आपके HTML कोड में स्थिर HTML फ़ाइलों और इसकी शैलियों को उत्पन्न करता है।

क्या इन फाइलों को गिट रिपॉजिटरी में चेक किया जाना चाहिए या उन्हें .ignignore के साथ अनदेखा किया जाना चाहिए?

git documentation

— कचरा इकठा करना
स्रोत

3

GitHub रिपॉजिटरी में उन्हें संग्रहीत करने के लिए एक तर्क हो सकता है क्योंकि आप पृष्ठों का उपयोग करके स्थिर HTML प्रकाशित कर सकते हैं । हालाँकि तब तर्क का एक पूरी तरह से अलग सेट उत्पन्न होता है कि आप कैसे सुनिश्चित करें कि वे अद्यतित हैं आदि ...

— बोरिस स्पाइडर

21

यदि फाइलें उत्पन्न होती हैं, तो परिभाषा के अनुसार वे स्रोत नहीं हैं ।

— क्राइसिस -ऑन स्ट्राइक-

3

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

— Džuris

5

बल्कि उत्पन्न

— कुटकी

7

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

— अलेक्जेंडर

131

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

तो उन फाइलों को .gitignore के साथ अनदेखा किया जाना चाहिए।

— 1201ProgramAlarm
स्रोत

4

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

— पीटर मोर्टेंसन

27

@PeterMortensen यदि आपको एक विशेष संस्करण के साथ निर्मित टूल की आवश्यकता है, तो आप इसे उन बिल्ड टूल के संस्करण के साथ निर्मित करते हैं जिनकी आपको आवश्यकता है। इस तरह की आवश्यकता या तो अपने आप में एक खोज है, जिस स्थिति में आप स्वयं हैं; बी) आरईएडीएमई में प्रलेखित ("आपको दो स्थापित किए जाने वाले डॉक्सीजन के 2 विशिष्ट संस्करणों की आवश्यकता होगी"); c) बिल्ड स्क्रिप्ट से निपटा (वे उपलब्ध बिल्ड टूल संस्करण की जांच करते हैं और उचित रूप से कार्य करते हैं)। किसी भी मामले में, स्रोत नियंत्रण स्रोतों के लिए है, न कि कलाकृतियों के निर्माण के लिए।

— जोकर_vD

2

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

— अलेक्जेंडर

4

@Alexander क्या आप रेपो में निर्मित बाइनरी भी डालेंगे? दस्तावेज बनाया गया है। आप बिल्ट डॉक्यूमेंटेशन लेते हैं और इसे कहीं सुलभ बनाते हैं।

— 1201ProgramAlarm

5

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

— अलेक्जेंडर

23

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

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

@ कर्ट सिम्पसन: सभी सॉफ्टवेयर आवश्यकताओं का दस्तावेज होना बहुत बेहतर है, जैसा कि मैंने कई स्थानों पर देखा है।

— gnasher729
स्रोत

7

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

— कर्ट जे। सैम्पसन

5

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

— सुल्तान

वह आपका नियम है और यह एक अच्छा नियम है और मुझे यह पसंद है। लेकिन दूसरे अपने नियम खुद बना सकते हैं।

— एमोरी

मुझे लगता है कि आपका मतलब है "एक बिल्ड कमांड चलाएं," क्योंकि आपकी मशीन पर कोई बिल्ड बटन नहीं होगा। ... जब तक आप पूरे निर्माण की उम्मीद नहीं कर रहे हैं, तब तक एक आईडीई के साथ एकीकृत होना चाहिए, जो पूरी तरह से अनुचित है।

— jpmc26

@ jpmc26 मुझे यह पूरी तरह से उचित लगता है कि पूरे निर्माण को एक आईडीई में एकीकृत किया जाए। मेरी मशीन पर निर्मित बटन कमांड-बी है।

— gnasher729

14

इन फ़ाइलों की जाँच नहीं की जानी चाहिए क्योंकि उन्हें उत्पन्न करने का डेटा पहले से मौजूद है। आप डेटा को दो बार (DRY) स्टोर नहीं करना चाहते हैं।

यदि आपके पास CI सिस्टम है, तो आप शायद डॉक्स का निर्माण कर सकते हैं और उन्हें उस बिल्ड के लिए स्टोर कर सकते हैं / वेब सर्वर पर प्रकाशित कर सकते हैं।

— Tvde1
स्रोत

4

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

लेकिन ज्यादातर मामलों में उन्हें स्रोत नियंत्रण में रखने की आवश्यकता नहीं होती है, जैसा कि अन्य उत्तरों में बताया गया है।

— पाओलो एबरमन
स्रोत

1

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

— cmaster

1

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

— anone

3

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

— anone
स्रोत

2

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

क्या डॉक्स उत्पादन की आवश्यकता है?
क्या डॉक्स बनाने के लिए आपके परिनियोजन सिस्टम में आवश्यक उपकरणों की कमी है?

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

— Trendfischer
स्रोत

1

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

— कर्ट जे। सैम्पसन

2

निर्भर करता है। यदि वे डॉक्स:

जरूरत है रिपॉजिटरी का हिस्सा बनने की, जैसी है readme.md, फिर उसे git रेपो में रखना पसंद किया जाता है। क्योंकि उन स्थितियों को स्वचालित तरीके से संभालना मुश्किल हो सकता है।
यदि आपके पास CI सिस्टम की तरह उन्हें बनाने और अपडेट करने का स्वचालित तरीका नहीं है, और इसका उद्देश्य सामान्य दर्शकों के लिए देखा जाना है, तो उन्हें git रेपो में रखना पसंद किया जाता है।
उन्हें बनाने के लिए समय का एक बहुत लेता है, तो उन्हें रखने के लिए उचित है।
आम दर्शकों (उपयोगकर्ता मैनुअल की तरह) के लिए देखे जाने का इरादा है, और इसे बनाने में काफी समय लगता है, जबकि आपके पिछले डॉक्स दुर्गम (ऑफलाइन) हो जाते हैं, फिर उन्हें गिट रेपो में रखने के लिए उचित है।
आम दर्शकों के लिए देखे जाने का इरादा है और इसके परिवर्तनों / विकास के इतिहास को दिखाना है, पिछले डॉक संस्करणों को कम करके रखना और पिछले से जुड़े नए को बनाना / बनाना आसान हो सकता है। न्यायोचित।
सभी टीम के शुरू होने के लिए एक विशिष्ट स्वीकृत कारण है, फिर उन्हें गिट रेपो में रखने के लिए उचित है। (हम आपके संदर्भ को नहीं जानते, आप और आपकी टीम ऐसा करती है)

किसी भी अन्य परिदृश्य में, इसे सुरक्षित रूप से अनदेखा किया जाना चाहिए।

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

— throawableAccount2892391
स्रोत

1

संस्करण नियंत्रण के सिद्धांत के रूप में, केवल "प्राथमिक वस्तुओं" को भंडार में संग्रहीत किया जाना चाहिए, न कि "व्युत्पन्न वस्तुओं" पर।

नियम के अपवाद हैं: अर्थात्, जब भंडार के उपभोक्ता हैं जिन्हें व्युत्पन्न वस्तुओं की आवश्यकता होती है, और उनसे उत्पन्न होने के लिए आवश्यक उपकरण नहीं होने की यथोचित अपेक्षा की जाती है। अन्य विचारों का वजन कम होता है, जैसे सामग्री की मात्रा क्या है? (क्या यह परियोजना के लिए बेहतर होगा कि सभी उपयोगकर्ताओं को उपकरण मिलें?)

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

— Kaz
स्रोत