গিট দিয়ে বড় বাইনারি ফাইল পরিচালনা করা

Question

আমি কীভাবে বড় বাইনারি ফাইলগুলি পরিচালনা করতে পারি তার উপর মতামত সন্ধান করছি যেগুলির উপর আমার উত্স কোড (ওয়েব অ্যাপ্লিকেশন) নির্ভরশীল। আমরা বর্তমানে বেশ কয়েকটি বিকল্প নিয়ে আলোচনা করছি:

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

এ সম্পর্কে আপনার অভিজ্ঞতা / চিন্তাভাবনাগুলি কী?

এছাড়াও: কারও কি একাধিক গিট সংগ্রহস্থল এবং একটি প্রকল্পে এগুলি পরিচালনা করার অভিজ্ঞতা আছে?

ফাইলগুলি এমন কোনও প্রোগ্রামের চিত্র যা এতে সেই ফাইলগুলির সাথে পিডিএফ তৈরি করে। ফাইলগুলি প্রায়শই পরিবর্তন হবে না (বছরের মতো) তবে এগুলি একটি প্রোগ্রামের সাথে খুব প্রাসঙ্গিক। প্রোগ্রামগুলি ফাইল ছাড়া কাজ করবে না।

Comments

যখন বাইনারি ফাইল নিয়ন্ত্রণ করে সংস্করণটি প্রয়োজনীয় তখন কী হবে? আমি সম্পদে কাজ করা শিল্পীদের দলগুলির জন্য চিন্তা করছি।

— ড্যান

যদি এটি প্রয়োজনীয় হয় তবে আপনার যে সুবিধা পাবেন তার বিপরীতে আপনাকে আপনার উপলব্ধ সংস্থানসমূহ (ডিস্ক, ব্যান্ডউইথ, সিপিইউ সময়) ভারসাম্য বজায় রাখতে হবে।

— পাই

নোট করুন যে ফাইল-লকিং ছাড়া গিটটি দুর্দান্ত হয় না যখন একাধিক ব্যক্তির একই বাইনারি ফাইলটিতে কাজ করা দরকার।

— yoyo

আরও দেখুন Git ভিত্তিক ব্যাকআপ ফাইল ইউনিভার্সিটি অব প্রফেশনালস ।

— ভোনসি

এখানে তারা বেসটেকভিডিও

— ট্যাগ /

Answer 1

প্রোগ্রামটি যদি ফাইলগুলি ব্যতীত কাজ না করে তবে মনে হয় এগুলিকে আলাদা রেপিতে বিভক্ত করা খারাপ ধারণা। আমাদের কাছে বড় টেস্ট স্যুট রয়েছে যা আমরা আলাদা একটি রেপোতে বিভক্ত করি তবে সেগুলি সত্যই "সহায়ক" ফাইল are

তবে, আপনি পৃথক রেপোতে ফাইলগুলি পরিচালনা করতে সক্ষম হতে পারেন এবং তারপরে এটিকে git-submoduleবুদ্ধিমান পদ্ধতিতে আপনার প্রকল্পে টানতে ব্যবহার করতে পারেন । সুতরাং, আপনার এখনও আপনার সমস্ত উত্সের সম্পূর্ণ ইতিহাস থাকবে তবে আমি এটি বুঝতে পেরেছি, কেবলমাত্র আপনার চিত্রগুলির সাবমডিউলে একটি প্রাসঙ্গিক সংশোধন থাকতে হবে। এই git-submoduleসুবিধাটি আপনাকে কোডের সঠিক সংস্করণটিকে চিত্রের সঠিক সংস্করণের সাথে সামঞ্জস্য রাখতে সহায়তা করবে।

গিট বুক থেকে সাবমডিউলগুলির জন্য এখানে একটি ভাল পরিচয় ।

Comments

"যেমনটি আমি এটি বুঝতে পেরেছি, আপনার কেবলমাত্র আপনার চিত্রগুলির সাবমডিউলে একটি প্রাসঙ্গিক সংশোধন হবে।" আমি এটি সঠিক মনে করি না।

— রবিন গ্রিন

প্রকৃতপক্ষে. একটি সাবমডিউল হ'ল একটি পূর্ণ গিট সংগ্রহস্থল, যা কেবলমাত্র প্যারেন্ট রিপোজিটরির ভিতরেই বাসা বাঁধে। এটি এর পুরো ইতিহাস জানে। আপনি এতে কম ঘন ঘন প্রতিশ্রুতিবদ্ধ করতে পারেন তবে আপনি যদি পিতা-মাতার কাছে একই জিনিস সংরক্ষণ করেন তবে এতে পিতামাতার একই সমস্যা থাকবে।

— ক্যাস্যাবেল

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

— এএ গ্র্যাপাস 21

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

— zul

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

— মিক্কো রেন্টালাইনেন

Answer 2

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

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

অনেকগুলি কমান্ড উপলব্ধ রয়েছে এবং ওয়েবসাইটে দুর্দান্ত দস্তাবেজ রয়েছে। একটি প্যাকেজ দেবিয়ান এ উপলব্ধ ।

