क्या मुझे अपनी परियोजना फाइलों को संस्करण नियंत्रण में रखना चाहिए? [बन्द है]


87

क्या मुझे एक्लिप्स की .project, .classpath, .settings जैसी परियोजना फाइलों को संस्करण नियंत्रण में रखना चाहिए (जैसे कि सबवर्सन, GitHub, CVS, Mercurial, आदि)।


यह भी देखें stackoverflow.com/questions/1429125/...
VonC

12
बहुत ही रचनात्मक
QED

जवाबों:


93

आप किसी भी पोर्टेबल सेटिंग फ़ाइलों को संस्करण नियंत्रण में रखना चाहते हैं ,
जिसका अर्थ है:
कोई भी फ़ाइल जिसमें कोई पूर्ण पथ नहीं है।
इसमें शामिल है:

  • .project,
  • .classpath ( यदि कोई पूर्ण पथ उपयोग नहीं किया जाता है , जो IDE चर, या उपयोगकर्ता पर्यावरण चर के उपयोग से संभव है)
  • आईडीई सेटिंग्स (जो कि मैं 'स्वीकृत' उत्तर से दृढ़ता से असहमत हूं)। उन सेटिंग्स में अक्सर स्थिर कोड विश्लेषण नियम शामिल होते हैं जो इस परियोजना को अपने कार्यक्षेत्र में लोड करने वाले किसी भी उपयोगकर्ता के लिए लगातार लागू करना महत्वपूर्ण हैं।
  • IDE विशिष्ट सेटिंग्स अनुशंसाओं को एक बड़ी README फ़ाइल (और संस्करण के रूप में अच्छी तरह से) में लिखा जाना चाहिए।

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


@ रीच: धन्यवाद। अन्य पाठकों के लिए, रिच का जवाब उसी प्रश्न के एक साल बाद देखें: stackoverflow.com/questions/1429125/…
VonC

3
प्रमुख चरण "... मिनटों में जा रहा है ..."
एरिक लाबाशोस्की

3
तो, वीसी रिपॉजिटरी में हर आईडीई के लिए कॉन्फिग फाइल होनी चाहिए? NetBeans, ग्रहण, Emacs, vi, जो भी हो? मैं विशेष रूप से इस विचार से असहमत हूं कि ये फाइलें क्योंकि डेवलपर को अपनी आईडीई स्थापित करने के लिए जिम्मेदार होना चाहिए।
RHSeeger

3
@ आरएच - "... अपनी आईडीई स्थापित करने के लिए जिम्मेदार होना चाहिए"। यह ठीक है, जब तक कुछ विदूषक अपनी ग्रहण कोड शैली गुण सेट करना भूल जाते हैं .... और उनमें TAB के साथ स्रोत फ़ाइलों में जाँच करते हैं। Grrrr !!
स्टीफन सी

2
मैं भी असहमत हूं - यदि आप CI, कई संस्करणों, प्लेटफार्मों, आईडीई आदि का उपयोग कर रहे हैं, तो यह बहुत बुरी तरह से टूट जाता है। Esp। चूंकि अलग-अलग प्लगइन्स / सेटिंग्स का यहां समाप्त होने पर बड़ा प्रभाव पड़ता है।
जैशाओ

30

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


2
-1 मैं उन हजारों लोगों का समय बर्बाद करने की अनुमति देने के बजाय उन प्लग इन के लिए बग रिपोर्ट दर्ज करने का सुझाव दूंगा। और फिर, मैंने सभी स्थिर सेटिंग्स फ़ाइलों को संस्करण नियंत्रण में रख दिया और उस विकी पृष्ठ को नंगे हड्डियों में ट्रिम कर दिया।
एरोन दिगुल्ला

18

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

इसके बजाय, मैं एक बिल्ड टूल (मावेन) का उपयोग करता हूं जो एक नया चेकआउट करने पर इन फ़ाइलों के प्रारंभिक संस्करण उत्पन्न कर सकता है।


