Git मा OpenVPN प्रोफाइल: कमिट गर्नु अघि के हटाउने

प्रोफाइलहरूले एकै पटक दुई उद्देश्य पूरा गर्छन्: तिनीहरूले जडान सेटिङहरू अभिलेख गर्छन्, र काम गर्ने प्रमाणहरूको बन्डल बोक्छन्। फाइलको एक्सटेन्सनले तपाईंको हातमा कुन छ भनेर केही भन्दैन। यो रिपोजिटरीको हो भनेर निर्णय गर्नु अघि भित्री सामग्री पढ्नुहोस्।

तलका चरणहरूले क्लाइन्ट टेम्प्लेटलाई संस्करण नियन्त्रणका लागि विचार गरिँदै छ भन्ने मान्छन्। तिनीहरूलाई क्रममा चलाउनुहोस्, र तपाईंले रद्द गर्न नसक्ने कुनै पनि कुरा कमिट गर्नु अघि रोक्नुहोस्।

तपाईंले स्टेज गर्न लागेको फाइल पढ्नुहोस्

वास्तविक बाइटहरूबाट सुरु गर्नुहोस्, किनकि अलग फाइलहरूलाई सन्दर्भ गर्ने प्रोफाइल तिनीहरूलाई भित्र राख्नेभन्दा पूर्ण रूपमा फरक देखिन्छ। PEM ब्लक चिन्हहरू र ca, cert, key, tls-auth तथा tls-crypt नामका इनलाइन ट्यागहरू खोज्नुहोस्, र त्यही जाँचले दुवै अवस्था देखाउनेछ। इन्क्रिप्ट गरिएको निजी कुञ्जी अझै संवेदनशील सामग्री मानिन्छ, र साझा tls-auth वा tls-crypt कुञ्जी प्रयोगकर्ताको पहिचान नभए पनि प्रमाण हो। प्रोफाइलसँगै स्टेज हुने सबैमा त्यही समीक्षा लागू गर्नुहोस्, प्रमाण फाइललाई सन्दर्भ गर्ने अभिलेख र सेटअप स्क्रिप्टहरू सहित।

त्यसपछि कार्य वृक्ष होइन, स्टेज गरिएको सेट हेर्नुहोस्। git diff --cached ले कमिटमा वास्तवमा के हुनेछ देखाउँछ, र यो निर्णयका लागि महत्त्वपूर्ण एक मात्र संस्करण त्यही हो।

रिपोजिटरीले के वितरण गर्न सक्छ निर्णय गर्नुहोस्

टेम्प्लेटले साझा, समीक्षित सेटिङहरू र दर्ताको समयमा व्यक्तिले पाउने सबैका लागि नामित प्लेसहोल्डरहरू बोक्न सक्छ। बोक्न नसक्ने कुरा प्रयोगयोग्य पहिचान हो, किनकि रिपोजिटरी त्यसलाई पढ्न सक्ने सबैमा वितरित हुन्छ, स्वचालन पनि सहित। निजी रिपोजिटरीले दर्शक साँघुरो बनाउँछ तर प्रत्येक पाठक त्यो प्रमाणका लागि अधिकृत छ कि भन्ने प्रश्न भने परिवर्तन गर्दैन।

बेवास्ता नियमले भविष्यका थपलाई रोक्छ र पहिले नै अभिलेख भएको कुरामा केही गर्दैन। यो असमानता दशौं कमिटपछि होइन, पहिलो कमिट अघि नै आत्मसात गर्नुपर्छ। पूर्वाधारका नाम र ठेगानाहरू अलग निर्णय हुन्: ती प्रमाणीकरणका रहस्य होइनन्, तर टोलीले प्रकाशित गर्न चाहेभन्दा बढी खुलासा गर्न सक्छन्। हरेक लाइनलाई पासवर्ड वा सार्वजनिक भनी वर्गीकरण गर्नुको सट्टा त्यो निर्णय स्पष्ट रूपमा लिनुहोस्।

सामग्री पहिले नै इतिहासमा भएमा

नयाँ कमिटमा लाइन हटाउँदा पुरानो संस्करण त्यसलाई तान्ने जो कोहीका लागि अछूत रहन्छ। खुलासालाई वास्तविक मान्नुहोस्: प्रमाणको प्रकार पहिचान गर्नुहोस्, त्यसपछि यसलाई अमान्य गर्न सक्ने निकाय खोज्नुहोस्। क्लाइन्ट प्रमाणपत्र रद्द गरिन्छ र रद्दीकरण सूची पुनः उत्पन्न गरिन्छ; साझा नियन्त्रण-च्यानल कुञ्जी सर्भरमा र यसलाई प्रयोग गर्ने प्रत्येक क्लाइन्टमा परिवर्तन गरिन्छ।

दुवैको प्रभाव-दायरा धेरै फरक छ, र योजनाले सुरु गर्नु अघि तपाईं कुन चलाइरहनुभएको छ भन्नुपर्छ। git log --all -S 'BEGIN PRIVATE KEY' जस्तो खोजबाट सामग्री भित्र्याउने कमिट पत्ता लगाउनुहोस्, ताकि सफाइको दायरा अनुमान नभई ज्ञात होस्। सहकर्मीको क्लोन वा फोर्कले पुरानो वस्तु पहिले नै राखेको हुन सक्छ, त्यसैले रद्दीकरण पहिले र सफाइ पछि आउँछ।

नियन्त्रण गरेपछि मात्र सफा गर्नुहोस्

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

त्यसपछि उपकरणको सारांशमा भरोसा गर्नुको सट्टा हालको वृक्ष र बाँकी इतिहास प्रमाणित गर्नुहोस्।

नतिजालाई दुई कलाकृतिका रूपमा राख्नुहोस्: साझा गर्न सुरक्षित टेम्प्लेट, र दर्ता प्रक्रियामा जारी गरिएका प्रमाणहरूको सूची। दुवैमध्ये कुनैले पनि रिपोजिटरीमा प्रयोगयोग्य पहिचान बस्नुपर्ने माग गर्दैन।

त्यही विभाजन वास्तविक समाधान हो, र प्रोफाइल कमिट गर्न चाहने अर्को व्यक्तिपछि पनि यो टिकिरहन्छ।