Comments

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

— cdunn2001

তবে, অ্যানেক্স উইন্ডোজ সমর্থন করে না। যা গেম ডেভেলপারদের জন্য সমস্যাযুক্ত।

— এএ গ্র্যাপাস 21

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

— স্যাম ওয়াটকিন্স 15

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

— লরেন্স হলস্ট

আমি এই পৃষ্ঠাটি সন্ধান করেছি । এটি এখন উইন্ডোতেওgit annex উপলব্ধ যে পড়া । যদি কেউ কখনও উইন্ডোজটিতে এটি পরীক্ষা করে দেখে থাকেন তবে আমি তার অভিজ্ঞতা সম্পর্কে শুনতে চাই!

— কাউচি সি নাকামুরা

Answer 3

এপ্রিল ২০১৫ সাল থেকে আর একটি সমাধান হ'ল গিট লার্জ ফাইল স্টোরেজ (এলএফএস) (গিটহাব দ্বারা)।

এটি গিট-এলএফএস ব্যবহার করে ( git-lfs.github.com দেখুন ) এবং এটি সমর্থন করে এমন একটি সার্ভারের সাথে পরীক্ষিত: lfs-test-server :
আপনি কেবল গিট রেপোতে এবং বৃহত ফাইল অন্য কোথাও মেটাডেটা সঞ্চয় করতে পারেন।

Comments

lfs-test-serverউত্পাদন ব্যবহারের জন্য না হিসাবে ঘোষণা করা হয়। আসলে, আমি প্রডাকশন এলএফএস সার্ভারে কাজ করছি ( github.com/artemkin/git-lfs-server )। এটি প্রক্রিয়াধীন, তবে ইতিমধ্যে পরিষেবাযোগ্য এবং আমরা এটি ঘরে বসে পরীক্ষা করছি।

— স্টাস

আপনি কি গিট এলএফএস ব্যবহার করে এই জাতীয় বাইনারি ফাইলের পূর্ববর্তী সংস্করণগুলি চেকআউট করতে পারেন?

— মুচাহো

@ মিউচাহো আপনার উচিত: গিট চেকআউটটির বাক্য গঠনটি অপরিবর্তিত এবং এলএফএস স্মুড স্ক্রিপ্টটি এখনও কল করা উচিত।

— ভোনসি

Answer 4

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

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

আমি আসলে আরও ভাল কম্প্রেশন রেট দেখিনি, তবে আমার সংগ্রহশালাগুলিতে সেগুলিতে সত্যিই বড় বাইনারি নেই।

আপনার মাইলেজ পরিবর্তিত হতে পারে.

Comments

বুপ স্টোরেজ সরবরাহ করে (অভ্যন্তরীণভাবে রিটার্নেন্সির জন্য প্যারিটি আর্কাইভ ব্যবহার করে এবং সংক্ষেপণের জন্য গিট, ডিপআপ এবং ইতিহাস), তবে এটি গিটকে প্রসারিত করে না। গিট-এনেক্স একটি গিট এক্সটেনশন যা একটি বুপ স্টোরেজ ব্যাকএন্ড সরবরাহ করে ।

— টুবু

@Tobu যখন আমি এই পোস্ট, Git অ্যানেক্স এখনো (মূলধারার রিলিজ মধ্যে) উপস্থিত করেনি

— sehe

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

— টুবু

Answer 5

আপনি গিট-ফ্যাটও ব্যবহার করতে পারেন । আমি পছন্দ করি এটি কেবল স্টক পাইথন এবং এর উপর নির্ভর করে rsync। এটি নিম্নলিখিত গিট ওয়ার্কফ্লো সমর্থন করে নিম্নলিখিত স্ব বর্ণনামূলক কমান্ড সহ:

git fat init
git fat push
git fat pull

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

আপনি স্বাভাবিক ব্যবহার করে একটি বাইনারি যুক্ত করেন git add, যা git fatআপনার gitattributes নিয়মের উপর ভিত্তি করে ডাকে ।

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

আপডেট: আপনি গিট-এসভিএন ব্রিজ ব্যবহার করলে গিট ফ্যাট ব্যবহার করবেন না। এটি আপনার সাবভার্সন সংগ্রহশালা থেকে বাইনারি ফাইলগুলি সরিয়ে শেষ করবে। তবে, আপনি যদি খাঁটি গিট সংগ্রহস্থল ব্যবহার করেন তবে এটি সুন্দরভাবে কাজ করে।

Answer 6

আমি সাবমডিউলগুলি (প্যাট নটজ হিসাবে) বা দুটি স্বতন্ত্র ভাণ্ডার ব্যবহার করব। আপনি যদি আপনার বাইনারি ফাইলগুলি প্রায়শই সংশোধন করেন তবে আমি ইতিহাসের পরিষ্কারের বিশাল সংগ্রহস্থলের প্রভাবকে হ্রাস করার চেষ্টা করব:

বেশ কয়েক মাস আগে আমার খুব অনুরূপ সমস্যা হয়েছিল: MP3 ২২ গিগাবাইট এমপি 3 ফাইল, অ-শ্রেণিবদ্ধ (খারাপ নাম, খারাপ আইডি 3 গুলি জানেন না যে আমি এমপি 3 ফাইলটি পছন্দ করি কিনা না ...), এবং তিনটি কম্পিউটারে প্রতিলিপি করা হয়েছে।

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

শেষে, আমার কাছে .git ডিরেক্টরিতে এমপি 3 ফাইল এবং GB 83 গিগাবাইট ফাইল ছিল। পূর্বপুরুষদের প্রতিশ্রুতি না দিয়ে আমি একটি নতুন প্রতিশ্রুতি তৈরি করেছি git-write-treeএবং git-commit-treeসেই প্রতিশ্রুতির প্রতি ইঙ্গিত করে একটি নতুন শাখা শুরু করেছি। এই শাখার জন্য "গিট লগ" কেবল একটি প্রতিশ্রুতি দেখায়।

তারপরে, আমি পুরাতন শাখাটি মুছে ফেলেছি, কেবলমাত্র নতুন শাখা রেখেছি, রেফ-লগগুলি মুছে ফেলেছি এবং "গিট প্রুন" চালাচ্ছি: এর পরে, আমার .git ফোল্ডারগুলি কেবল ~ 6 গিগাবাইট ওজন করেছে ...

আপনি একই সময়ে সময়ে বিশাল সংগ্রহস্থলটিকে "মুছে ফেলতে" পারতেন: আপনার "গিট ক্লোন" এর দ্রুততর হবে।

Comments

আমি একবার অনুরূপ কিছু করেছি যেখানে আমাকে একটি ভান্ডার বিভক্ত করতে হয়েছিল যা আমি ঘটনাক্রমে দুটি স্বতন্ত্র সংশ্লেষে একীভূত করেছিলাম। আকর্ষণীয় ব্যবহারের ধরণ যদিও। :)

— পাই

এটি কি ঠিক যেমন হবে: rm -f .git; git init; গিট অ্যাড ; গিট কমিট-এম "ইতিহাস ট্র্যাশ করুন।"

— প্যাট নটজ

হ্যাঁ, এটি কেবল আমার এমপি 3 ক্ষেত্রে একই। তবে কখনও কখনও আপনি আপনার শাখা এবং ট্যাগগুলি স্পর্শ করতে চান না (পাবলিক সঞ্চিতাগুলিতে কোনও স্থান হ্রাস নয়) তবে আপনি কেবল একটি শাখার "গিট ক্লোন / আনয়ন / টান" গতি বাড়িয়ে তুলতে চান (উত্সর্গীকৃত-এর জন্য কম স্থান) শাখা সংগ্রহস্থল)।

— ড্যানিয়েল ফানজুল

Answer 7

আমি যে সমাধানটি প্রস্তাব করতে চাই তা অনাথ শাখাগুলির উপর ভিত্তি করে এবং ট্যাগ পদ্ধতির সামান্য অপব্যবহারের উপর ভিত্তি করে, এখন থেকে * এতিম ট্যাগ্স বাইনারি স্টোরেজ (ওটিএবিএস) হিসাবে উল্লেখ করা হয়

টিএল; ডিআর 12-01-2017 আপনি যদি গিথুবের এলএফএস বা অন্য কোনও তৃতীয় পক্ষ ব্যবহার করতে পারেন তবে সর্বদা আপনার উচিত। যদি না পারো তবে পড়ুন। সতর্কতা অবলম্বন করুন, এই সমাধানটি একটি হ্যাক এবং এটির মতোই আচরণ করা উচিত।

OTABS এর পছন্দসই বৈশিষ্ট্য

• এটি একটি খাঁটি গিট এবং গিটের একমাত্র সমাধান - এটি কোনও তৃতীয় পক্ষের সফ্টওয়্যার (যেমন গিট-এনেক্স) বা তৃতীয় পক্ষের অবকাঠামো (গিথাবের এলএফএসের মতো) ছাড়াই কাজটি পায়।
• এটি বাইনারি ফাইলগুলি দক্ষতার সাথে সঞ্চয় করে , যেমন এটি আপনার সংগ্রহস্থলের ইতিহাস ফুলে যায় না।
• git pullএবং git fetch, সহ git fetch --allএখনও ব্যান্ডউইথ দক্ষ , যেমন সমস্ত বড় বাইনারি ডিফল্টরূপে দূরবর্তী থেকে টানা হয় না।
• এটি উইন্ডোজে কাজ করে ।
• এটি একক গিট সংগ্রহস্থলগুলিতে সমস্ত কিছু সঞ্চয় করে ।
• এটা জন্য করতে পারবেন মুছে ফেলার পুরানো বাইনেরিতে (অসদৃশ ইউনিভার্সিটি অব প্রফেশনালস) দিয়ে।