सटीक होने के लिए: मवन ग्रहण: ग्रहण एक उपयुक्त .classpath और .project उत्पन्न करेगा। आप इसे पास कर सकते हैं -DdownloadSource = true और -DdownloadJavadocs = true।
अलेक्जेंडर दिमित्रोव

आप हमेशा स्रोत और जावदोक डाउनलोड करने के लिए अपने पोम में ग्रहण प्लगइन को कॉन्फ़िगर कर सकते हैं।
क्रिस वेस्ट

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

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

इसके अलावा, प्लग-इन के कारण मर्ज संघर्ष को ठीक करने से जो इन फाइलों को तेजी से संपादित करते हैं, वे बहुत जल्दी पुराने हो जाते हैं।
क्रिस वेस्ट

7

मैं यहां दो विकल्पों के बीच फटा हुआ हूं।

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

दूसरी ओर, मुझे लगता है कि इतने सारे लोग एक ही उपकरण (जैसे ग्रहण) का उपयोग करते हैं और अक्सर यह बेहतर होता है कि कुछ चीजों को बिल्ड टाइम के बजाय डिज़ाइन समय पर मानकीकृत किया जाए - उदाहरण के लिए चेकस्टाइल एक ग्रहण प्लगइन की तुलना में कहीं अधिक उपयोगी है। एक चींटी या मावेन कार्य - कि विकास उपकरण और प्लगइन्स के एक सामान्य सेट पर मानकीकरण करना बेहतर है।

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

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

PS यदि आप मावेन का उपयोग करते हैं, तो यह कहने के लिए एक तर्क है कि .project और .classpath फाइलें व्युत्पन्न कलाकृतियाँ हैं। यह केवल सच है यदि आप उन्हें हर बार जब आप एक निर्माण करते हैं, और यदि आपने उन्हें पोम से उत्पन्न करने के बाद कभी हाथ से हाथ नहीं फेरना है (या अनजाने में उन्हें कुछ प्राथमिकताएँ बदलकर बदल दिया है)।


6

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


5

नहीं, मैं एक भारी मावेन उपयोगकर्ता हूं और ग्रहण प्लगइन के लिए क्यू का उपयोग करता हूं जो बनाता है और रखता है। सुरक्षित करें और .classpath को अपडेट करें। अन्य चीजों के लिए जैसे कि प्लगइन्स के लिए सेटिंग्स मैं आमतौर पर एक README या विकी-पेज के बारे में बताता हूं।

इसके अलावा जिन लोगों के साथ मैंने काम किया है वे अन्य आईडीई को पसंद करते हैं बस अपने आईडीई (और खुद) को खुश रखने के लिए आवश्यक फाइलों को उत्पन्न करने के लिए मावेन-प्लगइन्स का उपयोग करें।


5

यह सब राय है, मुझे लगता है - लेकिन वर्षों से सर्वोत्तम प्रथाओं से संकेत मिलता है कि किसी दिए गए आईडीई के लिए विशिष्ट फ़ाइलों को स्रोत नियंत्रण में संग्रहीत नहीं किया जाना चाहिए, जब तक कि आपके पूरे संगठन को एक आईडीई पर मानकीकृत नहीं किया जाता है और आपके पास स्विच करने का कोई इरादा नहीं है।

किसी भी तरह से, आप निश्चित रूप से उपयोगकर्ता सेटिंग्स संग्रहीत नहीं करना चाहते हैं - और .project में ऐसी सेटिंग्स हो सकती हैं जो वास्तव में डेवलपर विशिष्ट हैं।

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


1

हाँ, .settings फ़ोल्डर को छोड़कर। अन्य फ़ाइलों को कमिट करना हमारे लिए अच्छा है। यहां भी ऐसा ही सवाल है


1

हालांकि मैं आम तौर पर "फ़ाइल उत्पन्न न करें" दृष्टिकोण पर सहमत हूं, हमें इसके साथ समस्या है और इसे वापस स्विच करना होगा।

