क्या छवियों को जीआईटी भंडार में संग्रहीत किया जाना चाहिए?

200

संस्करण नियंत्रण के रूप में Git और Github का उपयोग करने वाली एक वितरित टीम के लिए, छवियों को git रिपॉजिटरी में भी संग्रहीत किया जाना चाहिए?

अधिकांश भाग के लिए, चित्र नहीं बदले जाएंगे। चित्र युक्त होते ही उनका फ़ोल्डर आकार में बड़ा हो जाएगा। एक चिंता यह है कि बड़ी छवियों के संयोजन से छवि फ़ोल्डर समय के साथ बड़े आकार में विकसित हो सकता है, या बस उनमें से बहुत से।

क्या यह सबसे अच्छा अभ्यास माना जाता है? परियोजनाओं में आवश्यक बाइनरी फ़ाइलों को साझा करने के लिए अन्य विकल्प क्या हैं जो एक वितरित टीम आसानी से एक्सेस कर सकती है?

version-control git github

— spong
स्रोत

17

जब आप कहते हैं कि "चित्र" हम 26mb DSLR रॉ फाइल, 1mb 3 डी गेम टेक्स्ट या <100k png आइकॉन के बारे में बात कर रहे हैं? (मैं जवाब देने जा रहा था "यह निर्भर करता है" लेकिन मैं मना करूंगा)

— ब्रुक

2

@ बरोक: मुझे लगता है कि हम वेबसाइटों के लिए आइकन या छोटे ग्राफिक तत्वों की बात कर रहे थे। खेल की बनावट, ग्राफिक डिजाइन कच्ची फाइलें या प्रलेखन संपादन के लिए सटीक ग्राफिक्स एक अलग कहानी हो सकती है, आप सही हैं।

— जाइलम

6

मुझे व्यक्तिगत रूप से लगा कि उनका मतलब आईएसओ इमेज है, न कि तस्वीरें।

— महमूद होसम

2

यह वास्तव में छोटे / मध्यम आकार की वेब-अनुकूल छवियों के लिए होना चाहिए। एक चिंता यह है कि कुछ देव-हस्ताक्षरकर्ता वहां हर बड़ी मूल छवि को चिपकाना शुरू कर देंगे, जब मैं सोच रहा हूं कि शायद कुछ और उपयोग करना चाहिए।

— spong

6

आज इस सवाल को पढ़ना? नीचे दिए गए जवाब को git lfs पर देखें। यह शायद आप चाहते हैं। programmers.stackexchange.com/a/306882/92506

— jonnybot

188

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

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

मैंने एक पूरी परियोजना की मूल कलाकृति को "पूफ" जाना देखा, जब ग्राफिक्स डिजाइनर की मैकबुक हार्ड ड्राइव की मृत्यु हो गई, सभी क्योंकि किसी ने, अनंत ज्ञान के साथ, निर्णय लिया कि "बायनेरिज़ रिवर्स कंट्रोल में नहीं है", और ग्राफिक्स डिजाइनर (कम से कम यह एक है) ) बैकअप के साथ अच्छा नहीं है।

किसी भी और सभी बाइनरी फ़ाइलों पर लागू होता है जो उपरोक्त मानदंडों को फिट करते हैं।

एकमात्र कारण डिस्क स्थान नहीं है। मैं $ 100 / टेराबाइट से डरता हूं, वह बहाना थोड़ा पतला है।

— mattnz
स्रोत

44

BTW: इंटरनेट एक विश्वसनीय स्रोत नहीं है। यदि आपने "bobsfreestuff.com" से कोई चित्र डाउनलोड किया है, तो यह संभवत: अगले सप्ताह नहीं होगा।

— मटनज़

16

+1 - और + अधिक होना चाहिए। संस्करण नियंत्रण की बात यह है कि आपको जो भी सामान हो सकता है, उसे वापस लाने / रोल करने की अनुमति दें, जो कुछ भी हो सकता है। 100% होने का एकमात्र तरीका है कि आप उस समय वापस प्राप्त कर सकते हैं जो उस समय होना चाहिए था जब संस्करण नियंत्रण के लिए हर जगह रखा जाए। Thats स्रोत, चित्र, resouces, सहायक / PDF का समर्थन। हेक, मैंने ज़िप्ड सीडी इमेज भी डाल दी। मुझे एक वीएम वर्चुअल मशीन (वीएमडीके सहित) को सोर्स कंट्रोल में रखने के लिए भी जाना जाता है। चरम लगता है? मेरे बेकन को 2 साल बाद बचा लिया।