OTABS এর অনাকাঙ্ক্ষিত বৈশিষ্ট্য

• এটি git cloneসম্ভাব্যভাবে অদক্ষ করে তোলে (তবে আপনার ব্যবহারের উপর নির্ভর করে প্রয়োজনীয় নয়)। আপনি যদি এই সমাধানটি স্থাপন করেন তবে আপনার সহকর্মীদের git clone -b master --single-branch <url>পরিবর্তে ব্যবহার করার পরামর্শ দিতে হতে পারে git clone। এটি কারণ হ'ল গিট ক্লোনটি ডিফল্টরূপে আক্ষরিক অর্থে পুরো সংগ্রহস্থলকে ক্লোন করে , এমন জিনিসগুলি সহ যা আপনি সাধারণত আপনার ব্যান্ডউইথকে নষ্ট করতে চান না, যেমন অনর্থক কমিটগুলি। এসও 4811434 থেকে নেওয়া ।
• এটি git fetch <remote> --tagsব্যান্ডউইথকে অদক্ষ করে তোলে তবে প্রয়োজনীয় স্টোরেজটি অক্ষম নয়। আপনি সবসময় আপনার সহকর্মীদের এটি ব্যবহার না করার জন্য পরামর্শ দিতে পারেন।
• আপনি git gcআর চান না এমন কোনও ফাইল থেকে আপনার সংগ্রহস্থল পরিষ্কার করার জন্য আপনাকে নিয়মিত একটি কৌশল ব্যবহার করতে হবে।
• এটি বুপ বা গিট-বিগ ফাইলগুলির মতো দক্ষ নয় । তবে আপনি যা করার চেষ্টা করছেন তার জন্য এটি যথাক্রমে আরও উপযুক্ত এবং অফ-শেল্ফটি আরও। আপনি কয়েক হাজার ছোট ফাইল বা গিগা বাইটের পরিসীমা নিয়ে ফাইল নিয়ে সমস্যায় পড়তে পারেন তবে কার্যক্ষেত্রের জন্য পড়ুন।

বাইনারি ফাইল যুক্ত করা হচ্ছে

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

1. একটি নতুন এতিম শাখা তৈরি করুন। git checkout --orphan binaryStuffকৌতুক করবে এটি এমন একটি শাখা তৈরি করে যা অন্য কোনও শাখা থেকে সম্পূর্ণ বিচ্ছিন্ন এবং আপনার এই শাখায় যে প্রথম প্রতিশ্রুতি করা হবে তার কোনও পিতা বা মাতা থাকবে না, এটি এটিকে মূল প্রতিশ্রুতিবদ্ধ করে তুলবে।
2. ব্যবহার করে আপনার সূচকটি পরিষ্কার করুন git rm --cached * .gitignore।
3. দীর্ঘ নিঃশ্বাস নিন এবং ব্যবহার করে পুরো কার্যকারী গাছটি মুছুন rm -fr * .gitignore। অভ্যন্তরীণ .gitডিরেক্টরিটি অচ্ছুত থাকবে, কারণ *ওয়াইল্ডকার্ড এটির সাথে মেলে না।
4. আপনার ভেরিবিগবাইনারি.অ্যাক্সে, বা আপনার হেরেহেভি ডিরেক্টরী / তে অনুলিপি করুন।
5. এটি যুক্ত করুন & এটি প্রতিশ্রুতিবদ্ধ।
6. এখন এটি জটিল হয়ে ওঠে - আপনি যদি এটিকে একটি শাখা হিসাবে দূরবর্তী স্থানে চাপেন তবে আপনার সমস্ত বিকাশকারী পরের বার যখন git fetchতাদের সংযোগ আটকে দেবে তখন এটি ডাউনলোড করবে । আপনি শাখার পরিবর্তে ট্যাগ চাপিয়ে এড়াতে পারবেন। এটি এখনও আপনার সহকর্মীর ব্যান্ডউইথ এবং ফাইলসিস্টেম স্টোরেজকে প্রভাবিত করতে পারে যদি তাদের টাইপ করার অভ্যাস থাকে তবে তারা git fetch <remote> --tagsকাজটি করে দেখুন। এগিয়ে যান এবংgit tag 1.0.0bin
7. আপনার অনাথ ট্যাগ পুশ করুন git push <remote> 1.0.0bin।
8. ঠিক তাই আপনি দুর্ঘটনাক্রমে কখনই আপনার বাইনারি শাখাটি ঠেকান না, আপনি এটি মুছতে পারেন git branch -D binaryStuff। আপনার প্রতিশ্রুতি আবর্জনা সংগ্রহের জন্য চিহ্নিত করা হবে না, কারণ এতিম ট্যাগ এটি নির্দেশ করে 1.0.0binএটিকে বাঁচিয়ে রাখার জন্য যথেষ্ট।

বাইনারি ফাইলটি পরীক্ষা করা হচ্ছে

