एंड्रॉइड स्टूडियो - पूरी .idea निर्देशिका गिट में अनदेखा होनी चाहिए?

Question

मैंने AndroidSudio के लिए कई उदाहरण देखे हैं, कुछ में .idea हैं, और कुछ नहीं हैं।

क्या कोई अच्छा कारण नहीं है कि पूरे .idea dir को .gitignore में शामिल न करें?

अगर इसे पूरी तरह से अनदेखा नहीं किया जाना चाहिए, तो वहाँ .idea (जैसे .iml) के अंदर विशिष्ट फाइलें हैं जो .gitignore में होनी चाहिए?

Answer 1

आप इस पृष्ठ पर एक नज़र ले जा सकते हैं:

IntelliJ doc about project configuration files

"निर्देशिका आधारित स्वरूप" में, एक विशेष लाइन दिलचस्प है:

.idea निर्देशिका एक सेट होता है विन्यास फाइलों (.xml) के। प्रत्येक फ़ाइल में एक निश्चित कार्यात्मक क्षेत्र से संबंधित कॉन्फ़िगरेशन डेटा का केवल एक हिस्सा होता है जो फ़ाइल के नाम पर दिखाई देता है, उदाहरण के लिए, compiler.xml, encodings.xml, modules.xml।

लगभग सभी फाइलें परियोजना के लिए सूचना कोर होती हैं, जैसे कि इसके घटक मॉड्यूल के नाम और स्थान, कंपाइलर सेटिंग्स इत्यादि। इस प्रकार, ये फ़ाइलें संस्करण नियंत्रण में रखी जा सकती हैं (और चाहिए)।

हालांकि, मैं ठीक से परियोजना आईडीई पर निर्भर बनाने के लिए नफरत है (मैं वर्तमान में NetBeans के साथ किए गए एक परियोजना पर काम कर रहा हूँ और यह ग्रहण जो मेरी कंपनी के मानक बन जाता है के साथ इसका इस्तेमाल करने के दर्द होता है)। संस्करण नियंत्रण तहत निर्देशिका रखें: आप निर्भरता का प्रबंधन और निर्माण करने के लिए कुछ Maven या Gradle की तरह उपयोग नहीं करते हैं

1. :

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

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

Answer 2

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

Answer 3

ठीक है, तो कुछ "हाँ" और "नहीं" जवाब के बाद, मैं द्वारा जोड़ा जा रहा एक "हाँ और नहीं" का जवाब :)

समस्या यह है कि .idea दोनों परियोजना का निर्माण विन्यास (निर्भरता घोषणा) के लिए इस्तेमाल किया जाता है और परियोजना सेटिंग्स (निरीक्षण, आदि)।

आप निश्चित रूप से अपने निर्माण कॉन्फ़िगरेशन के लिए अपने आईडीई का उपयोग नहीं करना चाहते हैं, लेकिन आप टीम के बीच सेटिंग्स साझा करना चाहेंगे। यही कारण है कि आप .idea सामग्री (libraries फ़ोल्डर और modules.xml फ़ाइल की तरह) का केवल एक हिस्सा उपेक्षा, लेकिन संस्करण नियंत्रण में लोगों को परेशान (करने की आवश्यकता है जैसे copyright, dictionaries और inspectionProfiles फ़ोल्डर और फ़ाइलें .idea तहत dynamic.xml, codeStyleSettings.xml, आदि जैसे ।)।

Answer 4

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

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

• Symlinking परियोजना फ़ोल्डरों सही काम नहीं करता:

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

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

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