आईडीई परियोजनाओं से मुझे अपने भंडार में क्या शामिल करना चाहिए

Question

मैं एक परियोजना जोड़ना चाहता हूं जो इस मामले में Netbeans में बनाई गई है लेकिन अधिकांश IDE के लिए यह प्रश्न सामान्य है। यह बस है, मुझे अपने भंडार में क्या शामिल करना चाहिए। उदाहरण के लिए Netbeans एक nbproject फ़ोल्डर बनाता है, ग्रहण एक .settings फ़ोल्डर बनाता है आदि क्या मुझे अपनी रिपॉजिटरी में इन्हें शामिल करना चाहिए, प्रोजेक्ट विशिष्ट सेटिंग्स को शामिल करने या न करने के क्या फायदे / नुकसान हैं।

इस मामले में यह एक व्यक्तिगत परियोजना है, इसलिए मुझे नहीं लगता कि अन्य लोग इस पर काम करना शुरू करेंगे, लेकिन परियोजना सेटिंग्स के नंगे न्यूनतम को जोड़ना अच्छा होगा, इसलिए परियोजना स्वयं विभिन्न मशीनों पर काम शुरू करना आसान होगा।

Comments

अपने स्वयं के बजाय उचित वातावरण स्थापित करने के लिए अपने ग्रहण प्लगइन (या अन्य विचारधारा) के साथ मावेन जैसे उपकरणों पर विचार करें ।

@MichaelT मुझे बहुत खेद है, लेकिन मैं वास्तव में अनुसरण नहीं करता, क्या आप उस पर विस्तार करना चाहेंगे?

— डैनियल फिगेरो

बिल्ड टूल का उपयोग करना और बिल्ड टूल को आइड के लिए वातावरण सेट करना आपको यह सुनिश्चित करने की अनुमति देता है कि सेटअप वही है जो प्लेटफॉर्म (या ide) पर कोई फर्क नहीं पड़ता। यहां तक ​​कि एकल डेवलपर्स के पास कई वातावरण हैं (ide vs build)। यह उस प्रश्न को सरल करता है जिसका उत्तर दिया गया है "किसी भी चीज की जांच न करें जो आपके पर्यावरण के लिए विशिष्ट है क्योंकि वे कोड उत्पन्न होते हैं।" - वही तर्कसंगत जिसे आप jaxb द्वारा उत्पन्न .java वर्गों में नहीं जाँचते, बल्कि उन्हें बनाने के तरीके पर निर्देश (बिल्ड .xml या .pom फ़ाइल) बनाते हैं।

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

— मैट्नज़

Answer 1

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

लेकिन IDE प्रोजेक्ट फ़ाइलों में से कुछ महत्वपूर्ण प्रोजेक्ट मेटाडेटा हैं। मैं नेटबीन्स को अच्छी तरह से नहीं जानता, लेकिन ग्रहण के लिए .project फ़ाइल आईडीई को बताती है कि प्रोजेक्ट का नाम क्या है, यह एक जावा वेब प्रोजेक्ट है, आदि और .classpath फ़ाइल में स्रोत फ़ोल्डर और लाइब्रेरीज़ के बारे में जानकारी है। .Settings निर्देशिका में कुछ फाइलें समान रूप से महत्वपूर्ण हो सकती हैं, जैसे org.eclipse.core.resources.prefs में यह जानकारी होती है कि किस फाइल के लिए एन्कोडिंग का उपयोग किया जाना चाहिए।

प्रोजेक्ट मेटाडेटा के रूप में, यह सामान बहुत ही स्रोत नियंत्रण में संस्करण के योग्य है।

कुछ आईडीई अन्य आईडीई से परियोजना मेटाडेटा आयात कर सकते हैं। इसे उस रूप में रखना और भी बेहतर होगा जो किसी विशिष्ट IDE से बंधा नहीं है।

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

Comments

अगर मैं गलत नहीं हूं तो मावेन आईडीई स्वतंत्र है। यदि ऐसा है, तो, क्योंकि इसमें परियोजना सेटिंग्स / मेटाडेटा शामिल हैं, इसलिए इसे निश्चित रूप से रेपो में शामिल करना चाहिए, लेकिन "आईडीई प्रोजेक्ट फाइल" नहीं, जो ओपी विशेष रूप से संदर्भित करता प्रतीत होता है।

— ब्लीडिंग फिंगर्स

@ hus787: मेरा कहना यह है कि यह मेटाडेटा रेपो में होने के लिए बहुत महत्वपूर्ण है, और जब यह आपके पास आईडीई-इंडिपेंडेंट रूप में हो तो बहुत अच्छा होता है, जब ऐसा न हो तो भी बेहतर है कि इसे न लें। यह है।

— माइकल बोर्गवर्ड

Answer 2

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

यदि आप अपना कोड अन्य लोगों के साथ साझा करने में सक्षम होना चाहते हैं जो समान आईडीई का उपयोग नहीं कर सकते हैं, तो बस कोड को बिना किसी परियोजना विशेष कार्यान्वयन के प्रतिबद्ध करें।