1. কীভাবে আমি (বা আমার সহকর্মীরা) খুব কার্যকরী ট্রিটিতে খুব বিগবাইনারি.এক্সই পরীক্ষা করে দেখতে পারি? যদি আপনার বর্তমান কার্যকারী শাখা উদাহরণস্বরূপ মাস্টার হয় তবে আপনি সহজভাবে পারেন git checkout 1.0.0bin -- VeryBigBinary.exe।
2. আপনার যদি এতিম ট্যাগ 1.0.0binডাউনলোড না হয় তবে এটি ব্যর্থ হবে, সেক্ষেত্রে আপনাকে git fetch <remote> 1.0.0binআগেই করতে হবে ।
3. আপনি VeryBigBinary.exeনিজের মাস্টারের মধ্যে এটি যুক্ত করতে পারেন .gitignore, যাতে আপনার টিমের কেউই দুর্ঘটনাক্রমে বাইনারি সহ প্রকল্পের মূল ইতিহাসকে কলুষিত না করে।

বাইনারি ফাইল পুরোপুরি মোছা হচ্ছে

আপনি যদি আপনার স্থানীয় সংগ্রহশালা থেকে ওয়েলবিগবাইনারি.এক্সইকে সম্পূর্ণরূপে মুছে ফেলার সিদ্ধান্ত নেন তবে আপনার দূরবর্তী সংগ্রহস্থল এবং আপনার সহকর্মীর সংগ্রহস্থলগুলি আপনি ঠিক করতে পারেন:

1. রিমোটে এতিম ট্যাগ মুছুন git push <remote> :refs/tags/1.0.0bin
2. স্থানীয়ভাবে এতিম ট্যাগটি মুছুন (অন্যান্য সমস্ত অবাস্তব ট্যাগ মুছে ফেলুন) git tag -l | xargs git tag -d && git fetch --tags। সামান্য সংশোধন করে এসও 1841341 থেকে নেওয়া ।
3. স্থানীয়ভাবে আপনার এখন অনর্থিত প্রতিশ্রুতি মুছতে একটি গিট জিসি ট্রিক ব্যবহার করুন। git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"। এটি অন্যান্য সমস্ত অননুমোদিত কমিটগুলি মুছে ফেলবে। এসও 1904860 থেকে নেওয়া
4. সম্ভব হলে রিমোটে গিট জিসি ট্রিকটি পুনরাবৃত্তি করুন। এটি সম্ভব যদি আপনি নিজের সংগ্রহস্থলটিকে স্ব-হোস্টিং করেন এবং কিছু গিট সরবরাহকারী যেমন গিথুব বা কিছু কর্পোরেট পরিবেশে সম্ভব নাও হতে পারে। আপনি যদি এমন কোনও সরবরাহকারীর সাথে হোস্টিং করছেন যা আপনাকে রিমোটটিতে ssh অ্যাক্সেস দেয় না তবে এটি হতে দিন। এটা সম্ভব যে আপনার সরবরাহকারীর অবকাঠামো তাদের নিজস্ব মিষ্টি সময়ে আপনার অরক্ষিত কমিটিকে পরিষ্কার করবে। আপনি যদি কর্পোরেট পরিবেশে থাকেন তবে আপনি প্রতি সপ্তাহে একবারে আপনার রিমোট সংগ্রহ করে ক্রোন জব জঞ্জাল চালানোর জন্য আপনার আইটিকে পরামর্শ দিতে পারেন। ব্যান্ডউইথ এবং স্টোরেজ হিসাবে তারা কী করে বা না তা আপনার দলে কোনও প্রভাব ফেলবে না, যতক্ষণ না আপনি আপনার সহকর্মীদের সর্বদা git clone -b master --single-branch <url>পরিবর্তে পরামর্শ দেবেন git clone।
5. আপনার সমস্ত সহকর্মী যারা পুরানো এতিম ট্যাগগুলি থেকে মুক্তি পেতে চান তাদের কেবলমাত্র 2-3 পদক্ষেপ প্রয়োগ করতে হবে।
6. তারপরে আপনি নতুন এতিম ট্যাগ তৈরি করতে বাইনারি ফাইল যুক্ত করার 1-8 পদক্ষেপটি পুনরাবৃত্তি করতে পারেন 2.0.0bin। আপনার সহকর্মীরা টাইপ করার বিষয়ে যদি আপনি চিন্তিত হন তবে আপনি git fetch <remote> --tagsএটির নতুন নাম দিতে পারেন 1.0.0bin। এটি নিশ্চিত করবে যে পরের বার তারা পুরানো সমস্ত ট্যাগ 1.0.0binআনবে এবং পরবর্তী আবর্জনা সংগ্রহের জন্য (পদক্ষেপ 3 ব্যবহার করে) নির্লিপ্ত হবে এবং চিহ্নিত হবে। আপনি যখন রিমোটে কোনও ট্যাগ ওভাররাইট করার চেষ্টা করেন তখন আপনাকে এই জাতীয় ব্যবহার করতে হবে -f:git push -f <remote> <tagname>

