গিট সোর্স নিয়ন্ত্রণের অধীনে ইন্টেলিজ আইডিইএ প্রকল্প ফাইলগুলি কীভাবে ডিল করবেন?


151

আমাদের দলের প্রত্যেকে ইন্টেলিজ আইডিইএ ব্যবহার করে এবং আমরা এর প্রকল্প ফাইলগুলি (.ipr এবং .iml) উত্স নিয়ন্ত্রণে রাখা কার্যকর মনে করি যাতে আমরা বিল্ড কনফিগারেশন, সেটিংস এবং তদন্তগুলি ভাগ করতে পারি। এছাড়াও, আমরা তারপরে টিমসিটির সাথে আমাদের অবিচ্ছিন্ন ইন্টিগ্রেশন সার্ভারে সেগুলি পরিদর্শন সেটিংস ব্যবহার করতে পারি। (আমাদের প্রতি ব্যবহারকারী কর্মক্ষেত্র .iws ফাইলটি .gitignore ফাইলটিতে আছে এবং উত্স নিয়ন্ত্রণে নেই))

যাইহোক, আপনি আইডিইএ-র যেকোন কিছু করতে গেলে এই ফাইলগুলি অল্প উপায়ে পরিবর্তন হয়। এটির জন্য আইডিইএর ইস্যু ডাটাবেসে একটি সমস্যা রয়েছে ( আইডিইএ-64৪৩১২ ), তাই সম্ভবত কেউ এটি আইডিইএতে একটি বাগ বিবেচনা করতে পারে তবে এটি আমাদের ভবিষ্যতের জন্য বাঁচতে হবে one

সাম্প্রতিক অবধি, আমরা সাবভারশন ব্যবহার করছিলাম, তবে আমরা সম্প্রতি গিতে স্যুইচ করেছি। আমরা একে অপরের সাথে ভাগ করে নিতে চাইলে প্রজেক্ট ফাইল পরিবর্তন না হওয়া পর্যন্ত আমাদের প্রতিটি প্রকল্পের ফাইলের পরিবর্তনের তালিকা থাকার অভ্যাস করেছিল যা আমরা উপেক্ষা করেছি এবং চেক ইন করিনি। কিন্তু গিটের সাথে, আসল শক্তি মনে হয় (আমরা যা আবিষ্কার করছি তা থেকে) এটি ধারাবাহিক শাখা প্রশস্ত করে যা এটি উত্সাহ দেয় এবং শাখাগুলির মধ্যে স্যুইচিং হ'ল প্রজেক্ট ফাইলগুলির সর্বদা সংশোধন করা ব্যথা। প্রায়শই এটি কোনওভাবে পরিবর্তনের সাথে একত্রী হতে পারে এবং প্রজেক্ট ফাইলের পরিবর্তনগুলি এখন নতুন শাখায় প্রয়োগ করার চেষ্টা করে deal তবে, যদি নতুন শাখা প্রকল্পের ফাইলগুলি পরিবর্তন করে (যেমন শাখাটি একটি নতুন মডিউলে কাজ করছে যা এখনও অন্য শাখায় নেই), গিটটি কেবল একটি ত্রুটি ছুঁড়ে দেয় যা এটি করে না ' টি যখন উভয় শাখায় পরিবর্তিত হয় এবং আপনার স্থানীয়ভাবে পরিবর্তন হয় তবে ফাইলগুলিতে মার্জ করার কোনও অর্থ নেই এবং আমি এর বিন্দুটি বুঝতে পারি। কমান্ড লাইন থেকে, "গিট চেকআউট" কমান্ডে "-f" ব্যবহার করে স্থানীয় পরিবর্তনগুলি ছুঁড়ে দেওয়ার জন্য এবং শাখার পরিবর্তে শাখার ব্যবহার করতে পারেন, তবে (1) আইডিইএতে গিট চেকআউট জিইউআই কমান্ড (10.5.1) এটি যে বিকল্প হিসাবে আমরা খুঁজে পেতে পারি তা মনে হয় না, তাই আমাদের নিয়মিত কমান্ড লাইনে যেতে হবে এবং (২) আমরা নিশ্চিত যে এটি ব্যবহার করার অভ্যাসে থাকতে চাই না পতাকা এবং গিটকে আমাদের স্থানীয় পরিবর্তনগুলি ছড়িয়ে দিতে বলছে।