यदि आप जानते हैं कि हर कोई एक ही IDE का उपयोग करता है, तो आप संभवतः कुछ भी शामिल कर सकते हैं जो कि कंप्यूटर विशिष्ट नहीं है, जो कि केवल IDE के लिए कोई भी सेटिंग फ़ाइल / फ़ोल्डर है, इस तरह वे पहले से ही परियोजना को आयात करने की क्षमता रख सकते हैं। आईडीई को उम्मीद है।

Answer 3

ऐसी कलाकृतियाँ जो आपके विकास में मदद करती हैं और निर्माण / जारी करने के लिए किसी काम की नहीं हैं या परियोजना को ही शामिल नहीं किया जाना चाहिए । रेपो साफ और सुव्यवस्थित होना चाहिए और केवल उन चीजों के लिए होना चाहिए जो परियोजना के लिए प्रासंगिक हैं न कि आपके पर्यावरण के लिए । रेपो को आपकी आदतों से अवगत होना चाहिए। और दूसरी बात यह अनावश्यक रूप से आपको बग कर देगी जब आप कुछ करने के लिए प्रेरित होते हैं git status... लेकिन हे मैंने कभी कोई बदलाव नहीं किया ... आह की उपेक्षा करें।

मुझे और अधिक व्यावहारिक उदाहरण दें (मैं gitएक उपकरण के रूप में यहां उपयोग करूंगा ):

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

विभिन्न मशीन पर अपनी सेटिंग का उपयोग करने में सक्षम होने के लिए, मैं सुझाव देता हूं कि आपके आईडीई के अंदर खुदाई करें और देखें कि इस तरह की चीजों के लिए क्या समर्थन प्रदान करता है। Emacs के पास initऔर Emacs सर्वर भी हैं। या आप अपने कस्टम मैक्रो या स्क्रिप्ट ( .sh) बना सकते हैं जो सेटअप स्वचालित रूप से करता है।

Comments

-1: पूरी तरह से असहमत। यह बहुत महत्वपूर्ण और उपयोगी जानकारी हो सकती है, और आपके रेपो में निश्चित रूप से ऐसी जानकारी शामिल होनी चाहिए ।

— माइकल बोर्गवर्ड

@MichaelBorgwardt क्या होगा अगर ओपी बाद में कुछ अन्य आईडीई पर स्विच करने की योजना बना रहा है। उन प्रोजेक्ट IDE विशिष्ट सेटिंग्स को दूसरे में कैसे समझा जाएगा? एक उदाहरण की बहुत सराहना की जाएगी।

— ब्लीडिंग फिंगर्स

कुछ आईडीई अन्य आईडीई से परियोजना मेटाडेटा आयात कर सकते हैं। यहां तक ​​कि अगर वे नहीं कर सकते हैं, तो ये फाइलें आमतौर पर कुछ हद तक मानव पठनीय होती हैं और उनके पास न होने से बेहतर है।

— माइकल बोर्गवर्ड

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

— एमी ब्लेंकशिप

@AmyBlankenship कि यह मेरा अपना कार्यक्षेत्र है, आप यह कैसे सुनिश्चित कर सकते हैं कि यह दूसरे का हस्तक्षेप नहीं करता है (वे अचानक से अपने कार्यक्षेत्र को अपने द्वारा प्रतिस्थापित कर लेते हैं), इसके लिए उन चीजों को एक अलग स्थानीय क्षेत्र में रखना बेहतर है आप अपनी व्यक्तिगत परियोजना विशिष्ट कार्यक्षेत्र कुलपति के लिए व्यापारिक उपयोग कर सकते हैं और परियोजना वीसी के लिए git कर सकते हैं। कोड टेम्प्लेट के बारे में, मुझे लगता है कि आपका IDE पर्याप्त परिपक्व नहीं है (या अभी तक ठीक से पता नहीं लगाया गया है) और यदि आपका कहना टेम्प्लेट विशिष्ट है, तो मुझे लगता है कि आपको अपने कोड में पैटर्न ढूंढना चाहिए।

— ब्लीडिंग फिंगर्स

Answer 4

यदि यह एक व्यक्तिगत परियोजना है, तो मैं कहता हूं कि सेटिंग्स को स्रोत नियंत्रण में संग्रहीत करें। व्यक्तिगत रूप से, फिर से विकास के माहौल को स्थापित करने की तुलना में एक परियोजना के लिए मेरी प्रेरणा को कुछ भी नहीं मारता है।

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

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

यदि आपकी टीम उसी IDE का उपयोग कर रही है तो यह बेहतर है, लेकिन तब कोई व्यक्ति खराब .classpath प्रविष्टि करता है क्योंकि उन्होंने एक निरपेक्ष पथ का उपयोग किया है। अब IDE का उपयोग करने वाला हर कोई इसके बारे में चिंता करता है।

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