উত্তরভাষ

• OTABS আপনার মাস্টার বা অন্য কোনও উত্স কোড / বিকাশ শাখাগুলি স্পর্শ করে না। প্রতিশ্রুতিবদ্ধ হ্যাশগুলি, সমস্ত ইতিহাস এবং এই শাখাগুলির ছোট আকার অকার্যকর। আপনি যদি ইতিমধ্যে বাইনারি ফাইলগুলির সাথে আপনার উত্স কোডের ইতিহাসটি স্ফীত করে থাকেন তবে আপনাকে এটিকে আলাদা আলাদা কাজের অংশ হিসাবে পরিষ্কার করতে হবে। এই স্ক্রিপ্ট দরকারী হতে পারে।

• উইন্ডোতে গিট-ব্যাশ দিয়ে কাজ করার বিষয়টি নিশ্চিত করেছেন।

• বাইনারি ফাইলগুলির স্টোরেজ আরও দক্ষ করার জন্য স্ট্যান্ডার্ড ট্রিকসের একটি সেট প্রয়োগ করা ভাল ধারণা । ঘন ঘন চালানো git gc(কোনও অতিরিক্ত যুক্তি ছাড়াই) বাইনারি ডেল্টাস ব্যবহার করে গিটকে আপনার ফাইলগুলির অন্তর্নিহিত স্টোরেজটিকে অনুকূল করে তোলে। তবে, যদি আপনার ফাইলগুলি প্রতিশ্রুতিবদ্ধ হতে প্রতিশ্রুতি থেকে একই রকমের থাকার সম্ভাবনা না থাকে তবে আপনি বাইনারি ডেল্টাস পুরোপুরি স্যুইচ করতে পারেন। অতিরিক্তভাবে, কারণ ইতোমধ্যে সঙ্কুচিত বা এনক্রিপ্ট করা ফাইলগুলি .zip, .jpg বা .crypt এর মতো সংকোচনের কোনও ধারণা নেই, গিট আপনাকে অন্তর্নিহিত স্টোরেজটির সংক্ষেপণটি স্যুইচ করতে দেয়। দুর্ভাগ্যক্রমে এটি আপনার উত্স কোডকেও প্রভাবিত করে এমন একটি অল-অ-কিছুই সেটিং।

• দ্রুত ব্যবহারের অনুমতি দেওয়ার জন্য আপনি OTABS এর অংশগুলি স্ক্রিপ্ট করতে চাইতে পারেন। বিশেষত, গিটার হুকের মধ্যে বাইনারি ফাইলগুলি সম্পূর্ণরূপে মুছে ফেলা থেকে 2-3 পদক্ষেপগুলি স্ক্রিপ্ট updateকরা গিট আনতে বাধ্যকারী তবে সম্ভবত বিপজ্জনক শব্দার্থক পদার্থ দিতে পারে ("পুরানো সমস্ত কিছু আনতে এবং মুছে ফেলতে")।

• কেন্দ্রীয় সংগ্রহস্থল ব্লাটের বিনিময়ে রিমোটে সমস্ত বাইনারি পরিবর্তনের পুরো ইতিহাস রাখতে আপনি সম্পূর্ণ বাইনারি ফাইলগুলি মুছে ফেলার 4 ধাপটি এড়িয়ে যেতে চাইতে পারেন । স্থানীয় সংগ্রহস্থলগুলি সময়ের সাথে সাথে দুর্বল থাকবে।

• জাভা বিশ্বে এই maven --offlineসংস্করণটিকে আপনার সংস্করণ নিয়ন্ত্রণে সম্পূর্ণরূপে সঞ্চিত পুনরুত্পাদনযোগ্য অফলাইন বিল্ড তৈরির সাথে একত্রিত করা সম্ভব (গ্রেডের তুলনায় এটি ম্যাভেনের সাথে সহজ)। Golang বিশ্বে এটা পরিবর্তে আপনার GOPATH পরিচালনা করতে এই সমাধানে গড়ে তুলতে সম্ভবপর হয় go get। অজগর বিশ্বে স্ক্র্যাচ থেকে প্রতিটি বিল্ডের জন্য পিপিআই সার্ভারের উপর নির্ভর না করে স্বতঃস্ফূর্ত বিকাশ পরিবেশ তৈরি করতে এইটিকে ভার্চুয়ালেনভের সাথে একত্রিত করা সম্ভব।

