रीट गिट रिमोट दूरस्थ इतिहास को हटा सकते हैं?

Question

जैसा कि हम काम पर एसवीएन से गिट करने के लिए विचार करते हैं, एक सहकर्मी ने चिंता जताई है कि एक दुर्भावनापूर्ण या दुर्घटनाग्रस्त डेवलपर हमारे साझा रेपो से रिमोट इतिहास हटाने के लिए git rebase का उपयोग कर सकता है।

संपादित करें: जैसा कि उत्तरों में बताया गया है, संपूर्ण शाखाओं को git push origin :branch-name के साथ रिमोट रेपो से भी हटाया जा सकता है।

क्या यह एक यथार्थवादी समस्या है? यदि हां, तो हम इसे रोकने के लिए क्या दृष्टिकोण ले सकते हैं?

Answer 1

मैं अपने सहकर्मी के साथ सहमत करने के लिए वहाँ एक समस्या यहाँ है कि करते हैं क्योंकि:

• चाहे कितनी अच्छी तरह आप अपने कमिटर पर भरोसा है, वहाँ हमेशा मानव त्रुटि
• अधिक महती समीक्षा प्रक्रियाओं की संभावना है (जैसे Gerrit) हमेशा उपयुक्त
• बैकअप से बहाल करने धीमा हो सकता है नहीं कर रहे हैं और एक PITA

आप receive.denyNonFastForwards औरमाना जाता हैविन्यास पैरामीटर? AFAICT ये गिट 1.6 में बाद में उपलब्ध हैं।

प्रो Git से

:

आप rebase करता है कि आप पहले से ही धक्का दिया है और फिर पुश करने के लिए एक एक दूरस्थ शाखा है, जो शामिल नहीं है के लिए प्रतिबद्ध कोशिश फिर से पुश करने के लिए प्रयास करें, या अन्यथा हैं रिमोट शाखा वर्तमान में इंगित करता है कि प्रतिबद्धता, आपको अस्वीकार कर दिया जाएगा।यह आम तौर पर अच्छी नीति है; लेकिन रिबेस के मामले में, आप यह निर्धारित कर सकते हैं कि आप जानते हैं कि आप क्या कर रहे हैं और -f ध्वज को अपने पुश कमांड पर ध्वजांकित करें।

, गैर तेजी से आगे संदर्भ के लिए दूरस्थ शाखाओं अद्यतन के लिए मजबूर करने की क्षमता को अक्षम सेट receive.denyNonFastForwards

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

लेखक का उल्लेख के रूप में, इस नियम भी एक हुक प्राप्त के माध्यम से लागू किया जा सकता है (जो described later in Pro Git है)।

इन तकनीकों को आपके साझा रेपो में आकस्मिक (या दुर्भावनापूर्ण) खोए इतिहास के विरुद्ध सुरक्षा करनी चाहिए।

Answer 2

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

• उन डेवलपर्स को पुश अनुमति न दें जिन्हें आप भरोसा नहीं करते हैं।

• जब रेपो साझा किया जाता है, तो इतिहास के साथ गड़बड़ न करें, पिछले कामों पर रीबेस का उपयोग करने से बचें। अगर आपको अलग-अलग शाखा से कुछ जोड़ने की ज़रूरत है तो विलय या चेरी-पिक का उपयोग करें, इस स्थिति में इतिहास प्रभावित नहीं होगा।

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

अपने प्रश्न को रोकने के लिए कैसे के बारे में - Gerrit संशोधन प्रणाली का उपयोग, यह संशोधन के लिए अच्छा वेब इंटरफेस के साथ डेवलपर के स्थानीय भंडार और मास्टर रेपो के बीच प्रतिबद्ध के रास्ते पर एक मध्यवर्ती कदम की तरह है, तो आप करने के लिए अनुमति दे सकते हैं किसी के लिए संशोधन को संशोधित करने के लिए दबाव डालें, लेकिन परिवर्तन सत्यापन और अनुमोदन के बाद आपकी मास्टर शाखा में विलय कर दिया जाएगा (जिसके लिए आपको आमतौर पर कोर डेवलपर्स को कुछ अनुमतियां दी जाती हैं)। आप देख सकते हैं कि यह महाारा प्रोजेक्ट की तरह कैसा दिखता है: https://reviews.mahara.org इस विशेष मामले में, केवल गेरिट बॉट को मास्टर को धक्का देने की अनुमति है (जो here है) और कोई और नहीं।

Answer 3

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