नोट: मुझे वॉनसी के जवाब में भी दिलचस्पी है , विशेष रूप से "मिनट के भीतर ग्रहण करें" बिंदु के बारे में। लेकिन यह हमारे लिए निर्णायक नहीं है।

एम 2 सीप्लेस प्लग-इन का उपयोग करके हमारा संदर्भ ग्रहण + मावेन है। हमारे पास एक समान विकास का माहौल है, जहां आम निर्देशिका संभव है। लेकिन ऐसा कभी-कभी होता है कि कोई व्यक्ति प्लग-इन की कोशिश करेगा, या कॉन्फ़िगरेशन में छोटी चीज़ों को बदल देगा, या किसी अन्य कार्यक्षेत्र के लिए दूसरा कार्यक्षेत्र आयात कर सकता है ...

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

एकमात्र समाधान जो हम देखते हैं। .project फ़ाइल को संस्करणित करना (जोखिम से बचने के लिए, हम .classpath और .settings के लिए भी ऐसा ही करेंगे)। इस तरह, जब एक डेवलपर अपने पोम को बदलता है, तो स्थानीय फाइलें m2eclipse का उपयोग करके अपडेट हो जाती हैं, वे सभी एक साथ प्रतिबद्ध हो जाते हैं, और अन्य डेवलपर्स सभी परिवर्तन देखेंगे।

नोट: हमारे मामले में, हम सापेक्ष फ़ाइल नामों का उपयोग करते हैं, इसलिए हमें उन फ़ाइलों को साझा करने में कोई समस्या नहीं है।

इसलिए, आपके प्रश्न का उत्तर देने के लिए, मैं कहता हूं कि हां, उन फाइलों को कमिट करें।


मैंने भी पसंद किया:


"... m2eclipse का उपयोग करके उसका पोम बदलता है ..."? M2eclipse का पोम फाइल से क्या लेना-देना है? निश्चित रूप से यह इसका उपयोग करता है, लेकिन पोम में परिवर्तन प्लगइन से स्वतंत्र होना चाहिए।
RHSeeger

@RHSeeger धन्यवाद, मैं अपने उत्तर के इस भाग पर स्पष्टता में सुधार करूंगा।
केएलई

0

ऐसा लगता है जैसे ये प्रोजेक्ट समय के साथ बदल सकते हैं क्योंकि आप किसी प्रोजेक्ट पर काम करते हैं, हां, मैं उन्हें संस्करण नियंत्रण में रखता हूं।


0

हाँ। सब कुछ लेकिन उत्पादन का निर्माण।


0

हम IntelliJ IDEA का उपयोग करते हैं, और प्रोजेक्ट नियंत्रण (.ipr) और मॉड्यूल (.iml) फ़ाइलों के '.sample' संस्करणों को संस्करण नियंत्रण में रखते हैं।

यहाँ कुछ हद तक बड़ी बात साझा करने और फिर से उपयोग करने की तुलना में, IMHO है। लेकिन अगर आप इन कॉन्फ़िगरेशन को साझा करने जा रहे हैं, तो उन्हें रिपॉजिटरी की तुलना में क्या बेहतर जगह मिल सकती है, बाकी सब चीजों के बगल में।

साझा और संस्करणित परियोजना फ़ाइलों के कुछ लाभ:

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

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

मैं इस उत्तर से सहमत हूँ जो कहता है:

आपको किसी प्रोजेक्ट को कार्यक्षेत्र में लोड करने में सक्षम होना चाहिए और उसमें वह सब कुछ होना चाहिए जो आपको अपनी आईडीई में ठीक से सेट करना है और मिनटों में जाना है। [...] इसे लोड करें, इसे सेट अप करें, जाएं।

और हमारे पास यह इस तरह है, संस्करणित फ़ाइलों के लिए धन्यवाद।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.