— जल्दी से_जुन 2’11

3

100% सहमत हैं। यदि छवियां सॉफ़्टवेयर का हिस्सा हैं, तो उन्हें नियंत्रित नियंत्रण की आवश्यकता है।

— डीन हार्डिंग

14

एकमात्र कारण मैं असहमत होगा अगर यह आपके रेपो को उस बिंदु पर क्लोन करने के लिए बोझिल बना देता है जहां डेवलपर्स को वास्तव में सोचना था "क्या मैं वास्तव में इस क्लोन करने के लिए समय निकालना चाहता हूं, या क्या मैं इस अन्य शाखा में एक्स कर सकता हूं"। यदि ऐसा होता है तो सुनिश्चित करें कि चीजें बहुत जल्दी फिर से व्यवस्थित हो जाएं

— ब्रुक

5

इसे तैनात करने की आवश्यकता के बारे में बात के लिए +1। अगर मैं आपका रेपो क्लोन करता हूं, क्योंकि मैं एक नया टीम का सदस्य या कुछ और हूं, तो इसे बॉक्स से बाहर काम करना चाहिए । यदि आवश्यक हो तो आवश्यक 3 पार्टी पुस्तकालयों को प्राप्त करने के लिए एक मेकफाइल बराबर चतुर होना शामिल है।

— स्पेंसर रथबुन

66

क्यों नहीं? :)

स्टोरिंग बायनेरी को बुरा अभ्यास माना जाता है, हां, लेकिन मैंने कभी भी छवियों के बारे में बहुत अधिक चिंता नहीं की।

सबसे खराब स्थिति, अगर आपके पास टन है, तो उन्हें कहीं और स्टोर करें या एक्सटर्नल का उपयोग करें या बाइनरी सपोर्ट के लिए एक्सटेंशन का उपयोग करें। और अगर छवियों को अक्सर बदला नहीं जाएगा, तो समस्या कहां है? आप एक बड़ा वसा डेल्टा नहीं मिलेगा। और अगर वे समय के साथ हटाए जाते हैं, तो यह केवल आपका सर्वर है जो इतिहास को संग्रहीत करने से थोड़ा ग्रस्त है, लेकिन क्लाइंट एक चीज नहीं देखेंगे।

मेरी राय में, आपको इसके बारे में चिंता नहीं करनी चाहिए - दी गई है कि आप उन लोगों के जीबी स्टोर नहीं करते हैं।

हालांकि आप क्या कर सकते हैं, केवल "स्रोत" छवियां संग्रहीत करें: SVGs, LaTeX मैक्रोज़, आदि ... और आपके निर्माण सिस्टम द्वारा उत्पन्न अंतिम छवियां हैं। यदि आप कर सकते हैं तो यह शायद और भी बेहतर है। यदि नहीं, तो परेशान मत करो।

(यह सब कहा जा रहा है, Git पाठ फ़ाइलों के लिए चमकता है, लेकिन चित्रों के लिए सबसे अच्छा VCS नहीं है। यदि आप कर सकते हैं तो हमें अधिक संदर्भ और मीट्रिक दें)

अतिरिक्त जानकारी के लिए, आप इन प्रश्नोत्तरों को देखना चाहते हैं:

— haylem
स्रोत

4

स्रोत को संग्रहीत करने के लिए +1, लेकिन यदि वे पूर्ण निर्माण के बिना विकास परीक्षण कर सकते हैं तो इससे गड़बड़ हो सकती है। इसका मतलब यह भी है कि आपको सुबह काम शुरू करने से पहले सभी छवियों का निर्माण करना होगा

— TheLQ

@ TheLQ: मुझे लगता है, लेकिन तब शायद आपको कैस्केडिंग बिल्ड चाहिए, जहां आपके डाउनस्ट्रीम (परीक्षण) बिल्ड केवल अपस्ट्रीम बिल्ड (वास्तविक बिल्ड) पर भरोसा कर सकते हैं। और फिर इन्हें स्थानीय स्तर पर परीक्षकों द्वारा फिर से उपयोग के लिए एक सार्वजनिक फ़ोल्डर में निर्यात करें। इसका मतलब है कि बुनियादी ढांचे का थोड़ा सा, स्पष्ट रूप से, लेकिन यह एक अपेक्षाकृत बड़े आकार की टीम में काम करने का मेरा तरीका होगा।

— जाइलम

बायनेरिज़ क्या हैं?

— डैनियल पेन्डगैस्ट

1

@ डेंटमैन: en.wikipedia.org/wiki/Binary_file