সুতরাং, আমাদের এগুলি মোকাবেলা করতে বিকল্পগুলির সাথে আমাদের কিছু চিন্তাভাবনা রয়েছে:

  1. পুরোপুরি উত্স নিয়ন্ত্রণের বাইরে প্রকল্প ফাইলগুলি নিয়ে যান। এগুলিকে .gitignore এ রাখুন এবং তাদের অন্য কোনও উপায়ে প্রতিটি লোক এবং টিমসিটিতে বিতরণ করুন, সম্ভবত এগুলি অন্য কোথাও বা অন্য নামে উত্স নিয়ন্ত্রণে রেখে। আমাদের দলের পক্ষে যথেষ্ট ছোট এই বিকল্পটি বিবেচনা করার পক্ষে যথেষ্ট সম্ভাব্য, তবে এটি দুর্দান্ত বলে মনে হচ্ছে না।
  2. একটি নির্দিষ্ট সময়ে কোন শাখায় আমাদের কোন ফাইল রয়েছে তা পরিচালনা করার জন্য নিশ্চিত হওয়ার চেষ্টা করে এটির সাথে বসবাস চালিয়ে যান। এর অংশ হিসাবে, আমরা প্রতিটি বিকাশকারীকে তাদের সিস্টেমে প্রতিটি প্রকল্পের একাধিক অনুলিপি রাখতে উত্সাহিত করতে পারি, যাতে তারা প্রত্যেকে পৃথক পৃথক শাখায় প্রকল্প ফাইলের বিভিন্ন সেট দিয়ে পরীক্ষা করে দেখতে পারেন।
  3. উত্স নিয়ন্ত্রণে এবং .gitignore ফাইলে নয় মডিউল (.iml) ফাইলগুলি সহ উত্স নিয়ন্ত্রণে প্রকল্প (.ipr) রাখার চেষ্টা করুন। প্রধান জিনিস যা নিয়মিতভাবে আইপিআর এর নিজস্ব ঘুরে দেখা যায় তা হল ভাগ করা বিল্ড কনফিগারেশনের ক্রম, তবে সম্ভবত সেগুলি কীভাবে সেট আপ করা যায় সে সম্পর্কে আমরা আলাদাভাবে তথ্য ভাগ করতে পারি। আমি পুরোপুরি নিশ্চিত নই যে আইডিইএ কেবল তার কিছু ফাইল রাখার ক্ষেত্রে এই জাতীয় জিনিসটির সাথে কীভাবে আচরণ করে, বিশেষত একটি নতুন চেকআউটে।

আমি অনুমান করি যে আমি আশা করছি যে আমরা কিছু স্পষ্ট (বা অ-সুস্পষ্ট) সমাধান মিস করেছি, সম্ভবত গিট এবং আইডিইএ উভয়ের যে বিশাল কাস্টমাইজিবিলিটি রয়েছে বলে মনে হচ্ছে তা মোকাবিলা করছি। তবে মনে হচ্ছে আমরা সম্ভবত এই সমস্যাযুক্ত একমাত্র দল হতে পারি না। স্ট্যাক ওভারফ্লোতে এই জাতীয় প্রশ্নগুলির মধ্যে 3495191 , 1000512 এবং 3873872 টি অন্তর্ভুক্ত রয়েছে তবে আমি জানি না যে তারা ঠিক একই সমস্যা, এবং সম্ভবত যে কেউ আমার কাছে বিভিন্ন পদ্ধতির জন্য কুফল পেতে পারে বর্ণিত, এই প্রশ্নের উত্তরের তালিকাভুক্ত পন্থাগুলি, বা যেগুলি তারা প্রস্তাব দেয়।



উত্তম বেস হিসাবে gitignore.io নীচে উত্তর দিন। আমি এটিকে দরকারী বলে মনে করি, এমনকি সত্যের তিন বছর পরেও: gitignore.io/api/java,android ,
eclipse

