क्या कोई गिट रिपोजिटरी संभाल सकता है की संख्या के लिए ऊपरी सीमा है?

Question

मुझे आश्चर्य है कि क्या गिट रिपोजिटरी संभाल सकता है कि काम करने की संख्या के लिए ऊपरी सीमा है।

एक एकल प्रोजेक्ट में मैं अभी काम कर रहा हूं, मैं स्थानीय रूप से कोडिंग कर रहा हूं, गिट में बदलाव कर रहा/दबा रहा हूं, फिर मेरे विकास सर्वर पर बदलाव खींच रहा हूं।

मैं स्थानीय स्तर पर काम करने के लिए एक आसान विकल्प के रूप में इस का इलाज और अपलोड करने के परिवर्तन FTP के माध्यम से ... सौभाग्य/दुर्भाग्य से यह इस तरह एक आसान कार्यप्रवाह है कि मैं कभी कभी के माध्यम से कई संपादित जाना है/प्रतिबद्ध/धक्का/खींच/ब्राउज़र ताज़ा चक्र कोडिंग करते समय।

मुझे आश्चर्य है कि यह चारों ओर घूमने जा रहा है और मुझे लाइन के नीचे कहीं काट रहा है। यदि यह एक समस्या होने की संभावना है, तो मैं सोच रहा हूं कि मैं उस परेशानी से कैसे बच सकता हूं ... ऐसा लगता है कि एक रिबेस का रास्ता हो सकता है, खासकर जब से मुझे विरोधाभासी शाखाओं आदि के बारे में चिंता करने की ज़रूरत नहीं है।

Answer 1

वैसे "ऊपरी सीमा" संभवतः एक बिंदु है जिस पर SHA1 टकराव होता है, लेकिन चूंकि SHA 40 हेक्साडेसिमल अंक लंबे होते हैं (16^40 ~ 1.4x10^48 संभावनाएं), यह शून्य संभावना के करीब है यह भी मजाकिया नहीं है। तो लगभग शून्य प्रतिशत मौका है कि आपको कम से कम अगले सहस्राब्दी के लिए कोई समस्या होगी।

हाइपरबॉलिक उदाहरण (बस मज़ेदार के लिए): 1 प्रतिबद्ध/मिनट (बस एक फ़ाइल बदलना -> तीन नए एसएचए इस्तेमाल किए गए (फ़ाइल, प्रतिबद्ध, पेड़) = 3 नए शास इस्तेमाल/मिनट = ... = 1.6 एम शास/वर्ष = 1.6 अरब शाह/सदियों = 1x10^-37 % प्रत्येक हजार वर्षों ... इस्तेमाल किया

कहा जा रहा है (1000 फ़ाइलें/commmit/मिनट, यह अभी भी 3.6x10^-35% है), आप अगर अपने इतिहास को साफ करना चाहते हैं, उन्हें रीबेस के साथ नीचे छेड़छाड़ करना शायद आपकी सबसे अच्छी शर्त है। बस सुनिश्चित करें कि आप रेपो को सार्वजनिक रूप से साझा करते हैं तो आप प्रभाव को समझते हैं।

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

Answer 2

मुझे यकीन है कि आपको बिल्कुल चिंता करने की ज़रूरत नहीं है :)

गिट फाइलों की जांच करने के लिए SHA-1 हैश का उपयोग कर रहा है, हैश संघर्ष होने की संभावना शून्य के करीब है। तो, मज़े करो !!

मैंने व्यक्तिगत रूप से बिना किसी समस्या के 30 कार्य किए।

लेकिन संस्करण बाइनरी फाइलों से बचें :) यह वास्तव में इसके लिए भारी है।

Answer 3

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

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