— haylem

5

"क्यों नहीं?" - क्योंकि यदि आपका रेपो 2GB से अधिक है, तो बिटकॉइन (और मैंने इसे केवल Github के साथ भी आज़माया है) आपके रेपो को अस्वीकार कर देगा। तो अगर आप उन्हें छवियों के टन के साथ ब्लोट होस्ट करने के लिए तैयार हैं।

— Jez

48

यह प्रश्न बहुत पुराना है, लेकिन यह एक सामान्य प्रश्न है जो Git से निपटने के दौरान आता है और अंतिम उत्तर के बाद से Git रेपो में बड़ी फ़ाइलों को संग्रहीत करने के आधुनिक समाधानों पर कुछ प्रगति हुई है।

Git में बड़ी फ़ाइलों को संग्रहीत करने के लिए निम्नलिखित परियोजनाएँ हैं:

git-annex - यह थोड़ी देर के लिए चारों ओर रहा है लेकिन स्पष्ट रूप से यह जटिलता रास्ते में हो जाता है।
git-media - इस एक के साथ कोई व्यक्तिगत अनुभव नहीं। साथ ही काफी जटिल लगता है।
git-fit - एक सरल प्लगइन बनाने का प्रयास। S3 भंडारण की आवश्यकता है। जबकि मैं सादगी की सराहना करता हूं कि प्लगइन के साथ मेरी मुख्य चिंता यह है कि यह काफी अज्ञात है और इसे 1 व्यक्ति द्वारा बनाए रखा गया है (पूर्ण प्रकटीकरण, मैं इस समय केवल अन्य कमिटेटर हूं और यह एक तुच्छ मुद्दे के लिए था)।
git-lfs - जबकि मैंने इसका बड़े पैमाने पर उपयोग नहीं किया है, यह पवित्र ग्रिल प्रतीत होता है। यह Github द्वारा समर्थित है और अक्टूबर 2015 तक उनके सभी रिपॉज पर उपलब्ध है और रेपो को संग्रहीत करने वाली साइट पर फ़ाइल प्रबंधन की जटिलता डालता है। केवल नकारात्मक पक्ष यह है कि यह काफी नया है, इसलिए गितुब से परे बहुत समर्थन नहीं है, हालांकि गिटलैब का भी समर्थन है , जैसा कि गिटिया और बिटबकेट ने भविष्य में समर्थन करने के लिए किया है ।

TLDR: यदि आप कर सकते हैं, git-lfs का उपयोग git में चित्र या अन्य बाइनरी फ़ाइलों को संग्रहीत करने के लिए करें।

— जेम्स मैकमोहन
स्रोत

9

पहली बार एक लंबे समय के लिए, मुझे खुशी है कि मैंने कम-वोट वाले उत्तरों को पढ़ने के लिए नीचे स्क्रॉल किया। git lfs ठीक वही है जो मैं चाहता हूं, और एटलसियन ने बिटबकेट सर्वर को इसके लिए समर्थन भी जोड़ा है ! अगर मैं इसे एक लाख बार बढ़ा सकता हूं, तो मैं करूंगा।

— jonnybot

7

@ जॉनीबॉट, धन्यवाद। मैं एक देर से जवाब था इसलिए मैंने बहुत अधिक दृश्यता नहीं प्राप्त की है, लेकिन गिट-एलएफ़एस का उपयोग करने के बाद यह लगता है कि यह गिट में बाइनरी फ़ाइलों को संग्रहीत करने के लिए सबसे अच्छा वर्तमान समाधान है।

— जेम्स मैकमोहन

45

संपूर्ण "बायनेरी को स्रोत नियंत्रण में संग्रहीत नहीं करता है" एक विशिष्ट कारण के लिए निर्धारित है: यदि आपके पास स्रोत कोड है जो संकलित करता है, तो वास्तविक संकलन को संग्रहीत न करें, लेकिन सिर्फ स्रोत कोड। छवियों और दृश्य परिसंपत्तियों में "स्रोत" नहीं होता है, इसलिए उन्हें संस्करण नियंत्रण में ट्रैक किया जाना चाहिए।

— जेसन टी पंखिंगम
स्रोत

4

कभी-कभी, दृश्य परिसंपत्तियों में "स्रोत जैसा कुछ" होता है, और फिर अंतिम आउटपुट बनाने की प्रक्रिया को स्वचालित करने और केवल संस्करण नियंत्रण में स्रोत को संग्रहीत करने के लिए एक अच्छा विचार है। उदाहरण: एसवीजी फाइलों से बने रेखापुंज ग्राफिक संस्करण, वेबसाइट की संपत्ति एक स्प्राइट शीट से कट जाती है।