নোট করুন যে IDEA ইস্যুতে youtrack.jetbrains.com/issue/IDEA-64312 ইন্টেলিজ আইডিইএ 14 তে নির্দিষ্ট হিসাবে চিহ্নিত হয়েছে, সুতরাং যেগুলি সর্বশেষ সংস্করণটি ব্যবহার করছে এবং ফাইলগুলি উত্স নিয়ন্ত্রণে রাখতে চায় তারা এখন এর আরও ভাল সময় পেতে পারে আমি এই প্রশ্ন পোস্ট সময় চেয়ে।

উত্তর:


48

আপনি আইডিইএর ডিরেক্টরি -ভিত্তিক প্রকল্প কাঠামো ব্যবহার করতে পারেন , যেখানে সেটিংসগুলি .ipr ফাইলের পরিবর্তে .idea ডিরেক্টরিতে সঞ্চিত থাকে। এটি সংস্করণ নিয়ন্ত্রণে কী সঞ্চিত তা আরও সূক্ষ্ম নিয়ন্ত্রণ দেয় । আইএমএল ফাইলগুলি এখনও প্রায় থাকবে, সুতরাং এটি এলোমেলো পরিবর্তনগুলি সমাধান করতে পারে না (সম্ভবত তাদের উত্স নিয়ন্ত্রণ থেকে দূরে রাখবে?), তবে কোড শৈলী এবং পরিদর্শন প্রোফাইলের মতো জিনিসগুলি ভাগ করা সহজ, যেহেতু তাদের প্রত্যেকটিই হবে .idea ডিরেক্টরিতে নিজের ফাইলটিতে file


ডিরেক্টরি ভিত্তিক কাঠামোতে স্থানান্তরিত স্পষ্টভাবে অনেক সাহায্য করেছিল। আমরা .ml ফাইলগুলি উত্স নিয়ন্ত্রণের বাইরে নিয়ে গিয়েছিলাম, যা প্রথমবারের জন্য যাচাই করার সময় আইডিইএকে কিছুটা বিভ্রান্ত করে তোলে, তবে এটি আপাতত সেরা আপস বলে মনে হয় না। আমাদের মাউন্টেন ফাইল এবং একটি রফতানি পরিদর্শন প্রোফাইলের বাইরেও টিমসিটি পরিদর্শন করা উচিত ছিল, তবে আমরা সেটিও পেয়েছি। ধন্যবাদ!

লিঙ্কটি নষ্ট হয়ে গেছে। আসল সামগ্রীটি কী ছিল তা নিশ্চিত নন, তবে এখানে আইডিইএর প্রকল্প কাঠামোর একটি প্রাসঙ্গিক ডকের লিঙ্ক। এবং এই নির্দিষ্ট সমস্যাটি মোকাবেলা করার জন্য এখানে আরও একটি লিঙ্ক রয়েছে।
বেন .12

31

অফিসিয়াল ডিওসি থেকে: http://devnet.jetbrains.com/docs/DOC-1186

ইন্টেলিজ আইডিইএ প্রকল্প বিন্যাসের উপর নির্ভর করে (.ipr ফাইল ভিত্তিক বা .idea ডিরেক্টরি ভিত্তিক) আপনার নিম্নলিখিত সংস্করণ নিয়ন্ত্রণের অধীনে ইন্টেলিজ আইডিইএ প্রকল্প ফাইলগুলি রাখা উচিত:

.ipr ফাইল ভিত্তিক ফর্ম্যাট

প্রজেক্ট .ipr ফাইল এবং সমস্ত .iml মডিউল ফাইলগুলি ভাগ করুন, .iws ফাইলটি ব্যবহারকারীর নির্দিষ্ট সেটিংস সঞ্চয় করার কারণে ভাগ করবেন না।

.idea ডিরেক্টরি ভিত্তিক ফর্ম্যাট

প্রোজেক্ট রুটে .idea ডিরেক্টরিতে থাকা সমস্ত ফাইলগুলি ওয়ার্কস্পেস.এক্সএমএল এবং Tasks.xML ফাইলগুলি বাদ দিয়ে যা ব্যবহারকারীদের নির্দিষ্ট সেটিংস সঞ্চয় করে, সমস্ত .iml মডিউল ফাইলগুলিও ভাগ করে।

আমি এটি আমার .gitignore এ রেখেছি:

#Project
workspace.xml
tasks.xml