• আপনার বাইনারি ফাইল খুব প্রায়ই পরিবর্তন করেন তাহলে বিল্ড নিদর্শন মতো, এটা স্ক্রিপ্ট একটি সমাধান যা সঞ্চয় হস্তনির্মিত 5 টি সাম্প্রতিকতম সংস্করণ অনাথ ট্যাগ করে নেওয়া ভালো হতে পারে monday_bin, tuesday_bin, ..., friday_binপ্রতিটি মুক্তির জন্য, এবং এছাড়াও একটি অনাথ ট্যাগ 1.7.8bin 2.0.0bin, ইত্যাদি। আপনি ঘোরান weekday_binএবং প্রতিদিন পুরানো বাইনারি মুছতে পারেন । এইভাবে আপনি দুটি বিশ্বের সেরা অর্জন করুন: আপনি আপনার উত্স কোডের পুরো ইতিহাসটি রাখেন তবে কেবল আপনার বাইনারি নির্ভরতার প্রাসঙ্গিক ইতিহাস। সমস্ত ইতিহাসের সাথে পুরো উত্স কোড না পেয়ে কোনও প্রদত্ত ট্যাগের জন্য বাইনারি ফাইলগুলি পাওয়া খুব সহজ : git init && git remote add <name> <url> && git fetch <name> <tag>আপনার জন্য এটি করা উচিত।

Comments

"আপনাকে পর্যায়ক্রমে ব্যবহার করতে হবে git gc" - ঠিক সেখানে পড়া বন্ধ করে দেওয়া হয়েছে। কেন কেউ হ্যাকের পক্ষে তাদের শেষ সুরক্ষা বেল্ট ছেড়ে দেবে?

— ব্যবহারকারী1643723

@ user1643723 git gcচালানো নিরাপদ নয়। আপনার সমস্ত ঝুঁকিপূর্ণ প্রতিশ্রুতিগুলি ডিফল্টরূপে কমপক্ষে 30 দিনের জন্য হার্ড ড্রাইভে নিরাপদে রাখা হবে: git-scm.com/docs/git-gc

— অ্যাডাম কুরকিউজিক

বিস্তারিত লেখার জন্য ধন্যবাদ। আমি আমার গিটহাব রেপোতে কিছু বাইনারি নির্ভরতাগুলি এমনভাবে সংরক্ষণ করার উপায় হিসাবে চেষ্টা করতে চেয়েছিলাম যে যখন কেউ রেপো ক্লোন করেন তখন সেগুলি ডিফল্টরূপে ডাউনলোড হয় না, তবে ম্যানুয়ালি ডাউনলোড করা যায় এবং স্থানীয় রেপো আপডেট করা যায়। তবে, এই পদক্ষেপে আমি একটি ত্রুটি পেয়েছি: git push <remote> 1.0.0bin- remote: error: GH001: Large files detected. You may want to try Git Large File Storage। দেখে মনে হচ্ছে সম্ভবত গিটহাব আর এটিকে সমর্থন করছে না? প্রশ্নযুক্ত বাইনারি আকারে 100MB ছিল।

— ব্যবহারকারী5359531

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

— অ্যাডাম কুর্কিউইচজ

এই সমাধানটি আসলে কীভাবে হ্যাকি রয়েছে সে সম্পর্কে আরও পরিষ্কার হওয়ার জন্য আমি উত্তরও আপডেট করেছি।

— অ্যাডাম কুরকিউইচ

Answer 8

আমার মতে, আপনি যদি সম্ভবত এই বড় ফাইলগুলিকে প্রায়শই সংশোধন করতে পারেন, বা যদি আপনি অনেকগুলি তৈরি করতে চান git cloneবা করেন git checkoutতবে আপনার আরও একটি গিট সংগ্রহস্থল (বা সম্ভবত সেই ফাইলগুলি অ্যাক্সেস করার অন্য কোনও উপায়) ব্যবহার করার বিষয়ে গুরুত্ব সহকারে বিবেচনা করা উচিত।

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

Comments

এবং, আলাদা রেপো চেকআউট সময়কে আরও খাটো করে তুলবে না, যেহেতু আপনাকে এখনও উভয় রেপো দেখতে হবে!

— এমিল সিট

আপনি যদি "বাইনারি রেপো" এর ইতিহাসটি অবিচ্ছিন্নভাবে পরিষ্কার করেন তবে এমিলসিট পৃথক রেপো চেকআউটটিকে আরও দীর্ঘ করতে পারে। তবুও ডিভস প্রতিবারই দু'দিকের রেপ চেকআউট করতে বাধ্য হবে না ।

— ফ্যাবিয়ানআন্ড্রে