— तानीस

सही है, यह पूरी तरह से उचित तर्क है।

— जेसन टी फेदरिंगम

21

मेरा मानना है कि गिट के साथ अनुशंसित तरीका एक उप-मॉड्यूल (गिट 1.5.3 में पेश) का उपयोग करना है जो मूल रूप से एक अलग भंडार है जो मुख्य के साथ जुड़ा हुआ है। आप अपनी छवियों (और अन्य बाइनरी एसेट्स) को उप-मॉड्यूल में संग्रहीत करते हैं। इसके बाद मुख्य रिपॉजिटरी या लेफ्ट के साथ चेक-आउट किया जा सकता है, जो कि आवश्यक है।

से http://book.git-scm.com/5_submodules.html

"Git का सबमॉड्यूल सपोर्ट एक रिपॉजिटरी को एक उपनिर्देशिका के रूप में सम्‍मिलित करने की अनुमति देता है, बाहरी प्रोजेक्‍ट का एक चेकआउट। सबमॉड्यूल्‍स अपनी अलग पहचान बनाए रखता है; सबमॉडल सपोर्ट सिर्फ सबमॉड्यूल रिपॉजिटरी लोकेशन और कमिट आईडी को स्‍टोर करता है, इसलिए दूसरे डेवेलपर्स जो क्‍लोनिंग प्रोजेक्‍ट करते हैं (") सुपरप्रोजेक्ट ") एक ही संशोधन पर आसानी से सभी सबमॉड्यूल्स को क्लोन कर सकता है। सुपरप्रोजेक्ट का आंशिक चेकआउट संभव है: आप गिट को क्लोन करने के लिए कह सकते हैं, कुछ या सभी सबमॉडल्स।"

यदि चित्र अक्सर बदलते नहीं हैं, तो भी आकार एक महत्वपूर्ण मुद्दा नहीं होना चाहिए। आप आकार को कम करने / कम करने के लिए कमांड भी चला सकते हैं, जैसे:

git gc
git gc-aggressive
git prune

— दान डिपलो
स्रोत

7

जी हां ।

कहते हैं कि आप सॉफ्टवेयर संस्करण 1.0 जारी करते हैं। संस्करण 2.0 के लिए आप छाया के साथ होने के लिए सभी चित्रों को फिर से करने का निर्णय लेते हैं। तो आप ऐसा करते हैं, और 2.0 जारी करते हैं। फिर कुछ ग्राहक जो 1.0 का उपयोग कर रहे हैं और 2.0 में अपग्रेड नहीं कर सकते हैं, वे तय करते हैं कि उन्हें दूसरी भाषा में प्रोग्राम चाहिए। वे आपको ऐसा करने के लिए $ 1G देते हैं, इसलिए आप निश्चित रूप से कहते हैं। लेकिन एक अलग संस्कृति में, आपकी कुछ तस्वीरें समझ में नहीं आती हैं, इसलिए आपको उन्हें बदलना होगा ...

यदि आप अपनी छवियों को स्रोत नियंत्रण में रखेंगे, तो यह आसान है, 1.0 के आधार पर आप छवियों (अन्य चीजों के बीच) में बदलाव करते हैं, निर्माण करते हैं, जारी करते हैं। यदि आपके पास स्रोत नियंत्रण में ये नहीं थे, तो आपके पास बहुत कठिन समय होगा, क्योंकि आपको पुरानी छवियां ढूंढनी होंगी, उन्हें बदलना होगा और फिर निर्माण करना होगा।

— earlNameless
स्रोत

7

यदि यह परियोजना का हिस्सा है, तो इसे वीसीएस में होना चाहिए । इस सर्वोत्तम को कैसे प्राप्त किया जाए यह वीसीएस पर निर्भर करता है, या आप एक परियोजना को कैसे व्यवस्थित कर सकते हैं। हो सकता है कि डिजाइनरों के लिए एक रेपो, और केवल कोडर के रेपो में परिणाम हो, या केवल 'छवि स्रोत' (मैं एक बार केवल एक .svg फ़ाइल के साथ एक परियोजना थी, और वे चित्र जहां मेक / इनस्केप क्लिप के माध्यम से उत्पन्न होता है)।

लेकिन, अगर कोई वीसीएस ऐसा नहीं कर सकता है, या बेकार हो जाता है, तो मैं कहूंगा कि यह आपकी नौकरी के लिए सही उपकरण नहीं है।