8
হ্যাঁ, এবং আমি প্রশ্নে যেমনটি বলেছি আমরা .আইপি এবং .আইএমএল এবং .iws ভাগ করে নিই। সমস্যাটি হ'ল সমস্যাটি হ'ল youtrack.jetbrains.com/issue/IDEA-64312 যে .iml ফাইলগুলি সর্বদা পরিবর্তিত হয় যা ঘন ঘন বিবাদ সৃষ্টি করে। উত্স নিয়ন্ত্রণের বাইরে থাকা আইআইএমএল ফাইলগুলি রাখা আমাদের পক্ষে আরও ভাল কাজ করে বলে মনে হয়, যেহেতু আইডিইএ এগুলি মাভেন পিওএম থেকে পুনরায় জেনারেট করে, এবং তারপরে তারা অন্যান্য বিকাশকারীদের সাথে দ্বন্দ্ব ছাড়াই স্থানীয়ভাবে পরিবর্তিত হতে পারে। ধন্যবাদ!

এই পদ্ধতির সাথে আমাদের কিছু সংস্থার নাম নিয়ে সমস্যা রয়েছে, উদাহরণস্বরূপ: অ্যান্ড্রয়েড জেডিকে সংস্করণ। আমাদের দলের সদস্যদের কিছুর একটি কনফিগার করা এসডিকে আলাদা আলাদা নাম বা বিভিন্ন সংস্করণ রয়েছে। রেপোতে প্রজেক্ট ফাইলগুলি প্রেরণ করা আপনাকে আপনার দলের সাথে এই জাতীয় জিনিসগুলি সারিবদ্ধ করতে হবে। গতকাল অবধি আমরা রেপোতে প্রজ ফাইলগুলি প্রেরণ করতে ব্যবহৃত হচ্ছিলাম না, তবে এটি আমাদের প্রকল্পটি বড় এবং কনফিগার করার পক্ষে শক্ত হয়ে ওঠে।
ফিলিপ

ব্যবহৃত এসডিকে এবং আপেক্ষিক পাথগুলি
একীকরণ করা

1
হ্যাঁ. এখন আমাদের সমস্ত মডিউলগুলি "প্রজেক্ট এসডিকে" নির্দেশ করে এবং আমরা একই এসডিকে ব্যবহার করতে টিমের সাথে সারিবদ্ধ হন। কমপক্ষে পরিবর্তন করার জন্য কেবলমাত্র এক জায়গা। তবে ইন্টেলিজ এটি আরও ভাল করতে পারে।
ফিলিপ

23

একটি সরকারী উত্তর পাওয়া যায় । ধরে নিচ্ছেন আপনি আধুনিক (এবং এখন ডিফল্ট) .ideaফোল্ডার প্রকল্প ফর্ম্যাটটি ব্যবহার করছেন:

  • সমস্ত কিছু যুক্ত করুন ...
  • ব্যতীত .idea/workspace.xml(যা ব্যবহারকারী-নির্দিষ্ট)
  • ব্যতীত .idea/tasks.xml(যা ব্যবহারকারী-নির্দিষ্ট)
  • পাসওয়ার্ড / কী / ইত্যাদি থাকতে পারে এমন কয়েকটি ফাইল বাদে (বিশদটির জন্য উপরের লিঙ্কটি দেখুন)

এই নমুনা .gitignore ফাইলটি একটি দরকারী রেফারেন্স হতে পারে, যদিও এই প্রবেশাগুলি কেন উপস্থিত হয় তা বোঝার জন্য আপনাকে এখনও উপরের লিঙ্কটি পড়তে হবে এবং আপনার যদি প্রয়োজন হয় কিনা তা সিদ্ধান্ত নিতে হবে।

ব্যক্তিগতভাবে আমি .idea/find.xmlফাইলটিকেও এড়িয়ে যাব কারণ আপনি যখন কোনও অনুসন্ধান অপারেশন করবেন প্রতিবারই এটি পরিবর্তিত হবে বলে মনে হচ্ছে।


1
"নমুনা গিটিগনোর ফাইল" লিঙ্কের উপর ভিত্তি করে, আমি এটিকে আরও একধাপ এগিয়ে নিয়ে যাব এবং আপনি এটি সরবরাহ করে আনন্দিত। ভিত্তিক ঠিকানায় যান এবং আপনি একটি "সম্পূর্ণ" গিটিগনোর পেতে বিভিন্ন ধরণের একত্রিত করতে পারেন। আমার অ্যান্ড্রয়েড প্রজেক্টের জন্য, যা স্পষ্টতই জাভা, অ্যান্ড্রয়েড, এক্লিপস, ইন্টেলিজিজ ব্যবহার করে
WernerCD

