git - गिट स्रोत नियंत्रण के तहत IntelliJ IDEA प्रोजेक्ट फ़ाइलों को लगातार कैसे बदलते हैं?




version-control intellij-idea (4)

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

हालांकि, जब आप आईडीईए में कुछ भी करते हैं तो वे फ़ाइलें छोटे तरीकों से बदलती हैं। आईडीईए के मुद्दे डेटाबेस ( IDEA-64312 ) में कोई समस्या है, इसलिए शायद कोई इसे आईडीईए में एक बग पर विचार कर सकता है, लेकिन यह एक है जिसे हमें निकट भविष्य के साथ जीने की आवश्यकता होगी।

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

तो, यहां कुछ विचार हैं जिनके पास हमारे पास विकल्प हैं जिनसे हमें इससे निपटना होगा:

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

मुझे लगता है कि मैं उम्मीद कर रहा हूं कि कुछ स्पष्ट (या गैर-स्पष्ट) समाधान हमने याद किया है, शायद गिट और आईडीईए दोनों की विशाल अनुकूलता से निपटने के लिए। लेकिन ऐसा लगता है कि हम संभवतः इस समस्या वाले एकमात्र टीम नहीं हो सकते थे। 3495191 पर समान प्रकार के 3495191 में 3495191 , 1000512 , और 3873872 , लेकिन मुझे नहीं पता कि वे बिल्कुल एक ही समस्या हैं, और हो सकता है कि कोई भी मेरे द्वारा उल्लिखित विभिन्न दृष्टिकोणों के लिए पेशेवरों और विपक्ष के साथ आ सकता है , उन प्रश्नों के उत्तर में सूचीबद्ध दृष्टिकोण, या दृष्टिकोण जो वे अनुशंसा करते हैं।

धन्यवाद।


आधिकारिक डीओसी से: devnet.jetbrains.com/docs/DOC-1186

IntelliJ IDEA प्रोजेक्ट प्रारूप (.ipr फ़ाइल आधारित या .idea निर्देशिका आधारित) के आधार पर, आपको संस्करण नियंत्रण के तहत निम्न IntelliJ IDEA प्रोजेक्ट फ़ाइलों को रखना चाहिए:

.ipr फ़ाइल आधारित प्रारूप

प्रोजेक्ट .ipr फ़ाइल और सभी .iml मॉड्यूल फ़ाइलों को साझा करें, .iws फ़ाइल साझा न करें क्योंकि यह उपयोगकर्ता विशिष्ट सेटिंग्स संग्रहीत करता है।

.idea निर्देशिका आधारित प्रारूप

Workspace.xml और tasks.xml फ़ाइलों को छोड़कर प्रोजेक्ट रूट में .idea निर्देशिका के अंतर्गत सभी फ़ाइलों को साझा करें जो उपयोगकर्ता विशिष्ट सेटिंग्स को संग्रहीत करते हैं, सभी .iml मॉड्यूल फ़ाइलों को भी साझा करते हैं।

मैंने इसे अपने .gitignore में रखा:

#Project
workspace.xml
tasks.xml

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


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

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

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


मैंने स्रोत नियंत्रण से वर्कस्पेस.एक्सएमएल लिया (+ .gitignore में जोड़ा गया)।






intellij-idea