কেন কেবল মূল মডিউলের বিল্ড স্ক্রিপ্টই দ্বিতীয় রেপো থেকে বাইনারি ফাইলগুলি আনতে পারে না, সেগুলি একে একে একে বের করা হয় (যেমন: এখানে স্ট্যাকওভারফ্লো / সেকশনস / ১১২৫৪76//২ )।

— akauppi

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

— টিমো রেইমান

Answer 9

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

ডকুমেন্টেশনের জন্য আমাকে ভার্শনিং সিস্টেমের বিষয়ে সিদ্ধান্ত নিতে হয়েছিল (জেপিইজি ফাইল, পিডিএফ ফাইল এবং .odt ফাইল)। আমি মাত্র একটি জেপিজি ফাইল যুক্ত করে চারবার 90 ডিগ্রি ঘোরানোর (বাইনারি ডেল্টাসের কার্যকারিতা পরীক্ষা করার জন্য) পরীক্ষা করেছি। গিটের সংগ্রহস্থল 400% বৃদ্ধি পেয়েছে। এসভিএন এর সংগ্রহস্থল কেবল 11% বৃদ্ধি পেয়েছে।

সুতরাং দেখে মনে হচ্ছে বাইনারি ফাইলগুলির সাথে এসভিএন অনেক বেশি দক্ষ।

সুতরাং আমার পছন্দটি হ'ল সোর্স কোডের জন্য গিট এবং ডকুমেন্টেশনের মতো বাইনারি ফাইলগুলির জন্য এসভিএন।

Comments

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

— নাইটিঙ্গেল

@ জ্পিয়ারসন আমি একটি খালি গিট সংগ্রহস্থল তৈরি করেছি এবং M১ এমবি আকারের একটি সম্পূর্ণ সাদা বিএমপি চিত্র যুক্ত করেছি (এবং প্রতিশ্রুতিবদ্ধ) যার ফলে 328KB আকারের মোট গিট সংগ্রহস্থল তৈরি হয়েছিল। পরে git gcমোট Git সংগ্রহস্থলের আকার 184KB কমে যায়নি। তারপরে আমি সাদা থেকে কালোতে একটি একক পিক্সেল পরিবর্তন করেছি এবং এই পরিবর্তনটি প্রতিশ্রুতিবদ্ধ করেছি, মোট গিট সংগ্রহস্থলের আকার 388KB এ বৃদ্ধি পেয়েছে এবং মোট গিট সংগ্রহস্থলের আকার 184KB এ নামিয়ে git gcআনা হয়েছিল। এটি দেখায় যে গিটার বাইনারি ফাইলগুলির ডেল্টা সংকোচনে ও সন্ধান করতে বেশ ভাল।

— টেডার

@ জপিয়ারসন একটি সিডনোট: আমি কেবল বাইনারি ডেল্টাসে মন্তব্য করেছি। যদি এটি বৃহত (জিবি আকার) ফাইলের সাহায্যে সংগ্রহস্থল পরিচালনা করে তবে গিট আপনার সমস্ত স্মৃতি খাবে এবং অদলবদল করবে। এর জন্য, গিট-এনেক্স ব্যবহার করুন (ইতিমধ্যে অন্য উত্তরে উল্লিখিত) ...

— টেডার

@ জনডভোরাক - কেউই এটি উল্লেখ করেনি, কারণ এটি সম্পূর্ণ অসত্য। সাবভার্সন কপিগুলি সস্তার - পৃষ্ঠার মাঝামাঝি প্রায় - svnbook.red-bean.com/en/1.7/svn.branchorses.using.html ।

— জোরিস টিমারম্যানস

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

— ইমন নেরবোন

Answer 10

git clone --filter গিট 2.19 + অগভীর ক্লোন থেকে

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

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

এটির সাহায্যে আমরা প্রথমে একটি অগভীর ক্লোন করতে পেরেছিলাম এবং তারপরে প্রতিটি ধরণের বিল্ডের জন্য বিল্ড সিস্টেমটি নিয়ে যা ব্লবগুলি স্বয়ংক্রিয়ভাবে ব্যবহার করতে পারি।

ইতিমধ্যে এমন একটি রয়েছে --filter=blob:limit<size>যা সর্বাধিক ব্লবের আকার আনতে সীমাবদ্ধ করে।

বৈশিষ্ট্যটি দেখতে কেমন লাগে তার একটি ন্যূনতম বিস্তারিত উদাহরণ আমি দিয়েছি : আমি কীভাবে কেবল গিট সংগ্রহস্থলের একটি উপ-ডিরেক্টরিকে ক্লোন করব?

Answer 11

আমি কীভাবে বড় বাইনারি ফাইলগুলি পরিচালনা করতে পারি তার উপর মতামত সন্ধান করছি যেগুলির উপর আমার উত্স কোড (ওয়েব অ্যাপ্লিকেশন) নির্ভরশীল। এ সম্পর্কে আপনার অভিজ্ঞতা / চিন্তাভাবনাগুলি কী?

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

একাধিক গিট সংগ্রহস্থল এবং একটি প্রকল্পে সেগুলি পরিচালনা করার অভিজ্ঞতা কি কারও আছে?

হ্যাঁ. হুগো থিমগুলি প্রাথমিকভাবে এইভাবে পরিচালিত হয়। এটি কিছুটা কচি, তবে কাজটি হয়ে যায়।

---

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

অতিরিক্ত বিকল্পগুলি বিবেচনা করার জন্য মিনিও এবং এস 3 সেমিডি অন্তর্ভুক্ত রয়েছে ।

Answer 12

কটাক্ষপাত আছে camlistore । এটি আসলে গিট-ভিত্তিক নয়, তবে আপনাকে যা করতে হবে তার জন্য আমি এটি আরও উপযুক্ত বলে মনে করি।