16

আমি ওয়ার্কস্পেস.এক্সএমএল উত্স নিয়ন্ত্রণের বাইরে নিয়েছি (+ .gitignore এ যুক্ত)।


10

আমাদের দল পাথ-নির্দিষ্ট ইন্টেলিজি ফাইলগুলি পরীক্ষা করে না। আমরা ধরে নিই যে লোকেরা কীভাবে আইডিই ব্যবহার করতে এবং একটি প্রকল্প স্থাপন করতে জানে। ইন্টেলিজিজ ফাইলগুলি 'উপেক্ষা করা' পরিবর্তন তালিকায় যায়।

হালনাগাদ:

উত্তরটি এখন সহজ যে আমি মাভেন এবং এর ডিফল্ট ডিরেক্টরি কাঠামোটি ব্যবহার করছি।

IntelliJ সব ফাইল উপেক্ষা করতে বলা হবে /.svn, /.ideaএবং /targetফোল্ডার নেই। কোনও ব্যক্তির পাথ সম্পর্কিত তথ্যের সাথে সম্পর্কিত সমস্ত কিছু এতে সঞ্চিত থাকে /.idea

সাবসার্শন বা গিটের প্রতি প্রতিশ্রুতিবদ্ধ থাকার জন্য অন্য সমস্ত কিছুই সুষ্ঠু খেলা।


14
প্রকল্পটি সেট আপ করা কোনও বড় বিষয় নয় কারণ এটি প্রায়শই ঘটে না, তবে স্ক্রিনশটগুলির আশেপাশে বা কোনও কিছু ইমেল না করে বিল্ড কনফিগারেশন এবং পরিদর্শন প্রোফাইলগুলি ভাগ করে নেওয়া খুব সহজ।

1
কোনও ব্যক্তির পথে নির্ভর করে না এমন স্টাফটি পরীক্ষা করে দেখুন।
duffymo

2

আমার দলটি ব্যবহার করেছে এমন অন্য পদ্ধতির ভাগ করে নেওয়ার জন্য: আইডিই সম্পর্কিত যেকোন ফাইলকে অন্য কোনও জায়গায় সরিয়ে ফেলুন যেখানে ইন্টেলিজি স্বীকৃতি দেয় না, এবং জিআইটি দ্বারা উপেক্ষা করা পছন্দসই 'সক্রিয়' অবস্থানে তাদের অনুলিপি করার জন্য একটি স্ক্রিপ্ট তৈরি করুন।

এই পদ্ধতির সুবিধা হ'ল আপনি সংস্করণ নিয়ন্ত্রণের মাধ্যমে আইডিই সেটিংস ভাগ করে নেওয়ার বিকল্পটি রেখেছেন। একমাত্র ত্রুটি আপনাকে স্ক্রিপ্টটি কখন চালাতে হবে তা স্থির করতে হবে (সম্ভবত একবার ওয়ার্কস্পেস ক্লোন প্রতি বা পরিবর্তনগুলি যখন প্রয়োজন হয়), এবং আপনি আপনার বিল্ড প্রক্রিয়াতে বা মার্জ-পরবর্তী হুকটিতে স্ক্রিপ্টটি অন্তর্ভুক্ত করে এটি স্বয়ংক্রিয় করতে পারেন।

এই পদ্ধতির উপর নির্ভর করে যে ইন্টেলিজ তার সেটিং ফাইলগুলির জন্য কেবলমাত্র নির্দিষ্ট অবস্থানগুলি অনুসন্ধান করে, তাই এটি ফ্রেমওয়ার্ক কনফিগারেশন ফাইলগুলির ক্ষেত্রেও প্রযোজ্য। প্রকৃতপক্ষে আমরা গ্রিলস। প্রপার্টি ফাইলগুলি একইভাবে উপেক্ষা করেছি, সুতরাং বিকাশকারীরা দুর্ঘটনাক্রমে তাদের স্থানীয় কনফিগারেশন পরিবর্তনগুলি চেক ইন করবে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.