একাধিক প্রকল্প সহ সার্ভারের জন্য জিআইটি সংগ্রহস্থল বিন্যাস

Question 1

আমার সাবভারশনটি সেট আপ করার পদ্ধতি সম্পর্কে আমার পছন্দের একটি হ'ল আমি একাধিক প্রকল্পের সাথে একটি একক মূল সংগ্রহস্থল রাখতে পারি। আমি যখন কোনও প্রকল্পে কাজ করতে চাই তখন আমি কেবল সেই প্রকল্পটি দেখতে পারি। এটার মত

\main
    \ProductA
    \ProductB
    \Shared

তারপর

svn checkout http://.../main/ProductA

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

প্রতিটি পণ্যের জন্য একটি পৃথক প্রকল্প সেট আপ করুন।
একটি একক বিশাল প্রকল্প সেট আপ করুন এবং সাব ফোল্ডারে পণ্য সংরক্ষণ করুন।

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

আমি ভাবতে পারি যে লিনাক্স কার্নেল প্রকল্পের সংগ্রহস্থলগুলি সমানভাবে বড় তাই গিটের সাথে এটি পরিচালনা করার উপযুক্ত উপায় থাকতে হবে তবে আমি এখনও এটি আবিষ্কার করতে পারি নি।

খুব বড় একাধিক-প্রকল্পের সংগ্রহস্থলগুলির সাথে কাজ করার জন্য কোনও গাইডলাইন বা সেরা অনুশীলন রয়েছে?

Question 2

গিট সীমাবদ্ধতার ক্ষেত্রে গাইডলাইনটি সহজ :

প্রকল্পের জন্য একটি রেপো
সাবমডিউলগুলি সহ একটি মূল প্রকল্প ।

ধারণা দোকান থেকে নয় সবকিছু এক দৈত্য Git রেপো তে, কিন্তু একটি প্রধান প্রকল্পের, অন্যান্য Repos ডান করে, প্রতিটি এক একটি প্রকল্প বা তার নিজস্ব সাধারণ উপাদান প্রতিনিধিত্বমূলক রেফারেন্স করবে একটি ছোট রেপো নির্মাণ।

ওপি পল আলেকজান্ডার মন্তব্য :

এটি subversion দ্বারা সরবরাহিত "বহিরাগত" সমর্থনের অনুরূপ বলে মনে হচ্ছে।
আমরা এটি চেষ্টা করে দেখেছি এবং একে অপরের উপর নির্ভরশীলতার সাথে প্রকল্পগুলি একযোগে বিকাশিত হওয়ায় বহিরাগতগুলিতে সংস্করণ উল্লেখগুলি ক্রমাগত আপডেট করা অত্যন্ত জটিল বলে মনে হয়েছে। অন্য কোন বিকল্প আছে কি ??

@ পল: হ্যাঁ, মূল প্রকল্প থেকে সংস্করণটি আপডেট করার পরিবর্তে আপনিও:

মূল প্রকল্পের মধ্যে থেকে সরাসরি আপনার উপ-প্রকল্পগুলি বিকাশ করুন (" প্রকৃত প্রকৃতির প্রকোষ্ঠে বর্ণিত "),
বা আপনি কোনও সাব-রেপোতে রেফারেন্স originকরে একই সাব-রেপো অন্যত্র বিকশিত হওয়ার দিকে: সেখান থেকে আপনাকে কেবল সেই সাব-রেপো থেকে অন্যত্র করা পরিবর্তনগুলি টানতে হবে।

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

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

আমি উত্তর দিলাম:

সত্যিই, আপনি হয়ত ঠিক বলেছেন ... এটি সর্বশেষ গিট প্রকাশের 1.7.1 অবধি রয়েছে ।
git diffএবং git statusউভয়ই মূল প্রকল্প থেকে মৃত্যুদন্ড কার্যকর করা হলেও সাব-মডিউলগুলিতে অ্যাকাউন্টে নিতে শিখেছে।
আপনি কেবলমাত্র সাবমডিউল পরিবর্তনটি মিস করতে পারবেন না।

বলা হচ্ছে যে:

সাবমোডিউলগুলি এসভিএন এক্সটার্নাল থেকে আলাদা: দেখুন " গিট সাবমোডিয়াল এসএনএন এক্সটার্নালগুলির সাথে কেন বেমানান? "
সাবমডিউলগুলি পরিচালনা করা জটিল হতে পারে: দেখুন " গিট সাবমডিউলটি ঠিক কীভাবে কাজ করে? "

Question 3

গিটস্লেভ আপনাকে এক হিসাবে বেশ কয়েকটি স্বতন্ত্র রেপো পরিচালনা করতে দেয়। প্রতিটি রেপো নিয়মিত গিট কমান্ড দ্বারা পরিচালিত হতে পারে, যখন গিটস্লাভ আপনাকে সমস্ত রেপোর উপরে একটি কমান্ড চালানোর অনুমতি দেয়।

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

প্রতি-প্রকল্পে রেপোতে সামঞ্জস্যের সুবিধা রয়েছে এবং মাভেনের মতো সরঞ্জামগুলির সাথে সরলিকৃত বিল্ড রয়েছে। প্রতি-প্রোজেক্টে বিকাশকারী ভ্রান্ত আচরণের ক্ষেত্রে - বিকাশকারী কী পরিবর্তন করছে তার সুযোগকে সীমাবদ্ধ করে সুরক্ষা যুক্ত করে।