अब तक, मुझे git में वेब परियोजनाओं के लिए ग्राफिक्स (मॉकअप, कॉन्सेप्ट्स, और पेज ग्राफिक्स) की सामान्य मात्रा डालने में कोई समस्या नहीं थी।

— keppla
स्रोत

5

क्या आपको अपनी छवियों को SCM में संग्रहीत करना चाहिए: हाँ। निसंदेह।

क्या आपको अपनी छवियों को git में संग्रहीत करना चाहिए: यह अधिक मुश्किल हो जाता है।

टेक्स्ट फ़ाइलों के साथ git बहुत अच्छा है, लेकिन इसके स्वभाव से बायनेरिज़ बहुत गर्म नहीं हैं। जब आप क्लोन या पुश करेंगे, तो आपके द्वारा हस्तांतरित किए गए डेटा के आकार के साथ समस्याएँ होंगी। आपकी निर्देशिकाएं बढ़ेंगी, और आप विलय के साथ ही सही गड़बड़ी प्राप्त कर सकते हैं (यानी आप 2 छवियों को कैसे मर्ज करते हैं!)

एक उत्तर सबमॉड्यूल्स का उपयोग करना है, क्योंकि इसका मतलब है कि आपकी परियोजना और छवियों के बीच की कड़ी कमजोर होगी - इसलिए आपको छवियों का प्रबंधन नहीं करना होगा जैसे कि वे आपके स्रोत का हिस्सा थे, फिर भी उन्हें नियंत्रित रखना, और नहीं होना उन्हें शाखाओं में बँटाने से चिंता होती है - यह मान लेना कि उपप्रोजेक्ट केवल डेटा का एक 'सपाट' भंडार है जो सामान्य विकास प्रक्रिया के दौरान समान मंथन से नहीं गुजरता है।

अन्य उत्तर उन्हें एक अलग परियोजना में रखना है, इसे कभी भी शाखा न दें, और यह सुनिश्चित करें कि जो कोई भी उस परियोजना को करता है वह उसे तुरंत ऊपर की ओर धकेलता है - कभी भी 2 लोगों को फ़ाइल के एक ही संस्करण को बदलने न दें - आपको यह सबसे कठिन लगेगा पहलू को गैर-वितरित वर्कफ़्लो के लिए डिज़ाइन नहीं किया गया है। इस नियम को लागू करने के लिए आपको पुराने जमाने की संचार विधियों का उपयोग करना होगा।

एक तीसरा जवाब उन्हें पूरी तरह से एक अलग SCM में रखा जाता है जो छवियों के साथ काम करने के लिए बेहतर रूप से तैयार है।

— gbjbaanb
स्रोत

0

@ हेयरस्टाइल के उत्तर में जोड़ते हुए, ध्यान दें कि आकार इसमें एक बड़ा कारक निभाता है। वीसीएस के आधार पर यह छवियों के टन के साथ अच्छी तरह से काम नहीं कर सकता है। जब क्लोन या बड़े धक्का पूरी रात लेना शुरू कर देते हैं तो वास्तव में बहुत देर हो जाती है क्योंकि सभी चित्र पहले से ही आपके भंडार में हैं।

बड़े चित्रों और भविष्य के विकास के लिए योजना बनाएं। आप इस परियोजना में दो साल नहीं चाहते हैं और "ओह बकवास है, शायद रेपो बहुत बड़ा है।"

— TheLQ
स्रोत

1

आपका उत्तर कुछ हद तक अप्रासंगिक है, क्योंकि यह सवाल विशिष्ट है। क्या आपको पता है कि अगर git रिपॉजिटरी के लिए आकार एक बड़ा (या कोई) कारक निभाता है?

— यानि

@ यानिस को याद करना चाहिए कि पहला वाक्य ... AFAIK, git बड़े रिपॉजिटरी के साथ बेहतर है, लेकिन आकार का मुद्दा अभी भी प्रासंगिक है क्योंकि

— गार्जियन

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

— मटनज

0

मैं निश्चित रूप से सहमत हूं कि तकनीकी और आर्थिक रूप से उनका भंडारण संभव है। प्रश्न I यह है कि "क्या ये चित्र शिपिंग उत्पाद का हिस्सा हैं या शिपिंग उत्पाद की सामग्री का हिस्सा हैं?" ऐसा नहीं है कि आप सामग्री को GIT (या किसी अन्य VCS) में संग्रहीत नहीं कर सकते, लेकिन यह एक अलग VCS के लिए एक अलग समस्या है।

— व्याट बार्नेट
स्रोत